Mbed TLS fails to report missing revocation information

[joyantaDebnath]

Summary

For a given list of CRLs and a certificate, during certificate validation, if the CRL corresponding to the certificate in question is missing–rendering its revocation status indeterminable–Mbed TLS does not report the result as undetermined. Instead, it silently accepts the certificate as valid.

System information

Mbed TLS version (number or commit id): 4.0.0 or older
Operating system and version: Ubuntu 24.04

Expected behavior

Reject the certificate as invalid since revocation status could not be determined from the given CRLs

Actual behavior

Accepts the certificate without any warning / error messages to the user regarding undetermined revocation status

[mpg]

Hi @joyantaDebnath and thanks for your report!

I agree it is desirable for Mbed TLS to be able to report whether revocation status has been checked or not as part of the verification result. However I'll note the function's current behaviour is aligned with what its documentation says:

 * \note           It is your responsibility to provide up-to-date CRLs for
 *                 all trusted CAs. If no CRL is provided for the CA that was
 *                 used to sign the certificate, CRL verification is skipped
 *                 silently, that is *without* setting any flag.

I think the reasoning behind the current API and behaviour is mostly valid for people who use a private CA that directly issues end-entity certificate (something that's more common in the embedded world): you have a single, or at most a handful of trusted CAs which you know well, and you can provide CRLs for all of them. Since there's a small number of trusted roots, managed manually, it's unlikely that the user will forget a CRL, so the library doesn't need to check and can just trust the caller.

That reasoning doesn't work so well for a context like the Web PKI where there are typically 100+ trusted roots, loaded from a directory, and they don't directly sign end-entity certificates, but instead the chain goes through one or more intermediate CAs. Here the problem is not just that it's hard to be sure we have CRLs for all trusted roots, it's about CRLs for intermediates. The scenario where an end-entity certificate is revoked by the intermediate CA that signed it is much more likely than the case of an intermediate being revoked by the root.

So, I agree that our API, while suitable for some use cases, is not good enough for other use cases. We should probably add another verification function that has a callback for dynamic loading of CRLs from intermediate CAs used in the chain, and that is able to report if not all CRLs relevant for a particular certificate chain where found.

As a result, I'm labeling this as an enhancement request. While I think your request is perfectly reasonable and valid, I want to set realistic expectations: these days development is more focused on the crypto side of the library, so we're not likely to implement this soon. We might review a PR about it though, but if you intend to raise one, please talk with us first about the design.

If other users are interested in this feature, please let us know by commenting on this issue, it might help us raise its priority.

[mpg]

Out of curiosity I've checked how OpenSSL's and GnuTLS's command line tools behave.

• openssl verify by default does not verify CRLs, even if a CRL file is provided, unless -crl_check (or -crl_check_all) is used. In that case, if a CRL is missing, then the certificate is not trusted, which is the safest option and what our API currently does not support.
• GnuTLS's certool by default does not verify CRLs, unless one is provided with --load-crl. In that case, it does not complain if the provided CRL file does not include one for the CA used, and I've not found a way to make it complain. This is more similar to our own documented behaviour: if you care about CRLs, providing the right ones is up to you. If you fail to provide all relevant CRLs, then the tool won't tell you.

So, we're not terrible outliers here, but OpenSSL does provide useful options that we currently do not, and probably should.