Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

techprowd.com

Post reply on HN
Print view View original

71–80 of 94 posts

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

#71

Post by e12e »

throw0101a wrote: post #67
z3t4 wrote: post #10

Earlier quoted context omitted.

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…

> If you for example use anycast DNS you will run into issues. You're not wrong, but this assumes that you use the your 'service hostname' for verification as well, rather than using CNAMEs. So let us say you want to have " svc1.example.com " in your cert: you could put the ACME challenge under there, but if you have anycast delays that's a problem (as you mention). (A kludge is putting a 'sleep' somewhere to allow f…

Oh, this is an interesting trick... I think I'll need to investigate further.

Do you use a custom acme/dns updater for automatic renewals?

[ed: ie - if I understand correctly, I could point: _acme-challenge.example.com via CNAME to auth.other.example.net - but then I'd like a command to check renew my example.com certs - and it would ideally use an api/dns update to manipulate the auth.other.example.net TXT (or CNAME to something like a15ce5b2-f170-4c91-97bf-09a5764a88f6.auth.acme-dns.io) record when I ask for a check/update of '*.example.com' certificate.

As far as I'm aware, most tooling assumes that you can/will (programmatically or manually) update the _acme-challenge.example.com record directly when issuing/updating an example.com certificate?]

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

#72

Post by darkarmani »

viro wrote: post #62

Honestly this feels overly complex when you can just create a CA and add the CA to ur devices. Still cool tho.

You don't want to be running a CA. Because devices don't implement "name constraints", once you import your CA Root cert into a device, all HTTPS communications on that device can be subverted if someone gets ahold of your Root CA's cert/private key.

I find it incredibly annoying that i can't tell chrome to use THIS CA Root Cert only for *.mydomain.com and not my banking domains, email, etc.

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

#73

Post by darkarmani »

iso1210 wrote: post #46
tialaramex wrote: post #39

Earlier quoted context omitted.

I don't want to trust your certificates in my browser, even if you invent all sorts of sophisticated technical hoops to jump through I have no reason to believe you actually did all that hoop jumping. Get certificates for the names you want from a PKI we both trust. The only one that's likely to be applicable is the Web PKI, which is what was done in this article. For some other purposes, where the Web PKI isn't appl…

Yes, I generate a client cert and give it to you, that's not a problem - you aren't trusting the cert at all. I can secure my servers with my own CA, again that's fine - I trust myself. If you want to verify my servers signed from my CA though you would need to trust my CA. Currently that means you would need to import my CA's root certificate. That's bad, it's also the way many corporations work, I've had third part…

> For some reason browsers don't allow that - it's all or nothing.

Absolutely. Name constraints. It's in the spec, but no one seems to implement it. This would fully make PKI useful. Typing x509 certificate (validation) to a delegated domain would allow people to import Root CAs from a variety of places while compartmentalizing security.

Right now, if you trust a Root CA cert, you trust any domain it signs. This has been a glaring problem for years. I never thought we'd have cheap certs for everything and LE came along and blew my mind.

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

#74

Post by darkarmani »

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.

Good point even if it is pedantic. I shift between terms depending on my audience, but try to use TLS in technical circles as an example.

I worry that I'll forever have to use both terms, because while SSL is the term that communicates better to semi-literate audiences, I worry that some security expert will assume I don't know anything because I'm using the "wrong" term.

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

#75

Post by throw0101a »

e12e wrote: post #71
throw0101a wrote: post #67

Earlier quoted context omitted.

> If you for example use anycast DNS you will run into issues. You're not wrong, but this assumes that you use the your 'service hostname' for verification as well, rather than using CNAMEs. So let us say you want to have " svc1.example.com " in your cert: you could put the ACME challenge under there, but if you have anycast delays that's a problem (as you mention). (A kludge is putting a 'sleep' somewhere to allow f…

Oh, this is an interesting trick... I think I'll need to investigate further. Do you use a custom acme/dns updater for automatic renewals? [ed: ie - if I understand correctly, I could point: _acme-challenge.example.com via CNAME to auth.other.example.net - but then I'd like a command to check renew my example.com certs - and it would ideally use an api/dns update to manipulate the auth.other.example.net TXT (or CNAME…

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-external DNS, a CNAME record to point svc1.int to svc1.int.dnsauth.

The ACME client only thinks about $DOMAIN and the cert-issuing LE server only thinks about $DOMAIN. But the "in between" does not: by doing text manipulation (expr(1) is handy in shell scripts), and DNS redirects, the "in between" uses not-$DOMAIN for verification, but rather TXT records in $AUTH_ZONE.

All with standard ACME clients and some jiggery pokery.

We ended up creating some custom scripts called via SSH, but there are (now) DNS servers written specifically to handle REST API calls [0] and one can use lexicon [1] for just about any commercial DNS service.

[0] https://github.com/joohoi/acme-dns

[1] https://github.com/AnalogJ/lexicon

† dehydrated has deploy_challenge() and clean_challenge() functions in its example hook script. I'm sure most ACME clients have something similar.

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

#76

Post by j45 »

windexh8er wrote: post #70

I do this with Traefik [0] internally in almost the same way. I use DNS-01 to get a Let's Encrypt wildcard cert and all my internal A records point to the ingress IP and Traefik happily proxies the communications to the appropriate service - container based and non-container based - which is the real win I was looking to solve for in my home environment. The thing I like about just using Traefik is it doesn't rely on…

Appreciate this breakdown, I've been using an nginx proxy to hold a few things over and wanted to move in the direction of a managed service, which Traefik looks perfect for.

As time goes on the value of having services running as appliances is becoming more and more valuable.

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

#77

Post by Hamuko »

aforwardslash wrote: post #3

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.

I've solved the IP exposure issue with CNAME records and a local DNS server. So if I want to run a Plex server at example.com, I'll set plex.example.com to be a CNAME for plex.internal and just have the local DNS server resolve what IP address plex.internal is at. Easy way to get HTTPS addresses for internal IP addresses without having the IP address listed publicly.

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

#79

Post by DenseComet »

pas wrote: post #27
swiley wrote: post #14

I’ve tried to set up kubernetes at home a couple of times and I always freak out at the amount of layers and “just run this” style of tutorials. Am I crazy? I’ve heard guix has some kind of container management thing. I’ve been thinking about trying it anyway.

k8s needs a control plane, that needs security, hence all the tokens, certs (which need internal and external IPs and FQDNs), also it needs to set up an overlay network (so you need to configure the CNI provider, sysctl stuff for ebtables and iptables/nftables to work correctly), and DNS, and a dashboard would be nice too. oh, and unless you use k3s or something that budles a container runtime (CRI provider) you need…

The k3sup project [1] takes this a step further and makes installing k3s even easier. k3s has been the most useful piece of infra I run at home. It gives me all the benefits of k8s with none of the complexity.

[1] https://github.com/alexellis/k3sup

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

#80

Post by duskwuff »

aforwardslash wrote: post #3

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.

You don't need to add those entries to your external DNS. It's possible to create and validate Let's Encrypt certificates for names which don't exist in public DNS, and use split-horizon DNS to define them on your local network.
Post reply on HN