Certificate authorities issue SSL certificates to fraudsters

In just one month, certificate authorities have issued hundreds of SSL certificates for deceptive domain names used in phishing attacks. SSL certificates lend an additional air of authenticity to phishing sites, causing the victims' browsers to display a padlock icon to indicate a secure connection. Despite industry requirements for increased vetting of high-risk requests, many fraudsters slip through the net, obtaining SSL certificates for domain names such as banskfamerica.com (issued by Comodo), ssl-paypai-inc.com (issued by Symantec), and paypwil.com (issued by GoDaddy).

CloudFlare, a content delivery network that provides free "Universal SSL" to its customers, is a hotspot for deceptive certificates, accounting for 40% of SSL certificates used by phishing attacks with deceptive domain names during August 2015. CloudFlare's Universal SSL certificates are provided in partnership with Comodo, and CloudFlare also use GlobalSign certificates for some of its customers. CloudFlare's flexible SSL option also appeals to fraudsters, offering a padlock in victims' browsers without the need for attackers to set up SSL on their web servers.

PayPal phishing site

A screenshot of a PayPal phishing site using a widely trusted SSL certificate valid for www.pay-pal.co.com. The certificate is a CloudFlare Universal SSL certificate issued by Comodo. The certificate has not been revoked; however, the phishing site is no longer available.

Websites that use TLS (the successor to SSL) are marketed as being trustworthy and operated by legitimate organisations. Consumers have been trained to "look for the padlock" in their browser before submitting sensitive information to websites, such as passwords and credit card numbers. While the reality is more nuanced, the data submitted to a phishing site using TLS is protected from eavesdroppers. However, a displayed padlock alone does not imply that a site using TLS can be trusted, or is operated by a legitimate organisation.

NatWest phishing site

A screenshot of a NatWest phishing site using a widely trusted SSL certificate valid for natwestnwolb.co.uk. (nwolb stands for NatWest online banking. The legitimate NatWest online banking service is available at www.nwolb.com.)

Bank of America phishing site

A screenshot of a Bank of America phishing site using a widely trusted SSL certificate valid for banskfamerica.com.

The following table lists some examples of deceptive SSL certificates that have been used to conduct phishing attacks, along with their Domain Registration Risk scores:

Hostname Phishing Target Certificate Authority Assurance Risk Score Revoked
halifaxonline-uk.com Halifax GlobalSign (CloudFlare) OV* 10.0 No
emergencypaypal.net PayPal Comodo (CloudFlare) OV* 9.17 Yes
blockchaín.info (xn--blockchan-n5a.info) Blockchain GlobalSign (CloudFlare) OV* 8.52 No
blockachain.info Blockchain Comodo DV 8.42 No
itunes-security.net Apple iTunes Symantec DV 8.08 No
phypal.com PayPal Symantec DV 6.61 No
btintranert.com BT GoDaddy DV 5.56 Yes

* The certificates that CloudFlare issues to its customers are ostensibly organisation-validated, as they contain CloudFlare's company name and address. However, the customer domains themselves are only domain-validated.

The CA/Browser Forum's Baseline Requirements – a set of rules that publicly-trusted certificate authorities are expected to follow – require that high-risk domain names that may be used for fraud or phishing are subjected to additional verification:

High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage.
The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval.

Despite this requirement, many major certificate authorities issue SSL certificates for deceptive domains used in phishing attacks. Notable exceptions include DigiCert and Entrust, neither of which issue domain-validated certificates.

A pie chart showing SSL certificates containing a deceptive domain name that were used in phishing attacks during August 2015, split by certificate authority. CloudFlare and non-CloudFlare certificates are shown separately.

Certificate authorities commonly provide SSL certificates at three different levels of assurance:

  • Domain validated (DV)
    Certificate authorities only have to check that the certificate's applicant controls the domain name contained in a DV certificate. These certificates are typically the cheapest option, and can be had for free or be purchased for less than $10. Let's Encrypt is planning to offer free, automatically-issued DV certificates starting later in 2015.
  • Organisation validated (OV)
    In addition to validating the domain name in the certificate, the identity of the person or organisation applying for an OV certificate is also verified by the certificate authority and included in the certificate. Most browsers do not treat OV certificates any differently to DV certificates.
  • Extended validation (EV)
    Like OV certificates, the identity of the organisation applying for an EV certificate is verified by the certificate authority. However, the verification is more stringent. EV certificates also receive different treatment in major web browsers – the address bar is either partially or completely coloured green and the requesting organisation's name and country are displayed next to the padlock. The requirements for EV certificates in Chrome are changing, with many certificate authorities caught out by recent changes to require Certificate Transparency.

The requirement to perform additional verification of high risk certificate requests applies to all levels of assurance. However, DV certificates are often issued completely automatically within minutes, making it easy for fraudsters to obtain DV certificates for deceptive domain names.

Several certificate authorities offer free trial certificates with shorter validity periods. For example, Comodo offers free 90 day certificates, which have been used by a number of SSL phishing attacks. Symantec also offers free 30 day certificates through its GeoTrust brand. The short validity periods are ideal for fraudsters as phishing attacks themselves typically have short lifetimes.

Netcraft's Domain Registration Risk service automatically identifies deceptive domain names constructed using such tricks. The service calculates a risk score between 0 (low risk) and 10 (high risk) for each domain name, which represents the likelihood that the domain name will be used to carry out a phishing attack. Certificate authorities can make use of the service to determine if a domain name is likely to be used for fraudulent purposes before issuing the certificate.

The service can be provided as an API that mimics a Certificate Transparency log server for ease of integration with your existing certificate issuance process. The same API can also be used with Netcraft's certificate compliance checking service, which can identify certificates before they are issued that do not conform with the CA/B Forum's Baseline Requirements or its EV Guidelines.

Most Reliable Hosting Company Sites in September 2015

Rank Performance Graph OS Outage
DNS Connect First
1 GoDaddy.com Inc Linux 0:00:00 0.000 0.256 0.008 0.019 0.019
2 Datapipe Linux 0:00:00 0.004 0.164 0.012 0.025 0.032
3 Qube Managed Services Linux 0:00:00 0.004 0.150 0.044 0.089 0.089
4 XILO Communications Ltd. Linux 0:00:00 0.009 0.224 0.064 0.128 0.129
5 Memset Linux 0:00:00 0.013 0.159 0.065 0.158 0.248
6 EveryCity SmartOS 0:00:00 0.018 0.100 0.067 0.133 0.134
7 Anexia Linux 0:00:00 0.018 0.191 0.086 0.174 0.174
8 Pickaweb Linux 0:00:00 0.026 0.305 0.010 0.168 0.169
9 Hyve Managed Hosting Linux 0:00:00 0.031 0.110 0.063 0.127 0.128
10 Pair Networks FreeBSD 0:00:00 0.031 0.241 0.070 0.141 0.141

See full table

For the second month in a row, GoDaddy had the most reliable hosting company website. Throughout September, it was the only company to respond to all of Netcraft's requests, with an average connection time of only 8 milliseconds. This is the fifth time this year that GoDaddy has been in the top ten.

GoDaddy recently added new features to its GoDaddy Pro programme, which has grown to more than 50,000 members since its launch in June. Aimed at web designers and developers, it allows members to manage clients and clients' products, offering discounts of at least 30%.

Datapipe had the second most reliable hosting company website in September, with just a single failed request. Datapipe came first in July, and August was the only month so far this year when it was absent from the top ten.

On 9 September 2015, Datapipe announced that it had acquired DualSpark – an Amazon Web Services assessment, automation and migration company, which was founded by former AWS managers. Datapipe hopes to use DualSpark's DevOps and automation expertise to bring increased levels of support to its cloud clients.

Qube Managed Services ranked third in September, also with only one failed request, but with a marginally longer average connection time than Datapipe. Qube's site has appeared in the top ten for all but two months so far in 2015, making this its seventh appearance.

Linux dominates the chart this month, being used by eight of the top ten sites, and all of the top five. EveryCity uses the SmartOS community fork of OpenSolaris, while Pair Networks uses the FreeBSD operating system. This is the third month in a row where Microsoft Windows has been completely absent from the top ten.

Netcraft measures and makes available the response times of around forty leading hosting providers' sites. The performance measurements are made at fifteen minute intervals from separate points around the internet, and averages are calculated over the immediately preceding 24 hour period.

From a customer's point of view, the percentage of failed requests is more pertinent than outages on hosting companies' own sites, as this gives a pointer to reliability of routing, and this is why we choose to rank our table by fewest failed requests, rather than shortest periods of outage. In the event the number of failed requests are equal then sites are ranked by average connection times.

Information on the measurement process and current measurements is available.

eBay phishing sites hosted by… eBay

Fraudsters are stealing eBay usernames and passwords using phishing pages hosted on eBay's own infrastructure. One of these pages, targeting German users, is shown below:

An eBay phishing form hosted on eBay's own infrastructure. The form contents are submitted to an external domain in Russia.

An eBay phishing form hosted on eBay's own infrastructure. The form contents are submitted to an external domain in Russia.

The convincing appearance of the spoof login form is bolstered by the fact that it is hosted on a genuine eBay domain, ebaydesc.com. This domain is ordinarily used to host descriptions for eBay listings which are displayed within iframes on eBay listing pages.

In this case, the corresponding eBay listing has already been deleted, although the phishing content within the listing's description can still be viewed by browsing directly to the relevant URL on vi.vipr.ebaydesc.com. Consequently, the attack is still live and capable of stealing credentials from eBay users.

The URL of the credential-stealing script is only momentarily visible in the address bar before the victim is redirected to the genuine eBay site.

The URL of the credential-stealing script is only momentarily visible in the address bar before the victim is redirected to the genuine eBay site.

When a victim enters his username and password into the form, both values are submitted to a PHP script hosted on a server in Russia. After stealing the credentials, this script then redirects the victim to the genuine ebay.de login page, which reports that the username or password was incorrect.

After the victim's credentials are stolen, he is redirected to the real eBay login page. Note that the username field has been automatically populated with the username stolen by the fraudster.

After the victim's credentials are stolen, he is redirected to the real eBay login page. Note that the username field has been automatically populated with the username stolen by the fraudster.

This error message might cause the victim to become suspicious enough to look at the browser's address bar, to check he is on the right website; but it will already be too late at this point – his credentials will have already been stolen, and because his browser will now be showing ebay.de in the address bar, he may not even realise that his credentials have just been sent to a web server in Russia. There is consequently little chance of the victim reacting by changing his password, allowing the fraudster to take full advantage of the stolen credentials at his leisure.

The website involved in collecting the stolen credentials has also been used to host other phishing attacks targeting German-speaking consumers, including sites impersonating PayPal, Apple, and mobile.de.

In an attempt to evade detection by eBay and others, the fraudster has obfuscated the HTML source of his eBay phishing form. This makes it impossible to find such a listing by searching for any of the words that appear in the description, yet the rendered results appear as normal when viewed in a web browser.

The obfuscated HTML source used by the phishing content hosted by eBay.

The obfuscated HTML source used by the phishing content hosted by eBay.

Allowing anyone to insert arbitrary HTML and malicious scripts into a listing's description gives plentiful opportunities to would-be fraudsters, particularly as this weakness has been exploited to carry out similar attacks against eBay users in the past. Last year, Netcraft reported on fraudsters injecting malicious JavaScript into eBay listings to set up man-in-the-middle attacks against car buyers, and similar JavaScript redirection techniques have continued to be exploited throughout 2015.

These phishing methods can be much more successful than traditional phishing attacks (where content is hosted solely on an unrelated domain). The techniques employed in these latest attacks are not permitted under eBay's HTML and JavaScript policy; however, a fraudster intent on stealing passwords is not going to be deterred by words alone.

September 2015 Web Server Survey

In the September 2015 survey we received responses from 892,743,625 sites and 5,438,101 web-facing computers. Both of these key metrics grew this month, with net gains of 18 million sites and 47,000 computers.

Microsoft made by far the largest gain in hostnames this month, with an additional 33.6 million sites bringing its total up to 265 million. Combined with a 15.9 million loss in Apache-powered sites, the difference between Microsoft's and Apache's market shares has now halved: Microsoft's share went up by 3.22 percentage points to 29.68%, while Apache's fell by 2.55 to 34.96%, reducing Apache's lead to just over five percentage points.

However, September's growth in web-facing computers paints a different picture, with Apache's net gain of 19,800 computers being more than six times higher than Microsoft's. Despite this, both Microsoft and Apache lost market share this month, while nginx – which gained the most web-facing computers in September (+22,100) – grew its share to nearly 13%. With an additional 6.9 million sites bumping its site share up to 15.60%, nginx was the only major server vendor to increase its market share in both sites and computers this month.

Despite no longer being supported by Microsoft, the number of websites using Microsoft IIS 6.0 (which typically runs on Windows Server 2003) has since grown by 19% and accounted for much of the overall Microsoft hostname growth this month. 153 million websites are now using Microsoft IIS 6.0, compared with 129 million in July; however, the number of web-facing computers using IIS 6.0 has fallen by 6%, and the number of active sites fell by 16%.

China accounted for around a third of this month's overall growth in web facing computers, outpacing the growth seen in the United States and Germany by a factor of three. Even so, China was responsible for only a tiny fraction of this month's site growth. Microsoft Windows continues to be the preferred hosting platform for computers in China, where it is currently used by 42% of all web-facing computers and 43% of all sites. Astoundingly, over half of these Windows computers are running Windows Server 2003, and some Chinese hosting providers continue to provide new installations of this deprecated operating system.

Amongst the world's top million websites, nginx has continued to increase its market share and now powers more than twice as many sites as Microsoft. Apache's share has been steadily declining over the past few years mostly as a result of nginx's gains, but it looks set to remain the dominant server vendor within the top million for a while longer, as it is still used by more than twice as many sites as nginx.

Total number of websites

Web server market share

DeveloperAugust 2015PercentSeptember 2015PercentChange
Continue reading

Most Reliable Hosting Company Sites in August 2015

Rank Performance Graph OS Outage
DNS Connect First
1 GoDaddy.com Inc Linux 0:00:00 0.004 0.235 0.008 0.019 0.020
2 Qube Managed Services Linux 0:00:00 0.004 0.149 0.047 0.097 0.097
3 ServerStack Linux 0:00:00 0.004 0.131 0.066 0.133 0.133
4 Pair Networks FreeBSD 0:00:00 0.004 0.239 0.070 0.142 0.142
5 Anexia Linux 0:00:00 0.004 0.191 0.083 0.169 0.169
6 XILO Communications Ltd. Linux 0:00:00 0.008 0.218 0.063 0.125 0.125
7 INetU Linux 0:00:00 0.008 0.128 0.066 0.135 0.135
8 Hyve Managed Hosting Linux 0:00:00 0.013 0.113 0.061 0.122 0.123
9 EveryCity SmartOS 0:00:00 0.013 0.098 0.067 0.134 0.134
10 www.dinahosting.com Linux 0:00:00 0.013 0.274 0.084 0.169 0.169

See full table

GoDaddy had the most reliable company website in August, responding successfully to all but one of Netcraft's requests. This marks GoDaddy's third consecutive appearance in the top 10 in 2015, and the first time it has topped the charts this year. GoDaddy has recently added a number of new features to GoDaddy Online Store, which makes it simpler for online merchants to build ecommerce sites. These features include integration with Shippo as well as GoDaddy Email Marketing.

Qube, Serverstack, Pair Networks, and Anexia also had only one failed request each this month, placing second, third, fourth, and fifth respectively based on the average connection time. This is Pair Networks' first appearance in the top 10 this year. Pittsburgh-based Pair Networks is also the only site running FreeBSD this month.

Linux remains the most common choice of operating system, powering 8 of the 10 sites. This is the second consecutive month without any sites powered by Windows appearing in the top 10.

Netcraft measures and makes available the response times of around forty leading hosting providers' sites. The performance measurements are made at fifteen minute intervals from separate points around the internet, and averages are calculated over the immediately preceding 24 hour period.

From a customer's point of view, the percentage of failed requests is more pertinent than outages on hosting companies' own sites, as this gives a pointer to reliability of routing, and this is why we choose to rank our table by fewest failed requests, rather than shortest periods of outage. In the event the number of failed requests are equal then sites are ranked by average connection times.

Information on the measurement process and current measurements is available.

Thousands short-changed by EV certificates that don’t display correctly in Chrome

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.


The Lloyds Bank login page, as viewed in Chrome 44 (above) and Firefox (below). The SSL certificate, issued by Symantec in June 2015, fails to receive the green EV indicator in Chrome.


Certificate marketing page advertising the "green bar" indication.

Certificate marketing page advertising the "green bar" indication.

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

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

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


DigiCert includes its recently acquired roots that previously belonged to Verizon Business.

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.