9 ms·

Easy HTTPS for your private networks

272 points by 8organicbits 3y ago

deleted 3y ago
[deleted]
jareklupinski 3y ago
interesting, wonder if this will help me get access to the Geolocation API for my ESP32 captive portal devices on connect, a user is presented with an option to preselect a wifi network and input their geographic location. I managed to stuff a zip code lookup table into the code, but lat/long is really cumbersome to input, and using the phone's location sensor requires an HTTPS server
frfl 3y ago
Haven't used this myself, but I did find out about Lego (https://github.com/go-acme/lego https://github.com/go-acme/lego) recently and used it to get a Let's Encrypt cert for a local network website I have using the DNS challenge. It was fairly straight forward, $ export NAMESILO_API_KEY=... $ export NAMESILO_POLLING_INTERVAL=10 $ export NAMESILO_PROPAGATION_TIMEOUT=1800 $ export NAMESILO_TTL=3600 $ lego --email <email> --dns namesilo --domains *.<domain>.com run
- 8organicbits 3y ago
  LEGO works great for this kind of thing. If you want to try with a localcert.net domain, the instructions are here: https://docs.getlocalcert.net/acme-clients/lego/ https://docs.getlocalcert.net/acme-clients/lego/
urda 3y ago
I recommend just using something like XCA [1]. Just configure your own root CA and distribute it. [1] https://hohnstaedt.de/xca/ https://hohnstaedt.de/xca/
- 8organicbits 3y ago
  Part of the reason I've been working on this is that the "distribute" step is quite difficult to do at scale across an ever changing set of operating systems and devices. Using a free public CA like Let's Encrypt let's you avoid that challenge since it's trusted out of the box everywhere.
- abound 3y ago
  Doesn't that require being able to add your root CA on each device you access the application from? That can be a chore in some cases, esp when you want to share the application with others. For services I host on my Tailscale/Headscale network, I just use DNS challenges. With Cloudflare and Caddy, it's as straightforward as adding: tls { dns cloudflare {env.CLOUDFLARE_AUTH_TOKEN} } to the site's configuration in the Caddyfile
  - 8organicbits 3y ago
    <3 Caddy. Here's my equivalent: https://docs.getlocalcert.net/acme-clients/caddy/ https://docs.getlocalcert.net/acme-clients/caddy/
  - housemusicfan 3y ago
    This is a poor solution to a non-problem. 99% of "private networks" don't need HTTPS for most things, full-stop. Those that do, the correct solution is to deploy a private CA and use internal DNS. The implication being you do not trust your network. So the solution is to.....use public DNS and Let's Encrypt garbageware and leak details of your internal network so you can pretend you're now more secure because the cafeteria menu is hosted over HTTPS? Save the black hats some time and just email them the Visio of your core network. If you don't have access to install the root certificate then by definition you don't control the private network, simple as that. > when you want to share the application with others This is literally the definition of no longer a "private network".
    - 8organicbits 3y ago
      > 99% of "private networks" don't need HTTPS for most things, full-stop. The encryption HTTPS provides isn't important if you trust your network. However server authentication is important if your devices move between networks (phone, laptop, etc). Applications don't know you switched networks, they just want to connect and will happily send sensitive data to an attacker if you ever connect to a malicious network. There was an example of `git push` leaking the entire commit history mentioned on HN not too long ago.
    - 3y ago
- bryancoxwell 3y ago
  “And distribute it” feels very “draw the rest of the fucking owl”-y to me
deleted 3y ago
[deleted]
andrewmcwatters 3y ago
If you absolutely need a hostname that is not "localhost" you should still configure your own host record and use a utility like mkcert.[1] Most of the time, you really shouldn't need this, and your local HTTPS development should just require: mkcert -install mkcert localhost In the directory of your app, etc. If you're deploying private applications, these records should exist in your intranet DNS resolver instead. [1]: https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert
schlarpc 3y ago
Somewhat related - I made a bridge server [1] that lets ACME clients use standard RFC2136 to solve DNS-01 challenges for internal names without them needing credentials for the actual DNS backend (Route 53 in my case). [1] https://github.com/schlarpc/rfc2136_bridge/blob/main/src/rfc2136_bridge/app.py https://github.com/schlarpc/rfc2136_bridge/blob/main/src/rfc...
- linsomniac 3y ago
  Interesting idea. I have a workflow for creating AWS credentials that are restricted to doing the LetsEncrypt DNS challenges for just a single sub-domain, and that seems to be working well. https://linsomniac.gitlab.io/post/2019-09-10-letsencrypt-with-route53/ https://linsomniac.gitlab.io/post/2019-09-10-letsencrypt-wit...
- bruce511 3y ago
  I did exactly the same for our local-cloud products. Our local-cloud program connects to our "certificate server", and asks for a name/ip combination. Our certificate server gets it using API access to our "local-cloud" domain. The local machine receives it. So the end user does not have the Domain credentials. They have credentials to our cert server, but those have very limited value (and would need to be decrypted first.)
ncphil 3y ago
Interesting idea, but I think I'll stick with DNS challenge and LetsEncrypt. Lazy me really needs to finally sit down and automate the process (all the pieces are in place on my registrar's side). Did the private CA thing for almost two decades, and yes, it was a PITA, but even that was mostly because I failed to invest the time to automate it (Linux and Windows devices aren't _that_ hard to manage with OSS tools, printers might be a harder challenge; Android refusing to play nice with private DNS just makes it easier to disregard it altogether, as do all those IoT firmwares that don't even pretend to give you a choice). Ultimately, the current infrastructure, like that for message encryption, is just too damn convoluted. Eventually it might get fixed, but I'll probably be long retired to an Internet dead zone by then (raising goats can't be harder than managing fleets of application servers, can it?).
worik 3y ago
This is unnecessary It is straightforward to create your own Root CA and use it to sign certificates for your private network, using openssl. Ensure that you implement the V3 extensions with @altnames, for the certificates you issue, with a "DNS => <FQDN>" (or you can use an IP address instead of FDN. I have not experimented with that). .local domain names work fine If you do not implement "@altnames" the certificate will work for tools like curl, wget "openssl s_client", but not for browsers. (In my notes some place I am too lazy to go and read there is a reference to the RFC that documents that you do not have to use the subject/CN, mēh) There are other tools (than openssl) that do this to. Using this service means you really do not have a private network
- WirelessGigabit 3y ago
  I love this idea. Except I have devices on my network that don't allow me to do that. Company lock downs etc. So I just pull in stuff from LetsEncrypt.
  - lolinder 3y ago
    As a rule I don't connect to my local services from my company laptop—it sits in the guest network isolated from the rest of the network.
    - saladdressing 3y ago
      [dead]
- lolinder 3y ago
  Caddy will do this for you as long as you don't give it an ACME config. It handles the root CA creation as well as all of the certificates for any domains that you define in the Caddyfile, so all you have to do is find the root CA it generates and install it on your devices.
  - e12e 3y ago
    > all you have to do is find the root CA it generates and install it on your devices. Unfortunately that's the hard part - getting Firefox/chrome/edge/safari and is/libc/curl to all trust the ca. It's a little easier on Linux, but still convoluted. And with an actual trusted CA the trust is way too wide (every domain). Not to mention revocation lists and certificate renewals (and revocation s) ... Dedicated letsencrypt "internal" domain is probably the sweetspot for most uses these days. Maybe a serviceN.int.example.com where int.example.com allows for dynamic DNS updates/DNS challenges. I've been thinking about setting up powerdns/coredns/knotdns with rfc dynamic updates for a dedicated internal domain - but for now tailscale with magic DNS mostly fills the need (unfortunately not with ssl for all k8s internal services, "only" VPN).
Humphrey 3y ago
Or, it's super easy to roll your own using letsencrypt. 1. Buy your own public domain (such as companyname.dev) 2. Setup a LetsEncrypt wildcard certificate with DNS validation 3. Update your /etc/hosts to something like `127.0.0.1 companyname.dev` We have this working with multiple developers, each renewing their certificates themselves. Works great, it's simple, and don't need to trust an extra third party.
- klysm 3y ago
  Just at the whole domain or does each dev make their own subdomain?
  - Humphrey 3y ago
    We setup each project with it's own subdomain... so a /etc/hosts file would be something like 127.0.0.1 client7.companyname.dev our-amazing-product.companyname.dev postgres2.companyname.dev So, then we can use the same settings, etc across devs. Then each dev just runs the script to renew the script as they are needed (no need to share certs between devs)
    - e12e 3y ago
      Why not put project.companyname.dev in DNS? (Pointing to 127.0.0.1, ::1?)
      - klysm 3y ago
        Yeah that seems more ideal
- 8organicbits 3y ago
  Correct, a distinction with this service is that the domain names are free. One part of my decision to build this service was the fall of freenom (free domain names). Typically free domain name services are full of spam, malware, and other junk. getlocalcert seeks to avoid that as it only permits private network usage. My hope is that this model can serve that niche while avoiding abuse.
tandav 3y ago
Side question: Does anyone know a simple caddy-like solution, but for non-HTTP traffic? For example, I want automatic SSL certificates for redis, mongodb, postgresql.
- mthoms 3y ago
  Caddy can act as a proxy for those services. It's ridiculously easy to set-up. mongo.mydomain.com { reverse_proxy 127.0.0.1:27017 }
  - selcuka 3y ago
    > but for non-HTTP traffic? Doesn't this only work for HTTP too? It may work with MongoDB because it talks HTTP through TCP 27017, but PostgreSQL, for example, has a proprietary protocol on TCP 5432.
    - 8organicbits 3y ago
      I think you need the layer4 module to get this working. https://caddyserver.com/docs/modules/layer4 https://caddyserver.com/docs/modules/layer4
- avtar 3y ago
  stunnel should work for all of the above
deleted 3y ago
[deleted]
gilad 3y ago
MiniCA[0] works for this, quite trivial to setup and stamp out certs. [0] https://github.com/jsha/minica https://github.com/jsha/minica
octagons 3y ago
My preferred solution for this is a combination of Traefik and Smallstep StepCA. I run a collection of tools via Docker compose, and new certificates are issued automatically based on the hostname. The only problem is that I have to maintain a list of DNS entries for the StepCA container as extra hosts. I haven’t found an elegant solution for this part.
seiferteric 3y ago
Cool, but as others said fairly easy to do on your own already. Sort of related but a problem I have been trying to solve is, how to create a trusted certificate for a new device on a private network automatically without any configuration? For example, imagine you are turning up a new router or switch with a Web UI for management. Traditionally this is served on http initially and you can optionally install a cert and enable https. It would be nice to have a way to have this happen automatically to obviate the need for http at all. Also consider that this private network may not be connected to the internet at all and so can't rely on outside servers. I was kicking around the idea for an rfc that would be something like this. Your DHCP server would have an option to act as a CA (or point at one), with ACME protocol enabled. Then, you add DHCP option fields telling clients to trust this new CA certificate, but only for hosts on this local network (to avoid being able to MITM outside connections). Then clients on this network would be able to request certificates from the CA using ACME automatically and others on the network would automatically trust them assuming support for this standard was added the OS or browsers etc.
- 8organicbits 3y ago
  You can get somewhat close to that with getlocalcert. When the device first boots, it calls the getlocalcert API to register a free, anonymous domain name (negative: its a UUID domain, ugly). You'd need outbound connections to api.getlocalcert.net and an ACME certificate authority (Let's Encrypt) to issue a ccertificate. When the user connects to http://<ip-address> http://<ip-address> it redirects to https://<uuid>.localcert.net https://<uuid>.localcert.net, which the browser trusts since the cert is from a public CA. No need to manually trust a cert. The user would bookmark it and all future use is HTTPS-only. If I see usage like this, there's ways I can make this cleaner.
  - denton-scratch 3y ago
    > it calls the getlocalcert API to register a free, anonymous domain name ...rather than to get an actual certificate. I didn't dig past the front page, but as far as I can see, they don't issue HTTPS certs at all, easy or oherwise; they offer managed DNS subdomains. You want a cert, you have to get it somewhere else.
denkmoon 3y ago
step-ca is an excellent for running your own private CA with ACME support. Individual software support for defining your own acme directory isn't always there, but such is the life of running your a private PKI. Worst case, you manually issue a cert like you would have done anyway.
donselaar 3y ago
I really hope DANE will become more popular (and widely supported) some time. Works great on air gapped networks without the need for a publicly trusted CA or Let's Encrypt. No ACME daemon to monitor, just put your public key in a DNS record an forget about it.
- ori_prior 3y ago
  Me too. But the CA and browser mafia is too intertwined to let this change anytime soon.
  - drsnow 3y ago
    Are you being facetious or do you actually believe this?
- 8organicbits 3y ago
  > Works great on air gapped networks I've usually seen DANE paired with DNSSEC, and on the internet it feels required. DANE on an air gapped network is new to me, do you just skip the DNSSEC part? I'd be fearful of joining a network that puts bogus DANE TLSA records for google.com, for example. Browser support for DANE is at 0%, unfortunately. https://caniuse.com/?search=dane https://caniuse.com/?search=dane
  - donselaar 3y ago
    You're right that DANE kind of implies DNSSEC. Technically it can go without, but it's quite pointless to do because you cannot trust your TLSA record without DNSSEC. DNSSEC works in an air gapped network when you deploy your own trust anchor in your DNS. I wouldn't touch a domain name that you don't own yourself (like google.com) but instead only use a domain name you purchased. It surprises me that DANE is even listed on caniuse.com! I expected it to be way to exotic to be on that list. I'm under no illusion that browsers are going to support this anytime soon unfortunately. Now let's hope I didn't wake up tptacek to lecture us on how DNSSEC is bad and how it will eat your children. ;)
mvip 3y ago
Another approach to solving this problem is to use Tailscale and their new SSL feature [1]. This of course is dependent on that you use Tailscale, but it is pretty handy and does give you a Let's Encrypt cert. [1] https://blog.viktorpetersson.com/2022/12/23/securing-services-with-tailscale.html https://blog.viktorpetersson.com/2022/12/23/securing-service...
mgaunard 3y ago
The web/cloud world is so much nonsense. First, why do you even need HTTPS on a trusted network. Also if you want a trusted network, why not just use IPSec? HTTPS was specifically built to work over the Internet because it was too hard to switch from IPv4. Second, if it's private, surely you can just use your own Certificate Authority, instead of paying a tax to be listed on someone else's Certificate Authority.
- pravus 3y ago
  > First, why do you even need HTTPS on a trusted network. PCI compliance among many other regulatory issues. You will be required to show that data is not only encrypted at rest but is encrypted through your entire transport chain regardless of any physical security. The threat model assumes that an attacker is able to temporarily access network resources undetected and can use simple sniffing tools to egress sensitive data. This will not be optional.
  - mgaunard 3y ago
    That's a whole lot of nonsense. What if you push your data using a custom binary protocol over UDP multicast? Are you suggesting that regulations make it so that everything should be a slow and inefficient https webapp?
- dvdkon 3y ago
  Trusted networks are a flawed concept, unless you mean a software-backed tunnel. And I'm glad the slightly-less-mad TLS won over IPSEC with some certificate extension.
- wolletd 3y ago
  Well, because my local instance of <WebApp> says, <Feature> isn't available unless I use HTTPS. Also, HTTPS with a public CA just works on most systems, whereas IPsec requires Client configuration. It's still easier to roll out than switching from IPv4. For personal or experimental things, I may use a local CA, but getting certificates for the internal subdomains of my company is trivial when you already got a public domain on a Server that's capable of using DNS-01 challenges. Enabling HTTPS is just way easier than actually ensuring you can trust your local network. Many real-life middle-class companies start out with just having a network and not thinking about security at all. Some companies may even have untrusted internal networks by choice by allowing BYOD.
3dbrows 3y ago
I wrote about something along these lines a couple of years ago [0] and thought the idea was dead due to rate limiting. But does LE now regard each subdomain as having its own limit, rather than taking that of the parent domain? [0] https://3dbrows.dev/ https://3dbrows.dev/
- Jnr 3y ago
  The limit can be increased in some cases. https://letsencrypt.org/docs/rate-limits/#a-id-overrides-a-overrides https://letsencrypt.org/docs/rate-limits/#a-id-overrides-a-o...
  - 8organicbits 3y ago
    I think options are expanding now. ZeroSSL offers ACME certs without rate limits. You'll likely need to pay them if you're getting more than three.
onion-soup 3y ago
>"Eeasy HTTPS" >Displays somewhat overcomplicated diagram with bunch of arrows and scary technobubble words. Ping me again when HTTPs actually becomes easy
loufe 3y ago
I'm fairly ignorant for certificates, but would anybody here happen to know whether this tech would be easily implemented on a Synology NAS? I enabled HTTPS on a NAS but figuring out how to get a let's encrypt cert or even a locally trusted cert to work seemed more difficult than anticipated.
emadda 3y ago
I released tabserve.dev recently. It gives you a https url for localhost by using your browser as a reverse proxy. Take a look: https://tabserve.dev https://tabserve.dev
throw0101c 3y ago
This leverages the ACME DNS server which has a REST API: * https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns If your DNS provider has an API, you can hook into that for internal-only web servers; this handy code supports several dozen APIs so you don't have to re-invent the wheel: * https://github.com/AnalogJ/lexicon https://github.com/AnalogJ/lexicon * https://pypi.org/project/dns-lexicon/ https://pypi.org/project/dns-lexicon/ * https://dns-lexicon.readthedocs.io/en/latest/user_guide.html https://dns-lexicon.readthedocs.io/en/latest/user_guide.html
- 8organicbits 3y ago
  > leverages the ACME DNS server It's inspired by ACME DNS, but getlocalcert is actually using PowerDNS with a Django API that's compatible. I originally built the tool as a fork of acme-dns, but lost traction somewhere, I switched to pdns and it worked great.
exabrial 3y ago
The whole point of a local DNS and local CA though is to insulate yourself from cloud expenses and failures. Our DNS system has had 0 outages, whereas our Google Fiber uplink has aprox one failure a month (Weather, construction, maintenance, upgrades, unscheduled outages). It's just as easy to deploy a trusted CA using MDM as it is to deploy this.
- 8organicbits 3y ago
  The split-dns setup [1] does a pretty good job of insulating users from cloud failures. Devices on your network use local DNS, no cloud needed. ACME clients start renewing certificates 30 days before expiration, and retry daily. The cloud API would need to be down 30 days in a row for the certificate renewal to fail. It's quite failure tolerant. If Let's Encrypt had an enormous outage, you could switch to ZeroSSL. Caddy actually fails over automatically [2]. Re. MDM, I've never seen a perfect rollout. [1] https://docs.getlocalcert.net/dns/split-view/ https://docs.getlocalcert.net/dns/split-view/ [2] https://caddyserver.com/docs/automatic-https#errors https://caddyserver.com/docs/automatic-https#errors
xrd 3y ago
As others have noted, I'm not sure what this adds unless you cannot use letsencrypt to get wildcard certs. I wrote about that here: https://blog.katarismo.com/2023-06-04-expose-any-private-service-using-headscale https://blog.katarismo.com/2023-06-04-expose-any-private-ser... All my internal and external services inside and outside of my headscale/tailscale network can use a single cert this way. I generate a single cert and then reuse it everywhere.
mr-karan 3y ago
I've a simpler system to use encrypted network for local/private use. - Setup Tailscale on the server and personal device - Deploy apps (self hosted tools that I use) on the wireguard interface created by Tailscale - Deploy caddy as a reverse proxy for all these tools and use `.internal` domain - Use Adguard's DNS rewrites feature to answer custom DNS response for specified `.internal` domains. The A record contains the IP assigned by Tailscale (wg0 interface) for that device. The Caddyfile is as simple as: http://miniflux.karan.internal { reverse_proxy 127.0.0.1:3000 } Using this setup, as soon as I connect to Tailscale, I can access `miniflux.karan.internal` on a secure encrypted network without worrying about configuring HTTPS for local domains or renewing SSL certs.
lazyweb 3y ago
My way of doing private SSL (not necessarily the easiest): * own CA, to be distributed to all systems via Ansible playbook or Dockerfile directives * Hashicorp Vault with enabled PKI engine * Ansible Hashivault module [1] * Ansible role & playbook to tie it all together * CI enviroment for automated deployment of SSL certs to target systems Works flawlessly once set up, including restart/reload of affected services. Might do a writeup on my personal blog at some point. [1] https://github.com/ansible-collections/community.hashi_vault https://github.com/ansible-collections/community.hashi_vault
1vuio0pswjnm7 3y ago
Even easier would be to eliminate ICANN DNS and LetsEncrypt as mandatory dependencies for using HTTPS. If I'm the CA then maybe I know what I want to trust. Not every computer network user has same use cases. One size does not fit all, so to speak. If come computer network users want to use third parties to help them figure out who to trust, then they can do so, it's always an option. But currently there are some companies standing in the way of letting any computer network user determine trust themselves. Currently, delegating trust to third parties isn't optional, it's mandatory.

272 points by 8organicbits 3y ago

deleted 3y ago

[deleted]

interesting, wonder if this will help me get access to the Geolocation API for my ESP32 captive portal devices on connect, a user is presented with an option to preselect a wifi network and input their geographic location. I managed to stuff a zip code lookup table into the code, but lat/long is really cumbersome to input, and using the phone's location sensor requires an HTTPS server

frfl 3y ago

Haven't used this myself, but I did find out about Lego (https://github.com/go-acme/lego https://github.com/go-acme/lego) recently and used it to get a Let's Encrypt cert for a local network website I have using the DNS challenge. It was fairly straight forward, $ export NAMESILO_API_KEY=... $ export NAMESILO_POLLING_INTERVAL=10 $ export NAMESILO_PROPAGATION_TIMEOUT=1800 $ export NAMESILO_TTL=3600 $ lego --email <email> --dns namesilo --domains *.<domain>.com run

8organicbits 3y ago
LEGO works great for this kind of thing. If you want to try with a localcert.net domain, the instructions are here: https://docs.getlocalcert.net/acme-clients/lego/ https://docs.getlocalcert.net/acme-clients/lego/

urda 3y ago

I recommend just using something like XCA [1]. Just configure your own root CA and distribute it. [1] https://hohnstaedt.de/xca/ https://hohnstaedt.de/xca/

8organicbits 3y ago
Part of the reason I've been working on this is that the "distribute" step is quite difficult to do at scale across an ever changing set of operating systems and devices. Using a free public CA like Let's Encrypt let's you avoid that challenge since it's trusted out of the box everywhere.
abound 3y ago
Doesn't that require being able to add your root CA on each device you access the application from? That can be a chore in some cases, esp when you want to share the application with others. For services I host on my Tailscale/Headscale network, I just use DNS challenges. With Cloudflare and Caddy, it's as straightforward as adding: tls { dns cloudflare {env.CLOUDFLARE_AUTH_TOKEN} } to the site's configuration in the Caddyfile
- 8organicbits 3y ago
  <3 Caddy. Here's my equivalent: https://docs.getlocalcert.net/acme-clients/caddy/ https://docs.getlocalcert.net/acme-clients/caddy/
- housemusicfan 3y ago
  This is a poor solution to a non-problem. 99% of "private networks" don't need HTTPS for most things, full-stop. Those that do, the correct solution is to deploy a private CA and use internal DNS. The implication being you do not trust your network. So the solution is to.....use public DNS and Let's Encrypt garbageware and leak details of your internal network so you can pretend you're now more secure because the cafeteria menu is hosted over HTTPS? Save the black hats some time and just email them the Visio of your core network. If you don't have access to install the root certificate then by definition you don't control the private network, simple as that. > when you want to share the application with others This is literally the definition of no longer a "private network".
  - 8organicbits 3y ago
    > 99% of "private networks" don't need HTTPS for most things, full-stop. The encryption HTTPS provides isn't important if you trust your network. However server authentication is important if your devices move between networks (phone, laptop, etc). Applications don't know you switched networks, they just want to connect and will happily send sensitive data to an attacker if you ever connect to a malicious network. There was an example of `git push` leaking the entire commit history mentioned on HN not too long ago.
  - 3y ago
bryancoxwell 3y ago
“And distribute it” feels very “draw the rest of the fucking owl”-y to me

deleted 3y ago

[deleted]

andrewmcwatters 3y ago

If you absolutely need a hostname that is not "localhost" you should still configure your own host record and use a utility like mkcert.[1] Most of the time, you really shouldn't need this, and your local HTTPS development should just require: mkcert -install mkcert localhost In the directory of your app, etc. If you're deploying private applications, these records should exist in your intranet DNS resolver instead. [1]: https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert

schlarpc 3y ago

Somewhat related - I made a bridge server [1] that lets ACME clients use standard RFC2136 to solve DNS-01 challenges for internal names without them needing credentials for the actual DNS backend (Route 53 in my case). [1] https://github.com/schlarpc/rfc2136_bridge/blob/main/src/rfc2136_bridge/app.py https://github.com/schlarpc/rfc2136_bridge/blob/main/src/rfc...

linsomniac 3y ago
Interesting idea. I have a workflow for creating AWS credentials that are restricted to doing the LetsEncrypt DNS challenges for just a single sub-domain, and that seems to be working well. https://linsomniac.gitlab.io/post/2019-09-10-letsencrypt-with-route53/ https://linsomniac.gitlab.io/post/2019-09-10-letsencrypt-wit...
bruce511 3y ago
I did exactly the same for our local-cloud products. Our local-cloud program connects to our "certificate server", and asks for a name/ip combination. Our certificate server gets it using API access to our "local-cloud" domain. The local machine receives it. So the end user does not have the Domain credentials. They have credentials to our cert server, but those have very limited value (and would need to be decrypted first.)

ncphil 3y ago

Interesting idea, but I think I'll stick with DNS challenge and LetsEncrypt. Lazy me really needs to finally sit down and automate the process (all the pieces are in place on my registrar's side). Did the private CA thing for almost two decades, and yes, it was a PITA, but even that was mostly because I failed to invest the time to automate it (Linux and Windows devices aren't _that_ hard to manage with OSS tools, printers might be a harder challenge; Android refusing to play nice with private DNS just makes it easier to disregard it altogether, as do all those IoT firmwares that don't even pretend to give you a choice). Ultimately, the current infrastructure, like that for message encryption, is just too damn convoluted. Eventually it might get fixed, but I'll probably be long retired to an Internet dead zone by then (raising goats can't be harder than managing fleets of application servers, can it?).

worik 3y ago

This is unnecessary It is straightforward to create your own Root CA and use it to sign certificates for your private network, using openssl. Ensure that you implement the V3 extensions with @altnames, for the certificates you issue, with a "DNS => <FQDN>" (or you can use an IP address instead of FDN. I have not experimented with that). .local domain names work fine If you do not implement "@altnames" the certificate will work for tools like curl, wget "openssl s_client", but not for browsers. (In my notes some place I am too lazy to go and read there is a reference to the RFC that documents that you do not have to use the subject/CN, mēh) There are other tools (than openssl) that do this to. Using this service means you really do not have a private network

WirelessGigabit 3y ago
I love this idea. Except I have devices on my network that don't allow me to do that. Company lock downs etc. So I just pull in stuff from LetsEncrypt.
- lolinder 3y ago
  As a rule I don't connect to my local services from my company laptop—it sits in the guest network isolated from the rest of the network.
  - saladdressing 3y ago
    [dead]
lolinder 3y ago
Caddy will do this for you as long as you don't give it an ACME config. It handles the root CA creation as well as all of the certificates for any domains that you define in the Caddyfile, so all you have to do is find the root CA it generates and install it on your devices.
- e12e 3y ago
  > all you have to do is find the root CA it generates and install it on your devices. Unfortunately that's the hard part - getting Firefox/chrome/edge/safari and is/libc/curl to all trust the ca. It's a little easier on Linux, but still convoluted. And with an actual trusted CA the trust is way too wide (every domain). Not to mention revocation lists and certificate renewals (and revocation s) ... Dedicated letsencrypt "internal" domain is probably the sweetspot for most uses these days. Maybe a serviceN.int.example.com where int.example.com allows for dynamic DNS updates/DNS challenges. I've been thinking about setting up powerdns/coredns/knotdns with rfc dynamic updates for a dedicated internal domain - but for now tailscale with magic DNS mostly fills the need (unfortunately not with ssl for all k8s internal services, "only" VPN).

Humphrey 3y ago

Or, it's super easy to roll your own using letsencrypt. 1. Buy your own public domain (such as companyname.dev) 2. Setup a LetsEncrypt wildcard certificate with DNS validation 3. Update your /etc/hosts to something like `127.0.0.1 companyname.dev` We have this working with multiple developers, each renewing their certificates themselves. Works great, it's simple, and don't need to trust an extra third party.

klysm 3y ago
Just at the whole domain or does each dev make their own subdomain?
- Humphrey 3y ago
  We setup each project with it's own subdomain... so a /etc/hosts file would be something like 127.0.0.1 client7.companyname.dev our-amazing-product.companyname.dev postgres2.companyname.dev So, then we can use the same settings, etc across devs. Then each dev just runs the script to renew the script as they are needed (no need to share certs between devs)
  - e12e 3y ago
    Why not put project.companyname.dev in DNS? (Pointing to 127.0.0.1, ::1?)
    - klysm 3y ago
      Yeah that seems more ideal
8organicbits 3y ago
Correct, a distinction with this service is that the domain names are free. One part of my decision to build this service was the fall of freenom (free domain names). Typically free domain name services are full of spam, malware, and other junk. getlocalcert seeks to avoid that as it only permits private network usage. My hope is that this model can serve that niche while avoiding abuse.

tandav 3y ago

Side question: Does anyone know a simple caddy-like solution, but for non-HTTP traffic? For example, I want automatic SSL certificates for redis, mongodb, postgresql.

mthoms 3y ago
Caddy can act as a proxy for those services. It's ridiculously easy to set-up. mongo.mydomain.com { reverse_proxy 127.0.0.1:27017 }
- selcuka 3y ago
  > but for non-HTTP traffic? Doesn't this only work for HTTP too? It may work with MongoDB because it talks HTTP through TCP 27017, but PostgreSQL, for example, has a proprietary protocol on TCP 5432.
  - 8organicbits 3y ago
    I think you need the layer4 module to get this working. https://caddyserver.com/docs/modules/layer4 https://caddyserver.com/docs/modules/layer4
avtar 3y ago
stunnel should work for all of the above

deleted 3y ago

[deleted]

gilad 3y ago

MiniCA[0] works for this, quite trivial to setup and stamp out certs. [0] https://github.com/jsha/minica https://github.com/jsha/minica

octagons 3y ago

My preferred solution for this is a combination of Traefik and Smallstep StepCA. I run a collection of tools via Docker compose, and new certificates are issued automatically based on the hostname. The only problem is that I have to maintain a list of DNS entries for the StepCA container as extra hosts. I haven’t found an elegant solution for this part.

seiferteric 3y ago

Cool, but as others said fairly easy to do on your own already. Sort of related but a problem I have been trying to solve is, how to create a trusted certificate for a new device on a private network automatically without any configuration? For example, imagine you are turning up a new router or switch with a Web UI for management. Traditionally this is served on http initially and you can optionally install a cert and enable https. It would be nice to have a way to have this happen automatically to obviate the need for http at all. Also consider that this private network may not be connected to the internet at all and so can't rely on outside servers. I was kicking around the idea for an rfc that would be something like this. Your DHCP server would have an option to act as a CA (or point at one), with ACME protocol enabled. Then, you add DHCP option fields telling clients to trust this new CA certificate, but only for hosts on this local network (to avoid being able to MITM outside connections). Then clients on this network would be able to request certificates from the CA using ACME automatically and others on the network would automatically trust them assuming support for this standard was added the OS or browsers etc.

8organicbits 3y ago
You can get somewhat close to that with getlocalcert. When the device first boots, it calls the getlocalcert API to register a free, anonymous domain name (negative: its a UUID domain, ugly). You'd need outbound connections to api.getlocalcert.net and an ACME certificate authority (Let's Encrypt) to issue a ccertificate. When the user connects to http://<ip-address> http://<ip-address> it redirects to https://<uuid>.localcert.net https://<uuid>.localcert.net, which the browser trusts since the cert is from a public CA. No need to manually trust a cert. The user would bookmark it and all future use is HTTPS-only. If I see usage like this, there's ways I can make this cleaner.
- denton-scratch 3y ago
  > it calls the getlocalcert API to register a free, anonymous domain name ...rather than to get an actual certificate. I didn't dig past the front page, but as far as I can see, they don't issue HTTPS certs at all, easy or oherwise; they offer managed DNS subdomains. You want a cert, you have to get it somewhere else.

denkmoon 3y ago

step-ca is an excellent for running your own private CA with ACME support. Individual software support for defining your own acme directory isn't always there, but such is the life of running your a private PKI. Worst case, you manually issue a cert like you would have done anyway.

donselaar 3y ago

I really hope DANE will become more popular (and widely supported) some time. Works great on air gapped networks without the need for a publicly trusted CA or Let's Encrypt. No ACME daemon to monitor, just put your public key in a DNS record an forget about it.

ori_prior 3y ago
Me too. But the CA and browser mafia is too intertwined to let this change anytime soon.
- drsnow 3y ago
  Are you being facetious or do you actually believe this?
8organicbits 3y ago
> Works great on air gapped networks I've usually seen DANE paired with DNSSEC, and on the internet it feels required. DANE on an air gapped network is new to me, do you just skip the DNSSEC part? I'd be fearful of joining a network that puts bogus DANE TLSA records for google.com, for example. Browser support for DANE is at 0%, unfortunately. https://caniuse.com/?search=dane https://caniuse.com/?search=dane
- donselaar 3y ago
  You're right that DANE kind of implies DNSSEC. Technically it can go without, but it's quite pointless to do because you cannot trust your TLSA record without DNSSEC. DNSSEC works in an air gapped network when you deploy your own trust anchor in your DNS. I wouldn't touch a domain name that you don't own yourself (like google.com) but instead only use a domain name you purchased. It surprises me that DANE is even listed on caniuse.com! I expected it to be way to exotic to be on that list. I'm under no illusion that browsers are going to support this anytime soon unfortunately. Now let's hope I didn't wake up tptacek to lecture us on how DNSSEC is bad and how it will eat your children. ;)

mvip 3y ago

Another approach to solving this problem is to use Tailscale and their new SSL feature [1]. This of course is dependent on that you use Tailscale, but it is pretty handy and does give you a Let's Encrypt cert. [1] https://blog.viktorpetersson.com/2022/12/23/securing-services-with-tailscale.html https://blog.viktorpetersson.com/2022/12/23/securing-service...

mgaunard 3y ago

The web/cloud world is so much nonsense. First, why do you even need HTTPS on a trusted network. Also if you want a trusted network, why not just use IPSec? HTTPS was specifically built to work over the Internet because it was too hard to switch from IPv4. Second, if it's private, surely you can just use your own Certificate Authority, instead of paying a tax to be listed on someone else's Certificate Authority.

pravus 3y ago
> First, why do you even need HTTPS on a trusted network. PCI compliance among many other regulatory issues. You will be required to show that data is not only encrypted at rest but is encrypted through your entire transport chain regardless of any physical security. The threat model assumes that an attacker is able to temporarily access network resources undetected and can use simple sniffing tools to egress sensitive data. This will not be optional.
- mgaunard 3y ago
  That's a whole lot of nonsense. What if you push your data using a custom binary protocol over UDP multicast? Are you suggesting that regulations make it so that everything should be a slow and inefficient https webapp?
dvdkon 3y ago
Trusted networks are a flawed concept, unless you mean a software-backed tunnel. And I'm glad the slightly-less-mad TLS won over IPSEC with some certificate extension.
wolletd 3y ago
Well, because my local instance of <WebApp> says, <Feature> isn't available unless I use HTTPS. Also, HTTPS with a public CA just works on most systems, whereas IPsec requires Client configuration. It's still easier to roll out than switching from IPv4. For personal or experimental things, I may use a local CA, but getting certificates for the internal subdomains of my company is trivial when you already got a public domain on a Server that's capable of using DNS-01 challenges. Enabling HTTPS is just way easier than actually ensuring you can trust your local network. Many real-life middle-class companies start out with just having a network and not thinking about security at all. Some companies may even have untrusted internal networks by choice by allowing BYOD.

3dbrows 3y ago

I wrote about something along these lines a couple of years ago [0] and thought the idea was dead due to rate limiting. But does LE now regard each subdomain as having its own limit, rather than taking that of the parent domain? [0] https://3dbrows.dev/ https://3dbrows.dev/

Jnr 3y ago
The limit can be increased in some cases. https://letsencrypt.org/docs/rate-limits/#a-id-overrides-a-overrides https://letsencrypt.org/docs/rate-limits/#a-id-overrides-a-o...
- 8organicbits 3y ago
  I think options are expanding now. ZeroSSL offers ACME certs without rate limits. You'll likely need to pay them if you're getting more than three.

onion-soup 3y ago

>"Eeasy HTTPS" >Displays somewhat overcomplicated diagram with bunch of arrows and scary technobubble words. Ping me again when HTTPs actually becomes easy

loufe 3y ago

I'm fairly ignorant for certificates, but would anybody here happen to know whether this tech would be easily implemented on a Synology NAS? I enabled HTTPS on a NAS but figuring out how to get a let's encrypt cert or even a locally trusted cert to work seemed more difficult than anticipated.

emadda 3y ago

I released tabserve.dev recently. It gives you a https url for localhost by using your browser as a reverse proxy. Take a look: https://tabserve.dev https://tabserve.dev

throw0101c 3y ago

This leverages the ACME DNS server which has a REST API: * https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns If your DNS provider has an API, you can hook into that for internal-only web servers; this handy code supports several dozen APIs so you don't have to re-invent the wheel: * https://github.com/AnalogJ/lexicon https://github.com/AnalogJ/lexicon * https://pypi.org/project/dns-lexicon/ https://pypi.org/project/dns-lexicon/ * https://dns-lexicon.readthedocs.io/en/latest/user_guide.html https://dns-lexicon.readthedocs.io/en/latest/user_guide.html

8organicbits 3y ago
> leverages the ACME DNS server It's inspired by ACME DNS, but getlocalcert is actually using PowerDNS with a Django API that's compatible. I originally built the tool as a fork of acme-dns, but lost traction somewhere, I switched to pdns and it worked great.

exabrial 3y ago

The whole point of a local DNS and local CA though is to insulate yourself from cloud expenses and failures. Our DNS system has had 0 outages, whereas our Google Fiber uplink has aprox one failure a month (Weather, construction, maintenance, upgrades, unscheduled outages). It's just as easy to deploy a trusted CA using MDM as it is to deploy this.

8organicbits 3y ago
The split-dns setup [1] does a pretty good job of insulating users from cloud failures. Devices on your network use local DNS, no cloud needed. ACME clients start renewing certificates 30 days before expiration, and retry daily. The cloud API would need to be down 30 days in a row for the certificate renewal to fail. It's quite failure tolerant. If Let's Encrypt had an enormous outage, you could switch to ZeroSSL. Caddy actually fails over automatically [2]. Re. MDM, I've never seen a perfect rollout. [1] https://docs.getlocalcert.net/dns/split-view/ https://docs.getlocalcert.net/dns/split-view/ [2] https://caddyserver.com/docs/automatic-https#errors https://caddyserver.com/docs/automatic-https#errors

xrd 3y ago

As others have noted, I'm not sure what this adds unless you cannot use letsencrypt to get wildcard certs. I wrote about that here: https://blog.katarismo.com/2023-06-04-expose-any-private-service-using-headscale https://blog.katarismo.com/2023-06-04-expose-any-private-ser... All my internal and external services inside and outside of my headscale/tailscale network can use a single cert this way. I generate a single cert and then reuse it everywhere.

mr-karan 3y ago

I've a simpler system to use encrypted network for local/private use. - Setup Tailscale on the server and personal device - Deploy apps (self hosted tools that I use) on the wireguard interface created by Tailscale - Deploy caddy as a reverse proxy for all these tools and use `.internal` domain - Use Adguard's DNS rewrites feature to answer custom DNS response for specified `.internal` domains. The A record contains the IP assigned by Tailscale (wg0 interface) for that device. The Caddyfile is as simple as: http://miniflux.karan.internal { reverse_proxy 127.0.0.1:3000 } Using this setup, as soon as I connect to Tailscale, I can access `miniflux.karan.internal` on a secure encrypted network without worrying about configuring HTTPS for local domains or renewing SSL certs.

lazyweb 3y ago

My way of doing private SSL (not necessarily the easiest): * own CA, to be distributed to all systems via Ansible playbook or Dockerfile directives * Hashicorp Vault with enabled PKI engine * Ansible Hashivault module [1] * Ansible role & playbook to tie it all together * CI enviroment for automated deployment of SSL certs to target systems Works flawlessly once set up, including restart/reload of affected services. Might do a writeup on my personal blog at some point. [1] https://github.com/ansible-collections/community.hashi_vault https://github.com/ansible-collections/community.hashi_vault

1vuio0pswjnm7 3y ago

Even easier would be to eliminate ICANN DNS and LetsEncrypt as mandatory dependencies for using HTTPS. If I'm the CA then maybe I know what I want to trust. Not every computer network user has same use cases. One size does not fit all, so to speak. If come computer network users want to use third parties to help them figure out who to trust, then they can do so, it's always an option. But currently there are some companies standing in the way of letting any computer network user determine trust themselves. Currently, delegating trust to third parties isn't optional, it's mandatory.