x509Chain revocation check failing on revoked but valid certificate

Question

I cannot find any answers that address my exact situation so apologies if this is a duplicate. I am attempting to validate the certificate that we use to digitally sign our files which is working ok up to the point we revoke the certificate. That sounds correct I hear you say but my understanding is as follows:

If a certificate with validity period of 1/1/2014 till 1/1/2015 is used to sign a file on 2/1/2014 and is then revoked on 3/1/2014, the certificate on that file is still valid because it was not revoked at the time of signing.

If that understanding is correct then I would expect the x509Chain object to pass the revocation check even if the check is done in the presence of an up to date revocation list after the 3/1/2014 on the above file. Unfortunately the result is that the validation fails because it thinks the certificate is revoked.

Do I have to do a further test to see the revocation date and override the result and ignore it in this scenario? Am I doing something stupid? Am I misunderstanding revocation?

Answer 1

As I understand it revocation checks are current because they have to be.

For instance, suppose the following:

1. A certificate is used to sign legit software in 2014
2. The certificate expires or is revoked.
3. Now suppose a hacker has the certificate (a prime reason for revoking it).
4. The hacker signs malware software with the compromised certificate - they can use any date they want so pick the same as the legit software.

Now you download software in 2015 and want to check that it's legit - if you rely on the state of the certificate from when the software was created both 1. and 4. appear to be legit. If you instead rely on the current state then both 1. and 4. appear unsigned, but the legit software can be re-signed with the a new valid certificate, the malware can't.

So, by default any X509 check will fail if the public key is expired or revoked.

However, you can choose not to check for either expiry or revocation with X509VerificationFlags. If you do this then X509Chain.Build will pass but you'll need to somehow hold on to your expired keys to validate against them directly.

I've done this in unit tests so that new certificates don't have to be created just for for testing, but in production you may need to revoke a certificate in future, making this potentially dangerous.