HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 17:58 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
In reply to: HTTPS-only mode (is briefly mentioned and I recommend to LWN readers) by dskoll
Parent article: Firefox 127.0 released

> No, each time the cert needs to be updated, the network admin would rsync the wildcard cert to specific servers via SSH.

A lot of services read the certificate once during startup, so you also need to restart them. Then you also have services that store the certificate in some kind of a database. And dockerized services that might need an image rebuild.

It's really not that easy. For my home network, I just bought a 5-year wildcard certificate for $100, so I don't need to worry about rekeying everything. But that's really not a lot of security.

I wish SSL were hierarchical, so that I could sign my own subcertificates for individual domain names. Sigh.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 18:14 UTC (Thu) by farnz (subscriber, #17727) [Link] (3 responses)

I'd love it to be possible for LetsEncrypt to sign my private CA for 30 days, conditional on my CA only issuing certificates for my domain names (as verified by LE), while allowing my CA to be valid for 20 years.

The idea is that anyone who trusts LE only trusts certs I've issued (or my CA) for 30 days after the LE signature, but if I can persuade you to import my private CA cert, you trust certificates I issue until their expiry date (or my CA's validity date, whichever comes first).

The other thing I'd like in X.509 is the ability to have multiple chains from a certificate to a CA; it'd be nice to be able to have a single certificate that was verified via the LE chain (for public visitors), and verified via my private CA (so that I trust it even when the LE signature has expired, making it easier to replace the LE chain every 30 days).

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 19:47 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

This technically can be expressed in today's X509!

You use your private infrastructure to sign certs, and specify the URI of your CA in: "Authority Information Access - CA Issuers - URI" extension field. Then this URL can return a certificate that is signed by the Let's Encrypt CA. You simply update this certificate once the signature expires. And your CA is in turn limited to your domain via the "Name Constraints" ( https://datatracker.ietf.org/doc/html/rfc5280#page-40 ) extension.

Now to bad news: name constraints fail open. This makes them a non-starter for any realistic applications. They must be redesigned to fail-closed, if a library doesn't understand them, the certificate validation should fail.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 22:19 UTC (Thu) by intgr (subscriber, #39733) [Link] (1 responses)

> name constraints fail open. This makes them a non-starter for any realistic applications.

I believe this is not correct. Every extension (such as Name Constraints) in a cert has a boolean flag called "critical".

Non-critical extensions may be ignored by implementations if they are not recognized (fail open). But the presence of unrecognized critical extensions will make the cert immediately invalid (fail closed).

It's up to the parent CA to mark the constraints as critical.

Of course there may be implementations that interpret Name Constraints incorrectly but that's another matter.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 13, 2024 22:41 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

I've seen X509 implementations that ignore critical extensions (or even things like SANs).

Proper modern implementation of restrictions would need to include something that poisons certificate validation for incorrect implementations.

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 15, 2024 2:20 UTC (Sat) by dskoll (subscriber, #1630) [Link]

A lot of services read the certificate once during startup, so you also need to restart them

Yup, that's also scripted. It's a bit of a pain to set up, but once it's set up, it just runs on its own. Basically, each machine has a script that knows how to reload relevant services if a certificate has been updated; the sync script runs that script iff the cert has actually been updated.

And dockerized services that might need an image rebuild.

"Doctor, it hurts when I do that!" "Then don't do that!"

HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)

Posted Jun 15, 2024 3:24 UTC (Sat) by intelfx (subscriber, #130118) [Link]

> And dockerized services that might need an image rebuild.

Huh?

Please don't tell me you're baking secrets into docker images?