You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a server is terminating TLS for many logical servers with lots of different DNS names it will need to manage a lot of certificates. When the number of certificates becomes large the server needs to create an index to find which certificate chain (and private key) to use, given the SNI from the ClientHello message.
Besides being able to extract all the DNS names from the certificates to build the index, the server also needs to know when each certificate would expire so that it can rotate in another configuration before the expiration occurs.
The most thorough way to accomplish this would be for the server to validate the certificate and calculate the max(notBefore) and min(notAfter) times for the chain. That would require the certificate to know the valid set of trust anchors and it would require the server to have all the intermediate certificates present.
The simplest way to accomplish this is to assume that the end-entity certificates always expire before any of the CA certificates that issue them expire. This isn't a valid assumption in general, however.
To allow for the "most thorough" way mentioned above, we'd simply need to change the validation logic to return Result<ValidityPeriod, Error> instead of Result<(), Error>, or similar.
To allow the "simplest way" mentioned above, we'd simply need to provide notAfter() -> SystemTime and notBefore() -> SystemTime functions on EndEntityCert().
I personally am biased towards the "more thorough" way.
When a server is terminating TLS for many logical servers with lots of different DNS names it will need to manage a lot of certificates. When the number of certificates becomes large the server needs to create an index to find which certificate chain (and private key) to use, given the SNI from the ClientHello message.
Besides being able to extract all the DNS names from the certificates to build the index, the server also needs to know when each certificate would expire so that it can rotate in another configuration before the expiration occurs.
The most thorough way to accomplish this would be for the server to validate the certificate and calculate the max(notBefore) and min(notAfter) times for the chain. That would require the certificate to know the valid set of trust anchors and it would require the server to have all the intermediate certificates present.
The simplest way to accomplish this is to assume that the end-entity certificates always expire before any of the CA certificates that issue them expire. This isn't a valid assumption in general, however.
/cc @Geal.
The text was updated successfully, but these errors were encountered: