Broken CRL URLs in CCADB

[Daniel McCarney]

Hello MDSP community,

I've been attempting to collect a dataset of CRLs by fetching each CRL URL present in the "Full CRL Issued By This CA" and "JSON Array of Partitioned CRLs" columns of the "all certificate records" CSV report available from CCADB[0].

This has uncovered a handful of mis-configurations that I believe should be remedied. They fall into three categories of failure:

1) CRL URLs that return a 403 Forbidden response.
2) CRL URLs that return a 404 Not Found response.
3) CRL URLs that return an x509 certificate, not a CRL.

The failures affect four distinct CA owners: Sectigo, GlobalSign nv-sa, Entrust, and Autoridad de Certificacion Firmaprofesional.

I'm disappointed that this is still a problem given Andrew Ayer previously shared similar results[1] back in September 2022. I would strongly encourage affected CAs to invest in monitoring of disclosed CRL URLs so that it doesn't fall to broader Mozilla community to do this work on a regular basis.

Forbidden responses:

* CA Owner: Sectigo
  * Salesforce Record ID 001o000000poU6CAAU
    * CRL URL: http://crl.nicecert.com/eBizNetworksCodeSigningCA.crl
  * Salesforce Record ID 001o000000piSaqAAE
    * CRL URL: http://crl.nicecert.com/eBizNetworksLASSLCA.crl

Not found responses:

* CA Owner: GlobalSign nv-sa
  * Salesforce Record ID 0014o00001l1GHoAAM
    * CRL URL: http://crl.globalsign.com/ca/gsatlaseccr5ovtlsca202012.crl
  * Salesforce Record ID 0011J00001ha3YgQAI
    * CRL URL: http://crl.globalsign.com/ca/dpdhlusercai5.crl
  * Salesforce Record ID 0014o00001l1GGCAA2
    * CRL URL: http://crl.globalsign.com/ca/gsatlaseccr5dvtlsca202012.crl
* CA Owner: Entrust
   * Salesforce Record ID 001o000000p2VbmAAE
    * CRL URL: http://crl.entrust.net/class1.crl

Not a CRL responses:

* CA Owner: Autoridad de Certificacion Firmaprofesional
  * Salesforce Record ID 0018Z00002nth12QAA
    * CRL URL: http://crl.firmaprofesional.com/ica-a01-qwac.crt
  * Salesforce Record ID 0018Z00002nth2KQAQ
    * CRL URL: http://crl.firmaprofesional.com/ica-a02-noqwac.crt

Thanks,

- Daniel (@cpu)

[0]: https://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat
[1]: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/Wm9Sf1AEbig/m/ANbMpBVFBwAJ

[Rob Stradling]

Hi Daniel.

> Forbidden responses:

>

> * CA Owner: Sectigo

>   * Salesforce Record ID 001o000000poU6CAAU

>     * CRL URL: http://crl.nicecert.com/eBizNetworksCodeSigningCA.crl

>   * Salesforce Record ID 001o000000piSaqAAE

>     * CRL URL: http://crl.nicecert.com/eBizNetworksLASSLCA.crl

The certificates for both of these CAs (https://crt.sh/?CAID=13544 and https://crt.sh/?CAID=12157) have expired and only chain to roots that have been removed from the root programs of the CCADB Root Store members.

AFAICT, there are no CCADB rules that govern the expectations for the behaviour of disclosed CRL URLs after the corresponding issuing CA certificate(s) expire and/or the relevant root certificate(s) are removed from the trust stores:

  - Mozilla's CRL disclosure requirement [1] applies to (emphasis mine) "intermediate CA certificates that are capable of issuing TLS certificates chaining up to root certificates in Mozilla's root store".

  - Likewise, Apple's CRL disclosure requirement [2] applies to (emphasis mine) "each included CA Certificate and each CA Certificate chaining up to an included CA Certificate in the Apple Root Program".

  - CCADB CRL disclosures are not required by Chrome, Microsoft, or Cisco.

For server authentication CAs, I think I'm right in saying that after CA expiry there's no requirement to continue providing CRLs.

For code signing CAs, the CS BRs require that "The serial number of a revoked Certificate MUST remain on the CRL for at least 10 years
after the expiration of the Certificate".  I can confirm that all of the certificates issued by the eBizNetworks code signing CA expired more than 10 years ago, so AFAICT there is no requirement to continue providing CRLs for that CA.

So ISTM that, per current requirements, Sectigo hasn't done anything wrong in these two cases.  Nonetheless, since we're actually still issuing CRLs for these expired CAs, I will update the disclosed Full CRL URLs to ones that do work.

[1] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#41-additional-requirements

[2] https://www.apple.com/certificateauthority/ca_program.html#:~:text=applies%20to%20each%20included%20CA%20Certificate%20and%20each%20CA%20Certificate%20chaining%20up%20to%20an%20included%20CA%20Certificate%20in%20the%20Apple%20Root%20Program

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Daniel McCarney <dan...@binaryparadox.net>
Sent: 19 April 2023 18:28
To: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Broken CRL URLs in CCADB

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c3632294-646c-4fa4-bc98-e45feedd71ddn%40mozilla.org.

[Rob Stradling]

> So ISTM that, per current requirements, Sectigo hasn't done anything wrong in these two cases.  Nonetheless, since we're actually still issuing CRLs for these expired CAs, I will update the disclosed Full CRL URLs to ones that do work.

FWIW, I've reviewed, and updated where necessary to make them functional, all of the (out of scope) Full CRL URLs in the CCADB records for all expired intermediate certificates that chain to no-longer-trusted roots owned by Sectigo.

More usefully, I've also just updated https://crt.sh/mozilla-disclosures and https://crt.sh/apple-disclosures so that they both now flag an (in scope) CA in the "Disclosure Incomplete or Incorrect" bucket when its disclosed Full CRL is broken in any way.  Currently these pages are showing instances of the other two categories you mentioned - "404 Not Found response" and "x509 certificate, not a CRL".  (I'm curious about why https://sslmate.com/labs/crl_watch/ isn't currently flagging these).

BTW Daniel, was there a reason you started this thread on MDSP instead of CCADB Public (https://groups.google.com/a/ccadb.org/g/public)?  It doesn't seem to be a Mozilla-specific topic.

---

From: Rob Stradling <r...@sectigo.com>
Sent: 19 April 2023 21:44
To: Daniel McCarney <dan...@binaryparadox.net>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: Broken CRL URLs in CCADB

 

[Daniel McCarney]

Hi Rob,

Thanks for your replies and for the improvements you've made, especially to crt.sh. Very helpful!

> BTW Daniel, was there a reason you started this thread on MDSP instead of CCADB Public (https://groups.google.com/a/ccadb.org/g/public)?  It doesn't seem to be a Mozilla-specific topic.

Just ignorance on my part. Thanks for the pointer :-) I agree the CCADB public list would be a better home for this discussion and I should have posted there instead. I will cross-post a link.