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.
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.
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