Why no CRL URL in the certificate?


#1

I have a brand new LE certificate and I have been testing it in various ways. I have a X509 audit tool that I wrote, among other things, it tries to follow the certificate chain to the root and check the CRLs on the way. For my server it reports ‘no CRL distribution point found’ When I manually check the certificate with openssl, sure enough there is no section X509v3 CRL Distribution Points. I can’t believe that this is an oversight, please educate me on the rationale for no CRL Distribution Points section.

Also, with my old thawte cert I got an A rating from https://www.ssllabs.com/ssltest/analyze.html now I get a B

This server’s certificate chain is incomplete. Grade capped to B.

Certificates provided 1 (1295 bytes)
Chain issues Incomplete

Path #1: Trusted
1 Sent by server taygeta.com

2 Extra download Let’s Encrypt Authority X3

3 In trust store DST Root CA X3 Self-signed

Is this a problem with my apache server config?


#2

The “incomplete chain” is because you’ve configured Apache to send only the certificate itself, not the accompanying intermediates. If you used the Certbot tool (or the same things under its older “letsencrypt” name) the intermediates are in the file chain.pem next to the cert.pem file you already added to your config. If you have a newer Apache (2.4.8 or newer), you can just change your config to refer to fullchain.pem, which has everything in it, on older versions they don’t understand how to handle that so add a directive like this

SSLCertificateChainFile "/path/to/chain.pem"

The reason for no CRL is that Let’s Encrypt is (as you may have noticed) hugely popular, with millions of certificates and fully automated issuance and revocation. Even if they perhaps shouldn’t, or at least needn’t - thousands of people revoke Let’s Encrypt certificates every week, and a CRL would need to list all those revocations promptly. So if a CRL existed it’d be a huge file (or hundreds of small files). Instead of a CRL, Let’s Encrypt provides OCSP, the Online Certificate Status Protocol, which is a protocol whereby a client can ask a server (actually a CDN working from a stash of pre-signed answers) “Hey, is this certificate still OK?” and get a signed “OK” or “Not OK” response.

The Baseline Requirements for Certificate Authorities like Let’s Encrypt (rules they agree with the major trust stores like Microsoft, Apple, Mozilla etc.) say that it’s OK for end entity certificates like yours to only have OCSP instead of a CRL, but that intermediate certificates must offer a CRL even if they also have OCSP.

Eventually, perhaps quite a few years from now, the intention is that online things like web browsers will mostly rely on something called OCSP Stapling, which avoids most of the problems with both CRLs and OCSP as it is normally used today. In OCSP Stapling the web server is responsible for fetching an OCSP response signed by the CA, and presents that to the client when they connect, so the client doesn’t need to do a separate connection. But since you use Apache I don’t recommend switching this on today because the Apache httpd doesn’t yet do stapling very well.


#3

Answering my own question…yes it was an apache config issue, I put the LE cert at SSLCertificateFile and not at SSLCertificateChainFile. I fixed that and got my A back


#4

CRL is crap and outdated. Read about OCSP.


#5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.