Entrust mis-issues a certificate, Refuses To Follow CA/B Rules
Extended Validation certificates are a massive hole in web security
Do you prefer to listen to an awesome podcast covering most of the same topic? Check out the “Root Causes” Podcast episode on this:
Every couple of weeks, a Certificate Authority ends up having an incident. These incidents fall into two possible scenarios:
Misissuance
Non Issuance related incident
Misissuances also fall into several categories:
Missing some requirement
A software bug
A human mistake
Malicious behavior (very, very rare)
The CA/B forum has created some rules in the Baseline Requirements (BRs) for operating a CA for dealing with these misissuances. They can naively be summarized as:
Does this misissuance cause a major trust issue for the certificates?
Yes? You have to revoke within 24 hours of finding out about it.
No? You have to revoke within 5 days of finding out about it.
Somtimes root programs find it acceptable to not revoke at all, if the impact of the certificate revocation will be worse thant he impacts of the misissuance. For example, this happened when Let’s Encrypt famously was issuing certificates for 90 days plus one second. These are generally handled on a case by case basis.
I’ll talk more about this incident in the future, however this incident led to Let’s Encrypt realizing that if this misissuance was a major problem, the disruption to the web would really shake the foundations of it. So they came up with an IETF draft as a solution to at least make future mass-revocations easier to do.
One of the requirements that the Mozilla Root Program has on Certificate Authorties is to report every major, and non major incident under a specific component in Bugzilla: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#24-incidents
This requirement also says for every deviation from the rules, a separate incident must be opened. For example, if you’ve made a mistake and you’ve been misissuing certificates, you’ll need to open at least one incident report for that. Now, if as the CA you’ve also failed to revoke these mis-issued certificates in the given timeframe, you’ll have to open another incident for that.
It should be noted, incidents are not a big deal. In fact, incidents are expected for any CA with any reasonable issuance load.
This brings us to Entrust. Entrust has recently opened an incident due to accidental misissuances for their EV certificates: https://bugzilla.mozilla.org/show_bug.cgi?id=1883843
The mistake is a simple one to miss. The CA/B forum rule changes have accidentally lead to an inconsistency between the rules for Domain Validation (DV) TLS certificates, and Extended Validation (EV) certificates.
Despite this mistake in the language of the BRs, the current requirements are still valid, and should still be respected. Despite this, Entrust has chosen to:
Not stop their active misissuance
Refuse to file an incident for failure to revoke
Per Entrust’s own comment, this bug impacts over 24,000 EV certificates. We can also independently validate this number using censys:
That number may sound like a lot of certificates, however the internet as a whole is issuing nearly half a million certificates per hour:
The crux of the problem comes down to this statement Entrust made:
These certificates are generally not managed through automation and used by large enterprises including many financial institutions and governments. Reissuing this number of EV certificates will require significant resources and coordination with our customers and their relying parties.
Extended Validation certificates are broken, and bad for the security of the web:
They create a false sense of trust:
Since they can’t be automated, they
Cause outages: https://www.keyfactor.com/blog/2023s-biggest-certificate-outages-what-we-can-learn-from-them/
Put a human element in the path of certificate issuance. And humans are very prone to making mistakes.
So we have a CA that is actively mis-issuing certificates. Failing to stop the bleed and fix the problem they have at hand. Failing to follow the incident response format of one incident per problem. And the best part? Paul van Brouwershaven who is filing this incident on behalf of Entrust is the Vice-Chairperson of the CA/B Forum.
The inability for CAs to fully automate the issuance process, and the unwillingness of the browsers to police the rules and limitations the CAs and Browsers set for themselves is slowly spelling out a disaster scenario for the web. CAs need to be prepared for a situation that will require them to revoke all their certificates.
The main component in WebPKI is Public Trust. That means everyone, on the web is a stakeholder in this. The excuse of “Our large customers can’t rotate their certificates fast enough” is not a problem for the Public.
If these organizations need strict SLOs and SLAs on their certificates, they should stick to private PKI.
What the web doesn’t need is a repeat of the DigiNotar incident. And the only way we can prevent heading that way is a strict enforcement of these rules and limitations.
There is some good news on the horizon. For example, Google is moving to require automated certificate issuance interfaces for all new CAs: https://www.chromium.org/Home/chromium-security/root-ca-policy/#automation-support
Further reading on why EV certificates are not great: