In the coming weeks, Mozilla and Chrome will remove trust in the Entrust certificate authority due to a pattern of compliance issues. To minimize disruption, only newly-issued certificates will be distrusted: Chrome will reject Entrust certificates issued after November 11, 2024, and Firefox will reject Entrust certificates issued after November 30, 2024. Previously-issued certificates are supposed to continue working, relieving server operators of the burden of replacing already-deployed certificates.

However, the Mozilla trust store is used not only by Firefox, but by numerous non-browser TLS clients in the Linux and open source ecosystems. A survey of prominent non-browser consumers of the Mozilla trust store reveals that the vast majority will not handle the upcoming distrust correctly - most will fail open, continuing to accept newly-issued Entrust certificates, but some will fail closed, rejecting previously-issued Entrust certificates, potentially as early as November 30. Consequentially, the Entrust distrust may be more disruptive than intended, and site operators using Entrust certificates should consider replacing their certificates prior to November 30 to avoid issues with non-browser clients.

Technical Background

The list of root certificates trusted by Mozilla is stored in the mozilla-central repository in a text file named certdata.txt. Roots in this file can be tagged with attributes which restrict how the root is used. One such attribute, CKA_NSS_SERVER_DISTRUST_AFTER, specifies the latest allowable issuance date for certificates issued under the root. The list of roots and their attributes is shipped with Firefox, and the Firefox certificate validator rejects certificates whose Not Before date is after the root's Distrust After date. In the near future, Mozilla will tag Entrust's roots with a Distrust After date of November 30, 2024. The maximum certificate validity period is 398 days, so on January 2, 2026 (398 days later), all Entrust certificates issued before November 30, 2024 will be expired, allowing Mozilla to remove the Entrust roots entirely from certdata.txt.

Most open source TLS clients do not ship with a list of roots like Firefox. Instead, the operator of the software is typically required to provide a PEM-encoded root certificate bundle. There are several places for an operator to get this bundle:

• Operating system packages, typically called ca-certificates, install a bundle to a quasi-standard location like /etc/ssl/certs/ca-certificates.crt or /etc/pki/tls/certs/ca-bundle.crt, which TLS clients load automatically.

• Curl provides a bundle for download. This bundle is shipped in libwww-perl's Mozilla::CA module.

• The Certifi project provides bundles via libraries for several popular languages.

• mkcert.org (part of the Certifi project) provides bundles via an HTTPS API endpoint.

• The golang.org/x/crypto/x509roots/fallback Go module embeds a bundle that is used if the operating system does not provide a bundle.

Ultimately, all of these bundles are generated by parsing Mozilla's certdata.txt. Unfortunately, there is no standard way to include attributes like Distrust After in PEM bundles. What should bundle providers do with roots which have this attribute?

Option 1: Ignore Attribute and Include the Root

The following bundle providers simply ignore the attribute and include the root in the bundle:

• Debian and Ubuntu's ca-certificates package, which is also used as the source of Gentoo's ca-certificates package.

• Fedora's ca-certificates package, which is also used as the source of Arch's ca-certificates package.

• Slackware's ca-certificates package, which was forked from Debian's ca-certificates package in 2018.

• Go's golang.org/x/crypto/x509roots/fallback module. (Interestingly, Go's certdata.txt parser supports parsing Distrust After attributes, and Go's CertPool type supports adding roots with constraints, but there's no code to actually take advantage of this functionality.)

If you use a bundle from one of the above providers, your TLS client will accept Entrust certificates issued after November 30.

Option 2: Exclude the Root

On the other hand, the following bundle providers exclude roots with Distrust After dates, if the date on which the bundle is generated is after the Distrust After date:

• Curl's bundle (Update: since publication, curl's bundle has been updated to include these roots!) (which is used by Alpine's ca-certificates package and libwww-perl's Mozilla:CA module)

• Certifi/mkcert.org

• FreeBSD's ca_root_nss

Consequentially, if you use a bundle from one of these providers and the bundle was generated after November 30, 2024, then your TLS client will reject all Entrust certificates - even those issued before November 30, which are supposed to keep working.

Unfortunately, most information about the Entrust distrust doesn't mention this problem, or even discuss non-browser clients at all, so server operators who need to support non-browser clients aren't aware of the need to replace their certificates before November 30.

P11-Kit Persistence Files

Fedora/Arch's ca-certificates package also ships a root bundle encoded in the p11-kit persistence format. This format supports attributes, and the ca-certificates package includes the CKA_NSS_SERVER_DISTRUST_AFTER attribute in the persistence file under an attribute named nss-server-distrust-after. However, it's unclear what software currently makes use of this. GnuTLS recently gained support for properly enforcing Distrust After, but GnuTLS is not commonly used compared to OpenSSL. Indeed, I tested curl on Fedora and Arch, and on both platforms the attribute-less PEM bundle was used.

What Should Server Operators Do?

If you're using Entrust certificates, particularly on non-HTTP endpoints such as mail servers, or on API endpoints that are likely to be accessed by non-browser clients, you should replace your certificates with non-Entrust certificates prior to November 30, 2024.

What Should Root Bundle Providers Do?

Bundle providers should provide p11-kit persistence files with Distrust After attributes, so that TLS clients like GnuTLS can take advantage. This shouldn't be too hard, since the p11-kit persistence format is just PEM with some Explanatory Text between the CERTIFICATE blocks. In theory, existing PEM parsers should be able to parse p11-kit persistence files, though for whatever reason Fedora chose to ship separate files for each format in their ca-certificates package.

As for the PEM bundles, I think it's preferable to simply ignore the Distrust After date and include the roots. While this may be seen as the less secure option compared to omitting the roots, in practice the security value of Distrust After is virtually nonexistent, since CAs can trivially circumvent it by backdating the certificate's Not Before time. Although Mozilla threatens to fully distrust CAs caught doing this, I view the threat as pretty meaningless. Since Firefox doesn't require certificates (or their corresponding precertificates) to be logged in Certificate Transparency logs (yet), it's wishful thinking to believe backdated certificates would be discovered - the CA would simply not log the precertificates for backdated certificates. If an unlogged certificate did make its way into Certificate Transparency logs, it would be difficult to prove it was backdated, as it could have plausibly been logged by a third party long after it was issued.

Rather than provide security, the point of Distrust After is to gracefully sunset a CA that is not immediately dangerous but which has fallen short of the high standards expected of CAs. As long as the certificate validator rejects certificates that are valid for more than 398 days, the CA won't be able to set the Not After (expiration) date of a backdated certificate more than 398 days after the Distrust After date. This ensures that all certificates issued by the CA will eventually expire, allowing the root to be fully removed without breaking any sites.

I think this goal would have been much better accomplished by restricting the Not After date instead of the Not Before date. For example, instead of rejecting Entrust certificates issued after November 30, 2024, Firefox should reject Entrust certificates expiring after January 2, 2026 (398 days later, the same date on which it will be safe to fully remove Entrust roots). Doing it this way would make the security properties extremely clear, and it would be harder to misinterpret as curl and Certifi have.

I have opened bugs with curl (since resolved) and with Certifi about this issue. But even if they are fixed, there may be other certdata.txt consumers who have misinterpreted Distrust After who will begin rejecting all Entrust certificates beginning November 30, so it would still be prudent for server operators to replace their Entrust certificates.