webpki icon indicating copy to clipboard operation
webpki copied to clipboard

Optionally ignore expired certificates

Open FortStatement opened this issue 7 years ago • 5 comments

A valid use case with some testing server you can't control would be to communicate with it over TLS without a valid certificate. I think other such validations should be ignorable, but I specifically need to be able to communicate with a server with an expired certificate.

As for implementation, obviously it should be passed down to check_validity (verify_cert.rs, line 176) from build_chain, but from a security standpoint it might be safer to also hide that behind a feature flag.

FortStatement avatar Aug 03 '18 15:08 FortStatement

I think I'd prefer the approach where Error::CertExpired becomes Error::CertExpired(Time), allowing the validation to be explicitly retried with a time just before expiry.

This means someone needing this behaviour needs to explicitly perform it (which should hopefully be obvious, handling and retrying the CertExpired error) and webpki doesn't need significant changes.

ctz avatar Aug 03 '18 16:08 ctz

It's nice to not have significant changes, but retrying with a different time (that isn't the present) just seems like a hack, don't you think?

FortStatement avatar Aug 03 '18 21:08 FortStatement

I understand why people request this but this is antithetical to the design goals of this library. Even the thing that @ctz suggested would mean adding mostly-unnecessary complexity, and avoiding unnecessary complexity is a key tenant here.

I suggest instead we provide a way to see the notAfter and notBefore fields of end entity certificates. Then somebody who really wants this functionality could retry the validation using the notAfter time. It wouldn't always work, because one of the intermediates might have expired, but it would probably be a good enough heuristic for most uses. I think it's inevitable that we'll need to expose the notAfter and notBefore fields for a variety of reasons so doing so wouldn't add any extra complexity.

briansmith avatar Oct 09 '18 20:10 briansmith

I've given a stab at this in #242. My use case is for certain embedded devices that simply doesn't have a clock source and therefore cannot validate the notAfter/notBefore.

lulf avatar Oct 12 '21 12:10 lulf

As a workaround for this issue: As the certificate error says either CertExpired or CertNotValidYet, and the time is supplied by the caller of webpki, one should be able to do a bisection search for a possibly valid time stamp.

est31 avatar Mar 28 '22 16:03 est31