Broken CRL URLs in CCADB
Daniel McCarney
Earlier today I posted a message with the same subject[0] to MDSP when it's likely a discussion better suited for this mailing list. Thanks to Rob Stradling for redirecting me to the right place.
Rob's replies on MDSP are also valuable, so I'm sad to have forked the discussion. As he notes I didn't do any filtering based on whether affected rows chain up to an active root in participating programs.
Is there an expectation that CRL URLs for inactive issuers should remain accessible? If not it may be less confusing to prune the inaccessible content.
Thanks,
[0]: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/LvbtTeBXRnI/m/lGS4uefZAAAJ
>
> 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
Corey Bonnell
Hi Daniel,
- Is there an expectation that CRL URLs for inactive issuers should remain accessible? If not it may be less confusing to prune the inaccessible content.
I assume that “inactive” in this case means that all certificates issued to that CA (name, key tuple) and chain to an Apple- or Mozilla-trusted root are expired or revoked. Even if there were an expectation that such CAs continue to provide revocation information, I struggle to see how maintaining access to that CA’s published revocation information would be valuable to a Relying Party. Relying parties will perform certification path validation on presented certificate chains, and this will fail upon encountering no valid paths from that CA (name, key tuple) back to a trust anchor. Any revocation artifacts issued by the CA in question have no value to the RP, as the CA itself is not trusted.
Thanks,
Corey
--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/44078b55-141b-4dc5-a7f9-c3e6a7bbaa90n%40ccadb.org.
Daniel McCarney
> Any revocation artifacts issued by the CA in question have no value to the RP, as the CA itself is not trusted.
Beyond the CRL question, maybe you can help me to understand why these issuers are included in the report at all.
Thanks,
Corey Bonnell
Hi Daniel,
As far as I’m aware, CCADB entries are not removed after the corresponding certificate expires/is revoked, so there’s a lot of old data present. In addition to CRL URIs, you’ll also find links to audit documents from 2017, etc. Definitely not useful for an RP making trust decisions today based on the data but may be useful when doing a historical analysis.
For those who care only about the set of unexpired/not revoked CA certificates (such as for your analysis), including the PEM text of the corresponding certificate, or at the very least the notBefore/notAfter values in the “AllCertificateRecordsCSVFormat” report would be useful. I know that I’ve had to write logic that correlates the information in the “AllCertificateRecordsCSVFormat” report with another data source to get the full picture at least a few times, and I imagine others have had to do the same thing as well.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CAPSmj0R7qWBX7GEko7L5c3D0mhvRox%3DF6ydAJHgb2%3DU0JxbGmg%40mail.gmail.com.
Kathleen Wilson
Corey Bonnell
Thanks, Kathleen. I think these are very useful improvements to CCADB reporting.
Thanks,
Corey
From: Kathleen Wilson <kwi...@mozilla.com>
Sent: Monday, May 8, 2023 6:15 PM
To: CCADB Public <pub...@ccadb.org>
Cc: Corey Bonnell <Corey....@digicert.com>
Subject: Re: Broken CRL URLs in CCADB
We've updated the report
Daniel McCarney
--
You received this message because you are subscribed to a topic in the Google Groups "CCADB Public" group.
To unsubscribe from this topic, visit https://groups.google.com/a/ccadb.org/d/topic/public/CKoJEAO6Qho/unsubscribe.
To unsubscribe from this group and all its topics, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/bfbf99ca-c9c9-462d-91d3-39335c8d2fb8n%40ccadb.org.
Rob Stradling
Sent: 08 May 2023 23:15
To: CCADB Public <pub...@ccadb.org>
Cc: corey....@digicert.com <Corey....@digicert.com>
Subject: Re: Broken CRL URLs in CCADB
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
Kathleen Wilson
>> We've updated the report>> to add two more columns (Valid From, Valid To).
>> We've also created another report:>> It has two columns: SHA-256 Fingerprint, X.509 Certificate (PEM)
> I can download this new CSV report if I access this URL in a browser, but with wget I'm getting an HTML page instead.
- Changed the CCADB links from ccadb-public.secure.force.com to ccadb.my.salesforce-sites.com per the Salesforce Enhanced Domains update.
- Renamed "All certs (root and intermediate) in CCADB (CSV)" to "All Certificate Information (root and intermediate) in CCADB (CSV)"
- Added "All Certificate PEMs (root and intermediate) in CCADB (CSV)"
- Added "All Included Root Certificate Trust Bit Settings (CSV)" per a previous request.
Kathleen
Kathleen Wilson
>> We've also created another report:
>> It has two columns: SHA-256 Fingerprint, X.509 Certificate (PEM)
> I can download this new CSV report if I access this URL in a browser, but with wget I'm getting an HTML page instead.
Corey Bonnell
Hi Kathleen,
The new reports contain very useful information that was not easily available previously. However, it appears that the method in which the report information is downloaded is different from the other reports. For example, the report containing the PEM text of all Mozilla-trust serverAuth roots [1] is directly available as a CSV. However, one of the new reports, such as the PEM texts of all certificates in CCADB, must first be accessed via a browser and JavaScript be executed to download the report. This download process hinders automation for tooling that consume these reports, as now the report must periodically be downloaded by someone manually or the tooling must execute the JavaScript to download the actual report CSV. Would it be possible to modify the new reports so that they are readily available as CSV files?
Thanks,
Corey
From: pub...@ccadb.org <pub...@ccadb.org> On Behalf Of Kathleen Wilson
Sent: Monday, May 15, 2023 6:13 PM
To: CCADB Public <pub...@ccadb.org>
Subject: Re: Broken CRL URLs in CCADB
--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/97347114-1da1-47f6-9966-036faf352b8an%40ccadb.org.
Ryan Hurst
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/DM6PR14MB2186188F73E34F52EE12E88692799%40DM6PR14MB2186.namprd14.prod.outlook.com.
Kathleen Wilson
However, one of the new reports, such as the PEM texts of all certificates in CCADB, must first be accessed via a browser and JavaScript be executed to download the report. This download process hinders automation for tooling that consume these reports, as now the report must periodically be downloaded by someone manually or the tooling must execute the JavaScript to download the actual report CSV. Would it be possible to modify the new reports so that they are readily available as CSV files?
Andrew Ayer
Kathleen Wilson <kwi...@mozilla.com> wrote:
> I believe you are specifically asking about the following report:
> https://ccadb.my.salesforce-sites.com/ccadb/AllCertificatePEMsCSVFormat
>
> My previous comments, which I'll copy again below were in regards to
> that report.
>
> Our Salesforce admin had to implement this
> AllCertificatePEMsCSVFormat report differently because otherwise we
> run into an error about the file being larger than 15MB. They have
> not been able to find a solution other than what they have currently
> implemented -- they had to create a lightning web component and then
> call it from the VisualForce page.
>
> We're open to ideas about how to work around this 15MB limitation.
different reports based on the first hex digit of the fingerprint)?
To echo what others have said, this really is a big deal for making
this data useful.
Regards,
Andrew
Kathleen Wilson
Would it be possible to split it into multiple reports (e.g. 16
different reports based on the first hex digit of the fingerprint)?
For example:
https://ccadb.my.salesforce-sites.com/ccadb/AllCertificatePEMsCSVFormat?NotBeforeYear=1999
Would provide the certificate PEMs for which the CCADB record has a ‘Valid From (GMT)’ field that contains 1999.
It looks like the first year for which there is data is 1994.
dr. Szőke Sándor
It is a good idea but it results too many separate reports.
What about grouping the certificates only by decades, which would result only for reports:
199x
200x
201x
202x
Sándor
From: pub...@ccadb.org <pub...@ccadb.org> On Behalf Of Kathleen Wilson
Sent: Thursday, May 18, 2023 11:06 PM
To: CCADB Public <pub...@ccadb.org>
Cc: Andrew Ayer <ag...@andrewayer.name>; CCADB Public <pub...@ccadb.org>; Kathleen Wilson <kwi...@mozilla.com>
Subject: Re: Broken CRL URLs in CCADB
Would it be possible to split it into multiple reports (e.g. 16
--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/e4ca526b-d690-485d-83f9-b4f92c00bb45n%40ccadb.org.
Andrew Ayer
Kathleen Wilson <kwi...@mozilla.com> wrote:
> How about if we shard the reports based on certificate notBefore?
>
> For example:
>
> https://ccadb.my.salesforce-sites.com/ccadb/AllCertificatePEMsCSVFormat?NotBeforeYear=1999
>
> Would provide the certificate PEMs for which the CCADB record has a
> ‘Valid From (GMT)’ field that contains 1999.
That said, would sharding by notBefore require manual action in
Salesforce every year/decade to provision a new shard? I think that
should be avoided if possible, as it would be prone to forgetfulness
and human error.
Regards,
Andrew
Kathleen Wilson
dr. Szőke Sándor
Hi Kathleen,
I tested the decade version for each decades and it was working fine.
Thanks for it,
Sándor
From: pub...@ccadb.org <pub...@ccadb.org> On Behalf Of Kathleen Wilson
Sent: Tuesday, May 23, 2023 12:03 AM
To: CCADB Public <pub...@ccadb.org>
Subject: Re: Broken CRL URLs in CCADB
The AllCertificatePEMsCSVFormat report has been update to accept one parameter: either NotBeforeYear or NotBeforeDecade
--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/54d8228b-d9fa-4e4e-a5eb-4898bdd89156n%40ccadb.org.