If a certificate received from a peer:
- Is expired,
- has a valid signature, but from an untrusted root CA
What error should be thrown? Untrusted certificate or expired certificate? I can't seem to locate what the relevant RFC would suggest.
$\begingroup$
$\endgroup$
1
-
$\begingroup$ Firefox/NSS had a bug some years ago (can't find a link now unfortunately) where a server cert that was both untrusted and expired was reported to the user as simply expired. Since an expiration is much less serious issue, it was thought that this might increase the rate of user clickthrough and so was changed to report the most serious error, rather than the first error that was noticed during processing. $\endgroup$– Jack LloydCommented Apr 19, 2019 at 12:10
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
Untrusted certificate or expired certificate?
If you go strictly by RFC 5280 ordering, "untrusted certificate" should be returned.
More specifically section 6.1.3 starts with
The basic path processing actions to be performed for certificate i (for all i in [1..n]) are listed below. (a) Verify the basic certificate information. The certificate MUST satisfy each of the following: (1) The signature on the certificate can be verified using working_public_key_algorithm, the working_public_key, and the working_public_key_parameters. (2) The certificate validity period includes the current time.
As RFC 5280 goes the from signer to signee, the current working_public_key is the ones of all trusted CAs (section 6.1.2 (h)). As the CA in question is not trusted, no public key will yield a successful validation. As this is checked before the expiration, it should yield the error.
Note that this also makes sense from a cryptographic standpoint, as you always want to make sure that your data is authentic before parsing it to avoid malicious data (like maliciously crafted certificates) to break and exploit your parser.
