New Lists of Mozilla Root CAs

[Ben Wilson]

Dear Mozilla Community,

Four new Root CA reports are now available for review from the CCADB. These reports provide information on Root Certificates trusted for TLS and S/MIME authentication within Mozilla’s Root Store. (These links will go on https://wiki.mozilla.org/CA/Included_Certificates and https://www.ccadb.org/resources.)

TLS ServerAuth Roots

Full report (CSV):
https://ccadb.my.salesforce-sites.com/ccadb/Report?Name=MozillaTLSServerAuthenticationCSV

A list of 144 Root CAs with the websites trust bit enabled, including:

• CA Owner

• Certificate Name

• SHA-256 Fingerprint

• SPKI SHA256

• Valid From / Valid To (GMT)

• Full CRL Issued By This CA

• JSON Array of Partitioned CRLs

• X.509 Certificate (PEM format)

PEM-only version:
https://ccadb.my.salesforce-sites.com/ccadb/Report?Name=MozillaTLSServerAuthenticationPEMOnly

Email S/MIME Roots

Full report (CSV):
https://ccadb.my.salesforce-sites.com/ccadb/Report?Name=MozillaSMIMECSV

A list of 134 Root CAs with the email trust bit enabled, including:

• CA Owner

• Certificate Name

• SHA-256 Fingerprint

• SPKI SHA256

• Valid From / Valid To (GMT)

• Full CRL Issued By This CA

• JSON Array of Partitioned CRLs

• X.509 Certificate (PEM format)

PEM-only version:
https://ccadb.my.salesforce-sites.com/ccadb/Report?Name=MozillaSMIMEPEMOnly

Please review these reports and share any feedback or suggested changes by next Monday. 

Thank you,
Ben Wilson
Mozilla Root Program

[Filippo Valsorda]

Hi Ben,

Would roots with constraints in their certdata.txt entry (such as CKA_NSS_SERVER_DISTRUST_AFTER) be listed in these reports?

Also, is the intention for applications to use the MozillaTLSServerAuthenticationPEMOnly report as a trust anchor pool? Because I can guarantee that offering the report in such a convenient PEM format will lead to it being used that way.

(It's really unfortunate that as an industry we have not found a better minimum common denominator format for root anchors than a pile of PEM files. It means applications often miss out on constraints like SCT-based distrusts, enforced name constraints, etc. However, that's a broader issue and probably not something needing to be solved for these reports.)

Cheers,

Filippo

--

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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYNWbmgbiySJLUsF-VBO2onv-Yp4CA%2BtDv5bdsmMoovHg%40mail.gmail.com.

[Jan Schaumann]

"'Ben Wilson' via dev-secur...@mozilla.org" <dev-secur...@mozilla.org> wrote:

> Four new Root CA reports are now available for review from the CCADB. These
> reports provide information on Root Certificates trusted for TLS and S/MIME
> authentication within Mozilla’s Root Store. (These links will go on
> https://wiki.mozilla.org/CA/Included_Certificates and
> https://www.ccadb.org/resources.)

> *TLS ServerAuth Roots*
>
> *Full report (CSV):*
> https://ccadb.my.salesforce-sites.com/ccadb/Report?Name=MozillaTLSServerAuthenticationCSV
>
> A list of *144 Root CAs* with the *websites* trust bit enabled, including:


Would it be possible to publish a diff to previous
versions of the list?

Pulling that out of the CSV is a bit inconvenient, and
seeing "added CA X cert Y; removed CA A, cert B" would
be quite helpful for consumers of the list.

Also: could these be hosted under a mozilla.org domain
name? Going to Salesforce as a the source of truth
for Mozilla truststore information seems odd.

-Jan

[Ronald Crane]

On 10/27/2025 12:12 PM, 'Jan Schaumann' via dev-secur...@mozilla.org wrote:

"'Ben Wilson' via dev-secur...@mozilla.org" <dev-secur...@mozilla.org> wrote:

...

Also: could these be hosted under a mozilla.org domain
name?  Going to Salesforce as a the source of truth
for Mozilla truststore information seems odd.

I second this request. Using alternate domains in this manner causes confusion and creates opportunities for phishing. Alas this practice is very common, even among institutions that we must (involuntarily) trust, such as banks, brokerages, and health plans.

-R