This doesn't get brought up enough but a Name Constraint on a root cert lets you limit where the root cert can be signed to. So instead of this cert being able to impersonate any website on the internet, you ratchet it down to just the domain (or single website) that you want to sign for.
https://github.com/FiloSottile/mkcert/issues/131
https://github.com/FiloSottile/mkcert/pull/113
Hopefully Filippo revisits this now that it's broadly supported.
I've been shopping a talk since then about how to set up a name-constrained root certificate, and what it should look like. It's still hard! CFSSL is my go-to tool, and it doesn't have support. I had to fork it to make it work. OpenSSL has support, but it's configuration is like all OpenSSL configuration - Poorly documented and nonstandard, mixing INI objects and object-refs.
> When generating a CA cert via caddy and putting that in the trust store, those private keys can also forge certificates for any other domain.
RFC5280 (2008) "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" > Section 4.2.1.10 Name Constraints: https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.... :
> The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located. Restrictions apply to the subject distinguished name and apply to subject alternative names. Restrictions apply only when the specified name form is present. If no name of the type is in the certificate, the certificate is acceptable.
> Name constraints are not applied to self-issued certificates (unless the certificate is the final certificate in the path). (This could prevent CAs that use name constraints from employing self-issued certificates to implement key rollover.)
I’d rather be able to further constraint at the cert store though.
OpenSSL is powerful, but it's hard to figure out how to use correctly. Each command seems cryptic no matter how many times I use it.
The step CLI is a lot simpler, even though it has a few quirks: generating PKCS1 formatted private keys instead of the newer PKCS7 format, making every leaf certificate eligible to be either a server certificate or a client certificate, and absurdly low default certificate expirations.
openssl genrsa -out private.key 4096 && openssl req -new -key private.key -out signreq.csr -subj "/CN=FQDN" && openssl x509 -req -days 365 -in signreq.csr -signkey private.key -out cert.crt
But ideally everyone could just use something like mkcert to take care of this
Initial setup is a handful of commands interacting with Vault's CLI, from there, with CI in place, client certs are renewed automatically. Services are restarted / reloaded as well. Works flawlessly.
I should maybe write a (small) blog explaining how it works.
The spec (RFC 7250, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)") suggests DANE/DNSSEC as a mechanism to bind identities to public keys (section 6).
https://datatracker.ietf.org/doc/html/rfc7250
Will this really be simpler?
