Certificate CRLs & X509_V_ERR_UNABLE_TO_GET_CRL

[Austin Krauss]

Hello all, I've recently enabled our OpenSSL application to use CRLs by using:

X509_STORE_set_flags(cert_store, X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL);

and loading individual CRLs. The problem that I seem to be running across is that some CAs don't have CRLs. In this case the certificate verify fails with the error:

Error: 3, unable to get certificate CRL

Obviously I can override this error in my certificate callback function, but I don't think this is the proper thing to do without fully understanding why OpenSSL is rejecting this certificate.

Can anyone explain how to properly use CRLs in conjunction with CAs that don't have a CRL?

Thanks in advance,

Austin Krauss
SISCO, Inc.

[Dr. Stephen Henson]

Post by Austin Krauss
X509_STORE_set_flags(cert_store, X509_V_FLAG_CRL_CHECK |
X509_V_FLAG_CRL_CHECK_ALL);
and loading individual CRLs. The problem that I seem to be running across is
that some CAs don't have CRLs. In this case the certificate verify fails
Error: 3, unable to get certificate CRL
Obviously I can override this error in my certificate callback function, but
I don't think this is the proper thing to do without fully understanding why
OpenSSL is rejecting this certificate.
Can anyone explain how to properly use CRLs in conjunction with CAs that don't have a CRL?

Well by enabling CRL checking its effectively saying that the revocation
status of the relevant certificates should be checked via a CRL.

In general there's no way to say for certain that a CA doesn't issue CRLs. It
may not have the CRLDP extension but CRLs may still be distributed by out of
band means.

The lack of a CRL could mean several things, for example...

The CA doesn't issue CRLs.

The CA does issue CRLs but the server distrbuting them is inaccessible for some
innocent reason.

The CA does issue CRLs but the server is inaccessible due to a denial of service
attack on either the server or the receiver.

This last case could mean that an attacker could use a revoked certificate by
preventing the CRL revoking it from being downloaded.

As a result its left to the application to decide what to do in this case,
with OpenSSL having a cautious default behaviour but allowing an application
to override this.

Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: shenson-Pqzf/mBTa20vnmoEvQhlZgbYiX8G1TQY9dF7HbQ/***@public.gmane.org, PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Lee Dilkie]

This question intrigues me as well. Does the crl check key on the presence
of the crl extension in the certificate or does it assume that all
certificates have a crl regardless of the certificate extension. I would
expect the behaviour that you describe only for certificates that have the
crl extension. You (well, the code) shouldn't reject a certificate that
doesn't contain a crl extension. If that is the way the code behaves, then I
must have misunderstood your explanation and I'm sorry. If it does reject
certificate without a crl extension, is there any way to know the failure
was due to a missing crl on a certificate with no crl extension?

-----Original Message-----
Stephen Henson
Sent: Wednesday, June 25, 2003 1:17 PM
Subject: Re: Certificate CRLs & X509_V_ERR_UNABLE_TO_GET_CRL

Post by Austin Krauss
Hello all, I've recently enabled our OpenSSL application to

use CRLs by

Post by Austin Krauss
X509_STORE_set_flags(cert_store, X509_V_FLAG_CRL_CHECK |
X509_V_FLAG_CRL_CHECK_ALL);
and loading individual CRLs. The problem that I seem to be

running across is

Post by Austin Krauss
that some CAs don't have CRLs. In this case the certificate

verify fails

Post by Austin Krauss
Error: 3, unable to get certificate CRL
Obviously I can override this error in my certificate

callback function, but

Post by Austin Krauss
I don't think this is the proper thing to do without fully

understanding why

Post by Austin Krauss
OpenSSL is rejecting this certificate.
Can anyone explain how to properly use CRLs in conjunction

with CAs that

Post by Austin Krauss
don't have a CRL?

Well by enabling CRL checking its effectively saying that the
revocation
status of the relevant certificates should be checked via a CRL.
In general there's no way to say for certain that a CA
doesn't issue CRLs. It
may not have the CRLDP extension but CRLs may still be
distributed by out of
band means.
The lack of a CRL could mean several things, for example...
The CA doesn't issue CRLs.
The CA does issue CRLs but the server distrbuting them is
inaccessible for some
innocent reason.
The CA does issue CRLs but the server is inaccessible due to
a denial of service
attack on either the server or the receiver.
This last case could mean that an attacker could use a
revoked certificate by
preventing the CRL revoking it from being downloaded.
As a result its left to the application to decide what to do
in this case,
with OpenSSL having a cautious default behaviour but allowing
an application
to override this.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Automated List Manager

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Dr. Stephen Henson]

Post by Lee Dilkie
This question intrigues me as well. Does the crl check key on the presence
of the crl extension in the certificate or does it assume that all
certificates have a crl regardless of the certificate extension. I would
expect the behaviour that you describe only for certificates that have the
crl extension. You (well, the code) shouldn't reject a certificate that
doesn't contain a crl extension. If that is the way the code behaves, then I
must have misunderstood your explanation and I'm sorry. If it does reject
certificate without a crl extension, is there any way to know the failure
was due to a missing crl on a certificate with no crl extension?

It always assumes that a certifcate will have an accessible current CRL. As I
mentioned the absence of a CRLDP extension doesn't necessarily mean that the CA
doesn't issue CRLs: just that it doesn't give details about how to download
them in the certificate.

Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: shenson-Pqzf/mBTa20vnmoEvQhlZgbYiX8G1TQY9dF7HbQ/***@public.gmane.org, PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Lee Dilkie]

Post by Dr. Stephen Henson
It always assumes that a certifcate will have an accessible
current CRL. As I
mentioned the absence of a CRLDP extension doesn't
necessarily mean that the CA
doesn't issue CRLs: just that it doesn't give details about
how to download
them in the certificate.
Steve.

Ok, so I didn't missunderstand. My problem is this. Some CA's issue CRL's
and some don't. The crl extension is the only way to know for sure that
there is supposed to be a crl for an issued certificates. I fully agree with
returning a verification failure if that crl isn't available.

However, the case of a certificate without a crl extension is more
difficult. It's not possible to know if there is an out-of-band crl or not.
I would think a warning would be a better thing to give than an error. Or
perhaps a(nother) flag to indicate that you wish to ignore crl-not-found
errors for certificates with no crl extensions. Otherwise we end up with the
case we have here. Someone wants to turn on crl checking because thats the
right and secure thing to do, but the build-in verify is too strict and is
not returning useful results. Short of writing his own verify code (a fairly
major effort to get right) I worry that this will discourage using the crl
checking features and we end up poorer off, security wise.

just my thoughts.

regards,

-lee

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Dr. Stephen Henson]

Post by Lee Dilkie

Post by Dr. Stephen Henson
It always assumes that a certifcate will have an accessible
current CRL. As I
mentioned the absence of a CRLDP extension doesn't
necessarily mean that the CA
doesn't issue CRLs: just that it doesn't give details about
how to download
them in the certificate.
Steve.

Ok, so I didn't missunderstand. My problem is this. Some CA's issue CRL's
and some don't. The crl extension is the only way to know for sure that
there is supposed to be a crl for an issued certificates. I fully agree with
returning a verification failure if that crl isn't available.
However, the case of a certificate without a crl extension is more
difficult. It's not possible to know if there is an out-of-band crl or not.
I would think a warning would be a better thing to give than an error. Or
perhaps a(nother) flag to indicate that you wish to ignore crl-not-found
errors for certificates with no crl extensions. Otherwise we end up with the
case we have here. Someone wants to turn on crl checking because thats the
right and secure thing to do, but the build-in verify is too strict and is
not returning useful results. Short of writing his own verify code (a fairly
major effort to get right) I worry that this will discourage using the crl
checking features and we end up poorer off, security wise.

There isn't a mechanism for issuing a warning in the verify code at present.

The behaviour OpenSSL exhibits is its default behaviour. To modify this an
application doesn't have to write its own verify code: it just needs to handle
the CRL not found error in the verify callback.

Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: shenson-Pqzf/mBTa20vnmoEvQhlZgbYiX8G1TQY9dF7HbQ/***@public.gmane.org, PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org