Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a way to get the validity time period for an EndEntityCert #67

Open
briansmith opened this issue Jan 10, 2018 · 2 comments
Open

Comments

@briansmith
Copy link
Owner

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.

@briansmith
Copy link
Owner Author

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.

@briansmith
Copy link
Owner Author

I suggest we implement #68 and then implement the "most through" way on the certificate chain that #68 would return.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant