Certificate authorities have sold thousands of Extended Validation (EV) certificates that do not display correctly in Google Chrome. Over 10,000 EV certificates (5% of all EV certificates) fail to receive the green EV indicator in the latest desktop version of Google Chrome.

Certificate authorities market EV, and justify its cost, by highlighting the increased trust instilled by the green bar containing the company’s name. Without the green EV bar, visitors will struggle to distinguish a $1,000 EV certificate from a $10 domain-validated certificate.

The lack of EV indicator for these certificates reflects Google’s policy requiring EV certificates to be delivered with Certificate Transparency information. Up to half of an affected site’s visitors may be affected, given Chrome’s significant market share. Most CAs have sold this type of flawed EV certificate; however, the extent to which each CA’s certificates are affected varies significantly.

Advertising

Certificate marketing page advertising the “green bar” indication.

Almost universally, CAs advertise their EV products as (unconditionally) triggering browsers’ green bars:

• Symantec: "Extended Validation triggers the green address bar in high security browsers"
• GlobalSign: "Activate the green address bar: clear security indicator increases user trust"
• Entrust: "Site visitors see a green Web browser address bar"
• Comodo: "Green address bar provides immediate trust"
• GoDaddy: "Green address bar"
• DigiCert: "Green in the address bar"

Such advertising underlines one of the primary reasons to purchase an EV certificate over a cheaper option — the green bar that is visible in the address bar.

This additional assurance comes at a price: EV certificates command a significant premium over the cheapest type of certificate. For example, Symantec’s EV certificates cost $995 per year, almost $600 more than its cheapest directly advertised option. If you include its other brands, a Symantec DV certificate can be had for $10.95 per year.

Extended Validation

PayPal’s EV certificate in Google Chrome. The address bar features a green indicator, and also displays the company name and location (highlighted in red). The presence of valid Certificate Transparency information is indicated (highlighted in blue).

The guidelines for issuing Extended Validation certificates were first published by the CA/Browser Forum in June 2007, motivated by the lack of a well-defined standard for high-assurance identity verification. As well as validating control over the requested domain names, CAs identify the requesting organisation. Major browsers typically display the validated organisation’s name in a green box in the address bar. The cheapest type of certificate, domain-validated, does not include this additional information and does not trigger the green box.

Merely issuing a certificate following the EV guidelines is not sufficient for the certificate to trigger the browser’s special treatment: the CA’s root certificate must be embedded in the browser; the CA must be specifically approved to issue EV certificates; and the certificate must conform to any additional policies set by the browser. Certificate authorities are periodically audited against these requirements, and are required to publish audit statements, though many audited CAs still issue non-compliant certificates.

All major browser vendors are members of the CA/Browser Forum that defines the EV guidelines, and most maintain an independent CA inclusion policy that can be more or less strict than the published minimum requirements. For example, Mozilla, Google, Microsoft, and Apple maintain separate EV policies and CAs must apply to each individually to obtain EV treatment in their browser.

Certificate Transparency

Google has recently added the additional condition that in order to be treated as EV in Chrome, the certificate must be present in a Certificate Transparency log and be bundled with a timestamp (an SCT) signed by the log. This policy for EV certificates is intended to be a trial run for requiring Certificate Transparency for all certificates.

Certificate Transparency is motivated by incidents like DigiNotar, mis-issuance from CNNIC, TURKTRUST, ANSSI, and TrustWave’s issuance of a MiTM certificate. By requiring newly issued certificates to be logged in publicly-auditable databases, Google hopes to make it easy to monitor domains for rogue certificates, and to enable regular and post-incident analysis of CA issuance practices.

The signed timestamps (SCTs) can be delivered to the browser in three ways: embedded in the certificate itself, delivered via a stapled OCSP response, or included in a custom TLS extension by the web server. Only the first option is currently practical according to Google as it does not require the certificate holder to update their server software. The second option requires support from the CA in its OCSP responder software, and the client must enable OCSP stapling. Almost three-quarters of all SSL certificates were delivered without a stapled OCSP response in the August 2015 Netcraft SSL Server Survey. The TLS extension, on the other hand, does not require CA support at all, but server-side support is not yet widely available.

Chrome’s policy only applies to EV certificates issued after 1st January 2015. At the start of 2015, Google produced a whitelist of existing EV certificates: certificates were included if they were present in at least one qualifying CT log and didn’t otherwise already comply. EV certificates that are not included in the whitelist must comply with the new policy. While it is possible for pre-2015 non-whitelisted certificates to comply — using a stapled OCSP response or in the TLS extension — it is not trivial to configure.

Netcraft’s Site Report tool can be used to inspect the SCTs (if any) presented by a given website and whether or not the certificate is present in Google’s whitelist.

Widespread failures

Many CAs have issued EV certificates that do not meet Google’s requirements, which has resulted in over 10,000 certificates not receiving the EV indicator in the current version of Chrome. Of these certificates, 42% were issued after 1st January 2015, whilst the remaining 58% were issued pre-2015 but are missing from the whitelist and do not otherwise qualify.

Chrome’s Address Bar	EV	Notes
	Yes	Normal EV display in Google Chrome
	No	Normal non-EV display in Google Chrome

Expected behaviour for SSL certificate display in Google Chrome’s address bar.

Certificate Authority	Chrome’s Address Bar	EV	Issued	Notes
Symantec		Yes	Jun 29 2015	No SCTs received
DigiCert (Verizon)		Yes	Mar 16 2015	No SCTs received
DigiCert		Yes	Aug 22 2014	Not in Google’s whitelist†
GoDaddy		Yes	Jun 25 2015	Too few SCTs for validity period
Entrust		Yes	Apr 10 2015	Malformed signatures in SCTs
GlobalSign		Yes	Feb 24 2015	No SCTs received
StartCom		Yes	Jun 29 2015	No SCTs received
WoSign		Yes	Jul 6 2015	No SCTs received

Actual behaviour of SSL certificate display in Google Chrome’s address bar.
†This certificate should have been included on the whitelist; however, a bug in Google’s whitelist meant it was incorrectly excluded.

A GlobalSign certificate that despite having undergone EV validation, fails to trigger the green bar in Chrome.

Whilst most CAs have issued at least some EV certificates with embedded SCTs, others have not embraced Certificate Transparency at all.

WoSign has never issued an EV certificate that contains embedded SCTs and it does not support the second-most-prevalent method for delivering SCTs — via its OCSP responses. This is also the case for StartCom, where almost 100% of EV certificates issued by StartCom so far in 2015 fail to receive EV treatment in Chrome. Some StartCom EV certificates are receiving the EV indicator as a result of Google’s one-off whitelist, and a single post-2015 certificate is being used on a server that supports sending SCTs via the TLS extension. WoSign and StartCom are not alone, however, as several other CAs have issued EV certificates without embeddeding SCTs, including Certplus (OpenTrust/KEYNECTIS).

Although Google produced a whitelist of existing EV certificates at the start of 2015, a significant number of pre-2015 certificates lost their EV treatment after Google Chrome started enforcing its CT policy. CAs had the opportunity to inspect Google’s draft whitelist; however, many certificates were not submitted to a CT log in time. As well as omissions by the CAs, there were also errors in the mechanism used by Google to generate the whitelist.

The second type of failure to be included in the whitelist, bugs in Google’s implementation, can be demonstrated by examining a DigiCert certificate^† (serial number 0ae01c52bf4917b4527c20bae5e2cd82): it is present in at least one Google CT log with a timestamp indicating it was first logged on 28th August 2014:

Log: https://ct.googleapis.com/pilot
Entry ID: 4867084
Timestamp: 2014-08-28 11:56:54 GMT
Certificate Serial Number: 0ae01c52bf4917b4527c20bae5e2cd82

Despite being logged in accordance with Google’s policies, it does not appear in Google’s whitelist. In this case, a bug in Google’s whitelisting code meant it was incorrectly excluded.

Some CAs offer the option to their customers to not include SCTs in their EV certificates, where inclusion in a public log would leak DNS names the customer would rather keep private. However, all of the certificates in this analysis were found on public-facing HTTPS services by Netcraft’s SSL survey, or were included in CT logs.

Google’s latest policy update in May 2015 could mean that 7,000 more EV certificates will lose the green bar treatment in Chrome. Certificates must now be delivered with SCTs from independent logs — i.e. at least one Google log and one non-Google log. Certificates that do not meet this new requirement still receive the green bar in Chrome, but are anticipated to stop working when Chrome’s code catches up with the new policy. It is not clear whether certificates issued before the policy update will be whitelisted or subjected to the new policy.

Comodo is the CA most affected by the May 2015 policy update, with almost 6,000 EV certificates at risk if Google’s new policy is applied from 1st Jan 2015. Comodo has recently issued certificates with SCTs from too few independent logs: for example, Comodo issued a certificate on 3rd August 2015 that is missing a non-Google SCT.

Before they were eventually deployed in March 2015, CAs had known for over a year that the changes to Chrome’s EV behaviour were coming. Google’s intention was for CAs to ensure that all issued certificates were meeting the requirements before the effective date. This was not the case for most CAs, however, and many non-compliant certificates remain in existence now that Chrome is enforcing the requirements. Worse still, many CAs are continuing to sell EV certificates that will not receive the indicator in Chrome.

Identifying non-compliant certificates

Using data from its SSL Survey, Netcraft’s certificate compliance checking service can promptly identify, and bring to the attention of CAs, all kinds of non-compliant certificates, including those that are not receiving the EV indicator in Chrome. The service also identifies certificates that will stop receiving the EV indicator as soon as Google’s May 2015 policy update becomes effective. By using Netcraft’s service to identify these certificates, CAs will be in a position to re-issue them such that they should once again receive the green EV indicator.

Netcraft’s service can also be used by CAs to test their certificates for compliance issues before issuance, by submitting pre-certificates or certificates to Netcraft and only releasing to customers those that are found to be fully compliant. Non-compliant certificates can then be revoked without ever being deployed.