←back to thread

Should you use Let's Encrypt for internal hostnames?

(shkspr.mobi)
238 points edent | 1 comments | 05 Jan 22 12:42 UTC | HN request time: 0.247s | source
Show context
meepmorp ◴[05 Jan 22 14:11 UTC] No.29809113[source]▶
I've used https://smallstep.com/docs/step-ca/ as a CA internally, works well.
replies(4): >>29809289 #>>29809335 #>>29810148 #>>29811399 #
mrweasel ◴[05 Jan 22 14:25 UTC] No.29809289[source]▶
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.
replies(7): >>29809419 #>>29809851 #>>29809903 #>>29810475 #>>29810488 #>>29811401 #>>29812390 #
corobo ◴[05 Jan 22 15:07 UTC] No.29809851[source]▶
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
replies(1): >>29809984 #
mrweasel ◴[05 Jan 22 15:19 UTC] No.29809984[source]▶
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.
replies(1): >>29816034 #
1. mmalone ◴[05 Jan 22 22:31 UTC] No.29816034[source]▶
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`.