Over the last few months, I’ve worked in collaboration* with several experts in our niche field of TLS development+deployment to produce the first codified set of guidelines for automated TLS certificates:
It may worth indicating that having multiple names in the same certificate can increase performance because there is no need to renegotiate a TLS connection if it’s the same IP/server behind all names.
Maybe insisting on the fact that the OCSP response must be renewed before the last minute (halfway through the validity period is recommended by https://gist.github.com/sleevi/5efe9ef98961ecfb4da8 ) so in case of revocation, the old stapled response is still valid ling enough to have time to renew without downtime. Related: https://github.com/certbot/certbot/issues/1028 (I have in mind the case of a mass-revocation, where a lot of client renew at the same time, and some renewals may fail because of the overload, so it needs to have a safety net of at least a day)
Good point, although honestly, in years of practice I have never known of substantial benefits from this – or heard even one request/complaint about this. For example, a CDN with 100 names on a cert could in theory benefit if the client happens to visit many of those sites but usually the names on the cert are not related, and if they are, the client might only visit a couple of them. So we’re talking a time savings of a few ms every few minutes. It definitely can be an optimization, but it’s a niche one to be sure.
I like this idea. It’s interesting how prophetic but that issue and this doc were in the case of the recent LE bug (by pure chance, of course – which also extends to single-SAN certs by the way!). In fact, we’ve since proven this advice by experience, as Caddy/CertMagic were (AFAIK?) the only clients guaranteed to be unaffected by the CAA rechecking bug (first, because they are not multi-SAN certs, and second, even if they were affected, Caddy/CertMagic would renew the impacted certificate before the Valid staple expired).
There is at least one caveat, and that is some clients don’t honor OCSP staples over their own revocation lists. For example, Safari (I think?) – actually, Apple as a vendor – dispatches their own revocation lists to their clients, and I believe they receive priority over a signed and stapled OCSP response, even! But yes, definitely if the server is watching the OCSP status and finds a revocation, doing an immediate replacement should at least minimize that window if there is one at all. I’d be surprised if a period check every few hours was that much faster than Apple’s propagation speed.
Also a good point – pending the caveat noted above – but would you mind opening an issue/PR to suggest it? We can at least discuss it.
I’m thinking more about a website, www.example.com how redirects to example.com and then loads assets from static.example.com and requests api.example.com
If the visitor is on another continent, each TLS negotiation needs at least 100ms so in that example, the website can’t display anything in less that 300ms lost only in TLS negotiation.
And, to be fair, your doc did talk about the opposite: “Multi-SAN certificates also have a larger size, so they slow down TLS handshakes.”, which is less likely to happen as they will only slow down the request if they increase the number of packets sent.
we need to develop a protocol to notify Subscribers’ systems of imminent certificate revocation, so those Subscribers can automate the process of replacing affected certificates before the deadline. We plan to design this protocol publicly, in collaboration with the PKI community, so that any CA and any Subscriber can implement it. We will also collaborate directly with popular ACME clients to integrate and test such automated replacement.