Guide to best practices for ACME clients

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 :slightly_smiling_face:

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.

Good to know, it was @schoen's question in Ability for Automated Notification of Revocations - #10 by schoen !

And from 1619179 - Let's Encrypt: Incomplete revocation for CAA rechecking bug :

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.

Sure, done: Explaining why/when must-staple can be useful regarding the threat-model · Issue #2 · https-dev/docs · GitHub

1 Like