Is this a vulnerability? No.

All CAs have to do this. This is a security feature, not a security problem. Without publishing the CRL, you lose security.

For PKI to work, anyone who accepts a certificate (called a "relying party" in PKI-speak) should verify the certificates. Otherwise, stolen certificates will be useable forever. To facilitate this, all certificate authorities publish a CRL file - i.e. a file that includes serial numbers and dates of all revoked certificates. This information must be made public to all relying parties.

It is possible to use internal CA certificates for client connections (SecureClient, SNX, SC-M and L2TP) as well as for site-to-site connections with other gateways. All these VPN peers are also relying parties, so they must be given access to the CRL.

Let's look at an example:

1. Surf to your favorite HTTPS site. For example, www.bankofamerica.com.
2. Click the padlock. In IE7, choose "View certificates". You get a window showing the certificate, and a note that this certificate was signed by Verisign.
3. Click the Details tab. The top window shows various fields from the certificate.
4. Scroll down to "CRL Distribution Points". The bottom window shows the URL - Class3InternationalServer.crl
5. You can download the file. It's a 768KB file. Don't try to read it with an editor, as it's in ASN.1, but double-clicking it in Windows will show you the content.
6. Click the Revocation List tab. Now you know that the certificate with serial number 0x0100f76ce1bfb3474c9be263b32694d4 was revoked on March 1st of 2005.
7. As an attacker, this does not help you attack BoA or Verisign. On the other hand, as a legitimate user, you can verify that the certificate for BoA is not in there. It's not.

CVE entry CVE-2006-6967 proposed that this issue be a candidate for inclusion in the CVE list based on two reference articles:

• OSVDB
  The OSVDB reference (31592) calls the issue, "loss of confidentiality". Not sure what they mean since the CRL information is anything but confidential.
• Nessus
  This reference ends with the following statement: "Risk Factor: None". The Nessus site does not refer to this issue as a problem. It is just mentioned as a way to detect a FireWall-1 Security Gateway. If it is listening on port 18264, it is probably FireWall-1.

To summarize, publishing the CRL is a good thing, and is actually required.