EasyRSA. Install the CA on my devices, distribute the SSL certs to the devices I care about. (Mainly NAS, OctoPi, PiHole). The me PiHole serves hostnames too, and DHCP.
Ask HN: What's your solution for SSL on internal servers?
21–30 of 79 posts
Re: Ask HN: What's your solution for SSL on internal servers?
#22I have my own 2T PKI.
Pro: you would know how some apps crash (and sometimes burn) when PKI breaks. Also you would know what every other distro guy thinks he is smarter than everyone and do the PKI his own way.
Cons: see Pro.
NB: Windows PKI in the ADDS environment (at terms of distributing the RCA/ICA trust) is a walk in the park compared to everything else.
NB2: Java keychain is PITA.
> Behind home routers, it's still a tedious topic
Buy a domain, park it at Cloudflare/Ghandi/whatever ACME supported provider, use DNS-01, push or pull certs to the local network.
There is no problem with the process, only with laziness and automation.
Re: Ask HN: What's your solution for SSL on internal servers?
#23Earlier quoted context omitted.
Then you're routing internal traffic through a public IP? Or do they support wildcard certs?
I have local DNS setup to resolve my personal domains to hosts on my home network. They do support wildcard certs, _only_ if you use some form of DNS challenge.
I'll try to do this for internal IPs using traefik on Kubernetes. Any pointers?
Re: Ask HN: What's your solution for SSL on internal servers?
#24Earlier quoted context omitted.
SSL certificates contain the name, not the IP. So the IP address can be anything, including internal ones.
I thought Let's Encrypt wouldn't give you a cert if the domain on the cert resolves to a private IP. Good to know - thx.
You just resolve the domain to a private IP on your internal network, Let's Encrypt can see it as whatever you want, for all they care it's 1.1.1.1.
Re: Ask HN: What's your solution for SSL on internal servers?
#25Earlier quoted context omitted.
SSL certificates contain the name, not the IP. So the IP address can be anything, including internal ones.
I thought Let's Encrypt wouldn't give you a cert if the domain on the cert resolves to a private IP. Good to know - thx.
You can, but you might not want employeerecords.example.com leaking its IP address, even if it is an inaccessible 192.168.10.10. Defense in depth. You can use hosts or internal resolution.
Re: Ask HN: What's your solution for SSL on internal servers?
#26Earlier quoted context omitted.
SSL certificates contain the name, not the IP. So the IP address can be anything, including internal ones.
I thought Let's Encrypt wouldn't give you a cert if the domain on the cert resolves to a private IP. Good to know - thx.
I’ve got a ton of certs from LE where the IP resolves to an RFC 1918 IP
Re: Ask HN: What's your solution for SSL on internal servers?
#27I'm using subdomains on a domain I own and request Let's Encrypt certificates with the DNS challenge.
Then you're routing internal traffic through a public IP? Or do they support wildcard certs?
>Then you're routing internal traffic through a public IP?
No, not typically. There's various methods to do the LetsEncrypt challenge/verification that don't require internet connecting the internal host you're generating the certificate for.
The downsides are:
- You can generate a wildcart cert for *.internal.yourdomain.tld. But then, it's a pretty big master key if you lose control of it.
- You can generate a cert-per-server but it exposes your hostnames (at least) in certificate transparency logs, which gives outsiders some view into how big your internal network is, perhaps some detail on what it's like via hostnames, etc. This is worse if you also expose the internal DNS records externally, then everyone sees those records as well, exposing more internal info. You could mitigate these things somewhat with various strategies around hostnames, DNS setup, etc.
Re: Ask HN: What's your solution for SSL on internal servers?
#28Earlier quoted context omitted.
I have local DNS setup to resolve my personal domains to hosts on my home network. They do support wildcard certs, _only_ if you use some form of DNS challenge.
I'll try to do this for internal IPs using traefik on Kubernetes. Any pointers?
I just use unbound where I have a ansible script install it from the arch repos and deploy a handwritten config file with the dns entries. Then it forwards the rest to my DNS provider. I have my router set the address of that unbound host as the DNS server for my devices via DHCP.
I don't use k8s in my home network (though I do have some podman containers), but there's probably something with more k8s integration you can tie into your k8s ingress setup that I'm unaware of.
Re: Ask HN: What's your solution for SSL on internal servers?
#29I have a private CA for all internal hosts. It's a bit of a pain to run, but it's neccessary because "internal" includes VMs that run colocated servers and many services to mutual authentication.
It's hyper annoying that it's barely to not possible to include our own CA into mobile Browsers so that they can use internal websites.
The alternative would be to depend on LE where neccessary, but this introduces an external dependency that I would rather avoid.
Re: Ask HN: What's your solution for SSL on internal servers?
#30For a long time I was all fussy about having to create a security exception for self-signed certificates. One day I realized I was acting insane, as if there was some glorious principle involved. There isn't. I trust my own (or coworkers) certificates. It's a dev site for heavens sake. Ever since, ssh-keygen all the way.
It can be tricky to get self-signed certificates put into all the various places where they need to be. OS level certificate stores, browsers, mobile devices, curl, python/requests, VPN clients, etc. There's always some weird exception case.
Yeah, I think OP probably mostly does web development through the browser, where there’s just one trust store to worry about.
As soon as you need some automation involving backend services or even just curl and some scripts, this gets tougher. (And please please don’t use `curl -k` to disable checks… if such scripts accidentally make their way to production, you may as well not use TLS at all.)