Live data from Hacker News

Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

techprowd.com

51–60 of 94 posts

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#51
I wrote a similar post about a year ago[0], but even at the time I wasn't the first to come up with this idea. As someone who doesn't have a lot of experiences with DNS security, seeing other people floating similar setups without significant pushback gives me more confidence that the core idea isn't horribly unsafe. I'm pretty happy/relieved to see other people playing around in the same space.

My perspective was (and is) that for portable devices (phones/laptops) that are interfacing with locally hosted services, having SSL for those services is really important because your device probably isn't configured to check what network it's on before automatically pinging 192.168.1.x. This is doubly important if you have other people occasionally hopping onto your network and connecting to those same services. It's imo bad practice to ask everyone connecting to your network to install certificates or set up a certificate manager. I wouldn't do that for any of my personal devices if someone asked me to.

To push this a step farther, I imagined a world where my services could handle not just renewing their own certificates, but also updating their addresses if they were moved to a different network/address. If I build a physical device to give to someone, I'd like them to be able to plug it into their network, go to a web URL, and have everything just work -- no messing around with their internal DNS settings or worrying about whether they're using DNS over HTTPS in Firefox.

[0]: https://danshumway.com/blog/encrypting-internal-networks/

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#52
post #21

Its TLS and not SSL. Its TLS for a long time now... And yes be aware that through this, it works fine but you are also exposing your internal infrastructure details through dns. I'm not seeing a big issue, just be aware of it.

> Its TLS and not SSL. Its TLS for a long time now...

Sure, that's technically correct but a wee bit overly pedantic. When technical people speak about SSL/TLS certificates it's common parlance to say "SSL" and everyone usually knows what you're talking about, which includes TLS, and whatever other new acronym might come down the pipe in the future.

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#53
post #2

Cert-manager has great support for a number of providers[0] including AWS, CloudFlare, Google Cloud, and Azure. I recommend this not just for internal IP setups, for actually for all setups, since DNS verification is more robust than HTTP verification, particularly if you have issues with load balancers, or if Let's Encrypt decides to deprecate a protocol again [1]. [0] https://cert-manager.io/docs/configuration/acme…

I like DNS challenges, but I don't see how it matters for deprecation of an ACME challenge type. The dns-01 challenge could just as easily for some reason need to be deprecated. The two likely reasons for such deprecation would apply just as well: 1. Updated Baseline Requirements or a programme policy requirement at any of the major root trust stores could forbid this challenge or require it to be substantially modif…

Both of those are reasonable concerns, if all other factors were ignored.

However, in practice, the DNS challenge (which demonstrates control over DNS) is greatly preferred over HTTP/TLS challenges (which demonstrate control over a single port).

DNS is likely to be the only way to get a wildcard certificate, and HTTP/TLS will likely end up further restricted once SRVNames in certificates can be gracefully rolled out.

As such, deploying the DNS based control is absolutely the best thing to do, and HTTP/TLS should be seen as legacy-compat fallbacks that may become more difficult in time. Either certificates become less scoped than “entire domain” (as they are today with dNSName SANs) or it becomes more difficult to use a single port to prove authorization for an entire domain.

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#54
post #10
post #2

Cert-manager has great support for a number of providers[0] including AWS, CloudFlare, Google Cloud, and Azure. I recommend this not just for internal IP setups, for actually for all setups, since DNS verification is more robust than HTTP verification, particularly if you have issues with load balancers, or if Let's Encrypt decides to deprecate a protocol again [1]. [0] https://cert-manager.io/docs/configuration/acme…

Verification via DNS is not without issues. If you have more then one DNS server the verification record need to propagate to all servers. If you for example use anycast DNS you will run into issues. Letsencrypt uses Google name servers for lookup which is problematic because they do not behave, they will for example not try secondary dns servers if the first try fail, making the Letsencrypt verification also fail. A…

Where have you seen Let’s Encrypt using Google’s servers?

CAs are required to run full recursive resolvers, up to the root, and can’t just point at someone else’s DNS infrastructure. Which, if you think about it, is what you want: you don’t want the CA just trusting someone else is being honest, you want to go to the authoritative source.

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#55
post #10
post #2

Cert-manager has great support for a number of providers[0] including AWS, CloudFlare, Google Cloud, and Azure. I recommend this not just for internal IP setups, for actually for all setups, since DNS verification is more robust than HTTP verification, particularly if you have issues with load balancers, or if Let's Encrypt decides to deprecate a protocol again [1]. [0] https://cert-manager.io/docs/configuration/acme…

Verification via DNS is not without issues. If you have more then one DNS server the verification record need to propagate to all servers. If you for example use anycast DNS you will run into issues. Letsencrypt uses Google name servers for lookup which is problematic because they do not behave, they will for example not try secondary dns servers if the first try fail, making the Letsencrypt verification also fail. A…

In which case it may be advisable to delegate the acme-challenge record to a different DNS provider, if doing so allows you to sidestep the anycast issues.

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#56
post #4

Keep in mind, adding local entries to your external DNS will expose internal details of your network, such as hostnames and IPs. Same goes for Let's Encrypt, due to Certificate Transparency logging.

While you'll get the hostnames leaked - you could register them as fake addresses (say an A record for 192.168.0.1 for every address), and have a local DNS server overriding with the real addresses. Whether this is worthwhile or not is debatable. Is the fact your internal server 'gubbins.mydomain.com' exists, or even that it exists on 10.0.41.43 really much use? The other option for internal certificates is to get a…

[deleted]

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#57
inlets with the inlets-operator [0] does this by using the HTTP01 challenge, and gives you a LoadBalancer just like you'd have on AWS. The benefit is that you get a real IP and routable traffic, there's no tricks required. It would also work with DNS01 if that's of interest.

[0] https://github.com/inlets/inlets-operator

Feel free to check it out in this tutorial: https://docs.inlets.dev/#/get-started/quickstart-ingresscont...

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#59
post #21

Its TLS and not SSL. Its TLS for a long time now... And yes be aware that through this, it works fine but you are also exposing your internal infrastructure details through dns. I'm not seeing a big issue, just be aware of it.

I know the difference, but common usage is to refer to the whole group of protocols as SSL.

I have yet to apt-get install opentls on any webserver.

Post reply on HN