Interesting. Normally we allow users to override "expired." Was the OCSP server returned "unknown" for the old cert after it expired? One way to check this wou

Interesting. Normally we allow users to override "expired." Was the OCSP server returned "unknown" for the old cert after it expired? One way to check this would be to uncheck the first check box in that dialog box ("Use OCSP"). If you are able to override the cert error for the expired cert then that is a good indication that the server is returning "unknown" for expired certs. If "unknown" response for the expired cert is the cause, this is the law of unintended consequences at work. Previously, it was very common for a CA's OCSP responder to return "good" for any certificate that it didn't know about; i.e. their OCSP responders returned "revoked" for every certificate that they knew was revoked, but "good" by default. After the DigiNotar incident, we (Mozilla and other browser vendors) pushed CAs to change the default to be "unknown." However, it is also fair for the CA to "forget" about a certificate as soon as it has expired and/or to revoke it as soon as it has expired. If so, the OCSP responder would return "revoked" or "unknown" for any expired certificate. That would turn a user-overridable error (expired) into a non-user-overridable error (revoked/unknown). This is something we hadn't considered. Certificate authorities need to be careful that they update their OCSP responders ASAP, preferably BEFORE they give the customer the cert, to avoid this issue in the newly-issued certificate case. Because many CAs have just recently implemented this policy of returning "unknown" for unknown certs, there are still some bugs to sort out, I guess. I will bring this up in the CA/Browser forum to make sure everybody knows it is a real-world issue.