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

Post by [deleted] » Thu, Sep 03, 2020, 8:14 PM UTC

e12e wrote: post #81

throw0101a wrote: post #75

Earlier quoted context omitted.

The way it works for us: First we use standard LE/ACME clients: either certbot or dehydrated. They ask for something like svc1.int.example.com ($DOMAIN). In the hook script(s)† we manipulate the $DOMAIN string to put it into dnsauth.example.com ($AUTH_ZONE) sub-domain and send that new string to the DNS server that handles the dnsauth zone (and only that). Before all of this we would have set up, in our public-extern…

Ok, thank you for the details and managing expectations. This still seems to warrant some experimentation. In my case I'm mostly interested in delegating a domain/sub-domain somewhere I can easily update (be that run my own dns, host it somewhere with an api) - while having my main domains on a more boring/static dns infrastructure - yet still easily get certs for things like imap.example.com - which would not run a…

Post by sroussey » Thu, Sep 03, 2020, 10:40 PM UTC

sleevi wrote: post #53

tialaramex wrote: post #13

Earlier quoted context omitted.

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.…

Post by sroussey » Thu, Sep 03, 2020, 10:50 PM UTC

sleevi wrote: post #85

sroussey wrote: post #84

Earlier quoted context omitted.

But can’t DNS queries be altered man in the middle style?

I’m not sure your point? Any HTTP/ALPN request first begins with DNS, so if you’re trying to compare those, they all share the same base issue. In theory, this can be mitigated by DNSSEC, but that’s not relevant when comparing these validation methods. However, both the HTTP and ALPN methods only demonstrate control over a single port (or .well-known resource), while the DNS method demonstrates the full ability to al…

Post by [deleted] » Fri, Sep 04, 2020, 5:07 AM UTC

MertsA wrote: post #45

pm90 wrote: post #8

Earlier quoted context omitted.

In this case, I don’t think there is a gateway involved at all. I believe Let’s encrypt is verifying the authors domains by (essentially) querying their selected DNS provider to prove ownership over a domain, which resolved to a private IP. So iiuc there is no split horizon, it’s just that the sites would only work for the author.

The host names wouldn't even need to resolve at all outside of the local network. Only the challenge subdomain _acme-challenge.foo.bar.org so certificate transparency will of course expose the existence of foo.bar.org but it wouldn't need to expose anything at all about those DNS records if you wanted to restrict them to only the local network.

Post by Schwan » Fri, Sep 04, 2020, 1:00 PM UTC

teh_klev wrote: post #52

Schwan wrote: 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.