[dead]
TLS certificates for internal services done right
81–90 of 177 posts
Re: TLS certificates for internal services done right
#82Earlier quoted context omitted.
I never understood the issue with DNS-01. if you have a process that you trust to maintain a zone's TLS identity what is the big deal about letting it control a record in that zone?
You can even put it in a seperate zone (which I do) by using a CNAME for _acme-challenge.domain.tld. I have it to a seperate subdomain, which is served by a seperate desec.io account, which is only used for this specific subdomain.
[dead]
Re: TLS certificates for internal services done right
#83Earlier quoted context omitted.
Once dns-persist-01 becomes available/usable[1], it should make dns validation even easier. [1]: https://letsencrypt.org/2026/02/18/dns-persist-01
I never understood the issue with DNS-01. if you have a process that you trust to maintain a zone's TLS identity what is the big deal about letting it control a record in that zone?
We have a few subdomains for white labeling 3rd party SaaS where we do what is basically the AWS ACM equivalent and add a persistent record from a vendor.
With this setup, I don't have to grant 3rd parties DNS access.
I actually made a webhook that allows per hostname API keys to wrap dnsimple because they only had per zone keys and I didn't want each VM to have access to the entire zone. These challenges would have solved that by allowing the DNS record automation to pull record values from the VM instead of having the VMs push values.
I think someone told me dnsimple might have more granular keys now but I haven't checked. Iirc we have the same concern with external-dns at work (some things need subdomains on the TLD but we don't want to give external-dns access to the whole zone so we usually cname the TLD subdomain to a per environment zone external-dns is allowed to update). With this, we could have the same pull based setup that applies arbitrary rules to decide if a requested record should be created.
I think the main takeaway is allowing pull instead of push model
Could be achieved with cnames but it's an extra layer of indirection to deal with and doesn't fully solve the "semi trusted 3rd party" case
Re: TLS certificates for internal services done right
#84Earlier quoted context omitted.
On k8s, there's cert-manager but also you need k8s... Most browsers support trust on first use for leaf certs
Well, if your cert-manager distributes its own CA, you'd still need the clients to trust the CA, even in k8s.
True but you can have cert-manager issue public certs then create service accounts for off cluster things to be able to pull the cert from the Secret so k8s+cert-manager acts as a local broker that handles renewal.
You can also invert and have k8s cronjobs provision the generated certs into other infra
With this setup, you don't have to worry about the RHEL certbot snap updating to a broken version which gets blocked by SELinux...
Re: TLS certificates for internal services done right
#85Or... - Don't use split DNS. Don't use any special internal or dev domain. Leave it to your infrastructure to route/NAT those public IPs to your internal network. - Don't use the HTTP-01 challenge. Use DNS-01. - Don't run your own internal CA. Use Let's Encrypt. If you care about name leakage (CT Logs), use wildcard certs. Use a central reverse proxy/load balancer for termination.
Let's encrypt is great but if you operate any kind of scale you can quickly hit their rate limit. AWS only recently started allowing you to pull the certificate out of ACM.
Re: TLS certificates for internal services done right
#86Earlier quoted context omitted.
On k8s, there's cert-manager but also you need k8s... Most browsers support trust on first use for leaf certs
I guess I mean treat it as a clear first class feature. Right now most browsers treat it as an arcane error. I’m thinking more “This is the first time you’re connecting to this site. Do you trust it?” And later if something changes, then they can do the whole DOING SOMETHING NASTY! thing, which is effectively the experience today
Yeah, that's fair. I think they're optimized for non technical users without a decent escape hatch.
Re: TLS certificates for internal services done right
#87The real answer here is that configuring HTTPS clients to trust a self-signed cert (or signed by an internal CA) shouldn't be as difficult as it is. I find it extremely annoying that every programming language has it's own idea of where certificates should live instead of just checking the os trust store.
Is there a commonly used language other than Java that doesn’t just defer to the OS trusted CAs by default?
Python for example, although nowadays you can simply install pip_system_certs to change that behaviour.
A lot of non-language tools bring their own certificate bundle as well, like uv, git, curl and Firefox. (I think they might all be the same Mozilla bundle even).
However, it seems like the situation here has improved slightly: git can read Windows certificates now once a flag has been set, Firefox has a flag for Windows and macOS, and it supports p11-kit. curl can be built with Windows/macOS support and respects OpenSSL environment variables. uv can be configured to use system-certs.
And obviously any VM or container has to be set up separately. That often includes stuff like pipelines in forges. As mentioned in the sibling comment, at least here it's definitely by design.
Re: TLS certificates for internal services done right
#88Hmm. I don't really care enough about leaking home network host names because they are all super generic names like 'router', 'laptop', 'tv', 'nas'. So I use my public zone on cloudflare. I just use internal ip addresses (eg: nas.example.com = 10.1.2.3) on the public zone and DNS01 challenge for let's encrypt. Anyone can resolve the ip for any of my hosts, but obviously you'd need to be on the wireguard vpn to hit th…
Fair, but what about names that are specific enough to give an attacker a clue to a potential attack surface, like "authelia.example.com" - now they know you've likely got an Authelia setup, and can start digging for exploitable CVEs etc. I'm in the process of removing all my individual certs and replacing with a wildcard cert served by Traefik. Is that a bad idea?
How many people out there have attackers doing individualized research to identify services on their home LAN so they can chain a network attack with CVEs in their self-hosted service?
Re: TLS certificates for internal services done right
#89Personally, I hate split horizon DNS. I prefer the "BeyondCorp" model. I MUCH prefer putting an mTLS cert in my trusted devices over relying on VPNs in same devices. I've yet to see a "clever" DNS setup not cause annoyances. Specifically grafana is nice to be able to see on the phone, and split horizon DNS and corp VPN is a hassle, to say the least, on phones. I bet you can do it with HA-Proxy, but I use https://gith…
Zero trust or bust. I actually cringed when I read "done right" applied to split-horizon DNS.
Re: TLS certificates for internal services done right
#90Bogus nonsense. Sign your internal certs with an internal CA, make your clients trust the CA. Use it properly.