verify -crl_check_all requires separate CRL for self-signed certificate

[mpeylo]

This has been reproduced with OpenSSL 1.1.1a and a development build based on commit 13d928d.

The same issue has been rejected in #2873, while the correct argumentation might have been overlooked as it was submitted after the issue was already closed.

Consider a 3-layer hierarchy where the EE and subCA both have CRL Distribution Points set, but the self-signed does not.

depth=0: CN = EE (untrusted)
depth=1: CN = subCA (untrusted)
depth=2: CN = self-signed

The following verification attempt including -crl_check_all will fail, although it downloads both the two meaningful CRLs from the applicable distribution points.

$ openssl verify -CAfile self-signed.pem -untrusted subCA.pem -crl_check_all -crl_download EE.pem 
CN = self-signed
error 3 at 2 depth lookup: unable to get certificate CRL
error EE.pem: verification failed

Note: there is no difference visible when replacing -CAfile with -trusted

If the same CLR which is also downloaded for validating the subCA certificate is given by means of -CRLfile, then the verification succeeds.

openssl verify -CAfile self-signed.pem -untrusted subCA.pem -crl_check_all -crl_download -CRLfile self-signedCRL.pem newcert.pem
EE.pem: OK

The verify documentation states

-crl_check_all
    Checks the validity of all certificates in the chain by attempting to look up valid CRLs.

A valid CRL for the self-signed was downloaded when the the subCA certificate was validated; this CRL's Issuer matches the issuer of the self-signed certificate. It could be considered as a bug (or at least as missing feature) that this successfully looked up valid CRL was not considered as applicable for checking revocation status of the self-signed certificate.

[mpeylo]

Just as thoughts:

Probably obvious that in case of a self-signed certificate, relying on a CRL which might have been signed with a compromised key (if that is the revocation reason) might not lead to the desired outcome. So a CRL for a self-signed certificate might make most sense if an explicitly referenced crlIssuer from another PKI hierarchy is involved?

But then, there might be valid use cases (while not suitable for key compromise) without crlIssuer e.g. during Trust Anchor roll-over when the TA subject name stays the same.

[ksw25]

I am facing the same issue. In my case the root CA doesn't have crlDistributionPoints so -crl_check_all is failing. What should I do?

[deivse]

Any updates on this? This seems like something that should be handled by openssl itself, using a flag on X509_STORE or something similar.

For anyone facing the same issue, the solution I will probably end up using is setting a custom verify_cb, and ignoring X509_V_ERR_UNABLE_TO_GET_CRL if the current cert (X509_STORE_CTX_get_current_cert) is self-signed.

[Herschdorfer]

The problem also becomes visible when using

openssl s_client -crl_check_all -crl_download -connect google.com:443

Other than openssl verify here you cannot specify the -trusted parameter with a selfsigned root certificate, which will always lead to a failed verification.

I just checked with the google.com cert and also openssl verify fails when using the -trusted option.