Should you use Let's Encrypt for internal hostnames?

I've used https://smallstep.com/docs/step-ca/ as a CA internally, works well.

What I'd want is an internal CA, like step-ca, but have the certificates signed by a "real" CA, so I don't have to distribute my own root CA certificate.

I've been setting this up for my homelab under .home.arpa, seems to work pretty well so far.

The dream would truly be an internal CA backed by a publicly trusted subordinate cert (limited to the domain you control). But afaik that can’t happen until the Name Constraint Extension is enforced by “all” clients.

Wouldn't that allow you to issue certificates for Google.com? Correct me if I've misunderstood but for the sake of discussion pretend cert pinning doesn't exist, use another example domain if it's easier

That would be a violation of the real CA's duty to only sign certs that they have some basis for believing are correct. (This basis almost always boils down to "controls the DNS".)

I'm not a 100% sure how certificates work. What I imagined would be possible is having a certificate for mydomain.com, which can be used to sign certificates for subdomains.

I've been using it too and it works well, particularly with Caddy to do automatic certificates with ACME where possible

Plus all my services go through Tailscale, so although I am leaking internal hostnames via DNS, all those records point to is 100.* addresses

I'm a fan of both Caddy and Tailscale; any chance you have any devnotes to share on your setup?

Yeah, that is the major drawback.

Out of curiosity, What's the problem with distributing your own root CAs? Is it security? Or is it "just a PITA"?

Mostly the second.

This is the correct answer ;)

If you're going to run a serious internal network, you'll need the basic things like NTP, DNS, a CA server, and, yes, some kind of MDM to distribute internal CA certificates to your people. The real PITA is when you don't have these in place.

This would be called an "Intermediate CA" to those for whom this is unclear.

> But afaik that can’t happen until the Name Constraint Extension is enforced by “all” clients.

For those curious about this extension, see RFC 5280 § 4.2.1.10:

* https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10

You really don't actually want this. This intermediate CA would still be subject to the same extensive CAB Forum / vendor root program requirements (audited yearly via WebTrust) as a root CA. There are a ton of requirements, including mandatory response times, that inevitably makes this require a fully staffed team to operate.

My notes were pretty rough but I've tried putting them into a gist here:

https://gist.github.com/mojzu/b093d79e73e7aa302dde8e335945b2...

Which covers using step-ca with Caddy to get TLS certs via ACME for subdomains, and protecting internal services using client certificates/mtls

I then install Tailscale on the host which is running the docker containers, and configure the firewall so that only other 100.* IP addresses can connect to ports 80/443/444. The combination of VPN+MTLS mitigates most of my worries about exposing internal subdomains on public DNS

You can put "name constraints" on an intermediate that, in theory, can restrict the intermediate to only signing certs for a particular subdomain. In theory, name-constrained intermediate certificate for `.example.com` would have no more authority than a wildcard certificate for `.example.com`.

But, name constraints are enforced by "relying parties" -- HTTPS/TLS clients & servers that are validating certificates and authenticating remote peers. In practice, there's a risk that a broken/misconfigured relying party would trust a cert for google.com signed by an intermediate that's name constrained / only trusted to issue for `*.example.com`.

Awesome, thanks!

Tailscale+TLS: isn't it two strong layers of encryption?

Yeah, it's probably overkill but I think the multiple layers would help in cases I misconfigured something or if an account someone uses to log into Tailscale was compromised. For example when I ran the containers on a linux host I discovered later docker was bypassing the firewall rules and allowing all connections, but it probably wasn't a big deal because of the MTLS (and the server was behind a NAT router anyway so it was only addressable within the local network)