More than two thousand sites using Extended Validation certificates stopped working this weekend and remain inaccessible today (Monday), including those run by banks, governments, and online shops. The EV certificates used by these sites were revoked on Saturday, and have yet to be replaced. Most visitors using modern web browsers are completely locked out: this certificate error cannot be bypassed in Chrome, Firefox, Safari, or Microsoft Edge.
Chrome’s unbypassable revoked certificate interstitial on online.anz.com. ANZ is one of the”big four” Australian banks.
Last week, DigiCert disclosed a reporting discrepancy in its audit for EV certificates. As part of its response, DigiCert committed to revoking the certificates, which it intends to complete over the coming weeks. Only a subset of DigiCert’s EV certificates are affected: in the July SSL Server Survey, Netcraft found 17,200 EV certificates in active use on port 443 that are due to be revoked.
The first batch of revocations happened this weekend. While most of the certificates revoked on Saturday 11th July have been correctly replaced and reinstalled, many have not.
On Monday morning, Netcraft found 3,800 sites still using EV certificates issued by the affected sub-CAs. Of these 3,800, more than 2,300 were still using a revoked EV certificate, completely disabling the sites for users in modern browsers, which handle EV revocation more robustly than other types of certificate. The remainder are yet to be revoked.
Many organisations appear to have been caught unawares, continuing to use revoked EV certificates, including The State Bank of India, Rackspace, Authorize.net, ANZ Bank, and Telegram.
Authorize.net using a revoked EV certificate
The New Zealand government using a revoked EV certificate
Wirecard, the beleaguered German payment processor, briefly had its main site, www.wirecard.com, displaying a certificate warning early on Monday, but the certificate has since been replaced with a working non-EV certificate. There are still a number of Wirecard domains with revoked certificate warnings.
The Baseline Requirements and EV Guidelines, the de facto rulebooks for running a CA, define two revocation timelines for subscriber certificates: 24 hours for serious security issues, and 5 days for less severe issues. If a CA fails to meet these deadlines, it is highlighted in subsequent audits. Too many failures, and a CA could go the way of StartCom and Symantec, resulting in being distrusted and effectively ending its ability to issue certificates that work in modern web browsers.
These deadlines apply to all publicly trusted certificates whether they are being used on public websites, embedded in hardware appliances, ATMs, or used in healthcare settings. While often convenient to use for non-browser use cases, it means that deploying publicly trusted certificates must be carefully considered — you may be required to replace compromised certificates with hours of notice, or replace an entire population of certificates within a handful of days.
This expectation of agility is reflected in the continued push to reduce the maximum lifetime of certificates — set to drop to just over one year in September on Apple devices, in Google Chrome and Firefox.
However, ACME, the protocol used by Let’s Encrypt, DigiCert, Sectigo and others, does not yet have robust, built-in support for replacing certificates promptly when there is a pending revocation. When Let’s Encrypt faced a similar mass revocation incident, its instructions also required manual intervention with certbot. Let’s Encrypt also did not meet the 5-day expectation in its response to that incident.
