Comment by justin_oaks
3 years ago
How do you define "properly"? What are some of the things someone can do wrong that Let's Encrypt does correctly?
3 years ago
How do you define "properly"? What are some of the things someone can do wrong that Let's Encrypt does correctly?
Root certificate stored on offline HSM and intermediates on secure infrastructure. FIPS compliance. (Relatively) reliable revocation services. [See note 0]
The result is security of issuance, that is near complete confidence that certificates will only be used for controlled domains (not necessary if you want to MITM of course).
Also, ACME is generally easier and more reliable than other certificate rollover processes I've seen. I'm not sure if there's in-house PKI tools supporting it?
Depends on your organisation size though. Maybe your in-house PKI is fine, but it's not for everyone!
[Note 0] Revocation is of course a mess. Let's Encrypt isn't without fault either, particularly when used internally, since OCSP responders will need to be accessible from client devices.
I mean sure but an org doesn’t really need that much security. If you’re not taking that much care with your API keys and db passwords then you probably don’t need it for certs either. Keep your root CA offline and in an air gapped backup, issue team specific intermediates with med length and keep your endpoint certs short.
You need as much security on your CA as the accounts in your org with the authority to replace them with your provisioning tools.
That reasoning goes back around. If you don’t need that much security and are fine with exposing internal hostnames via CT logs, then Let’s Encrypt can be nicer (no internal CA to maintain).
It’s just that very specific bit in the middle, where you don’t want to expose the internal hostnames but don’t need top-tier security where having a private CA is worthwhile (assuming outbound internet connectivity to Lets Encrypt is allowed).