In order for their issued SSL certificates to remain trusted by web browsers, certificate authorities are expected to comply with various requirements. All major browsers require certificate authorities to comply with the CA/B Forum’s Baseline Requirements when issuing certificates. The CA/B Forum also maintains a separate set of requirements specific to extended validation (EV) certificates.
In March 2015, Google pushed updates to its Chrome desktop browser such that certificate transparency (CT) is required for EV certificates – any certificates that do not meet Google’s CT requirements are no longer treated as EV by version 42 or later. Chrome also displays security warnings for certificates with certain violations of the Baseline Requirements, for example a certificate with too long a validity period.
Whilst publicly-trusted certificate authorities undergo annual audits, many issued certificates nevertheless fail to comply with the Baseline Requirements and the EV requirements set by the CA/B Forum. Additionally, Netcraft’s June 2015 SSL Survey data revealed that a significant proportion of EV certificates do not meet Google’s CT requirements and therefore failed to receive EV treatment in the latest version of Chrome.
Certificate Compliance Checking
Netcraft can promptly identify, and bring to your attention, certificates issued by your certificate authority that fail to comply with the Baseline Requirements, the CA/B Forum’s EV requirements, or Google’s CT requirements for EV certificates. This data is delivered as a monthly spreadsheet, and covers all certificate authorities. Netcraft also provides an API that can be used to check certificates for violations immediately pre- and post-issuance before they are passed onto your customer. The API can also be presented to mimic a CT log, allowing for easy integration by certificate authorities who are already submitting precertificates to logs and embedding SCTs in certificates. Netcraft’s certificate violations API can be used to eliminate all certificate compliance issues before your issued certificates are deployed on any public servers.
Full compliance with the CA/B Forum’s requirements will ensure that your certificates remain trusted by all major browsers and display without security warnings. By meeting Google’s CT requirements, your issued EV certificates should always receive the EV indicator in Chrome.
Netcraft’s violations service also provides warnings where certificates ignore recommendations set by the CA/B Forum. Netcraft also provides recommendations of its own, for example using aggregate data to alert when two or more distinct certificates using the same public key are detected (even if the each certificate was issued by a different certificate authority).
Certificate Transparency and Chrome
As of March 2015, Google’s Chrome desktop browser has a Certificate Transparency (CT) requirement for all EV certificates, regardless of when a certificate was issued. Google also plans to require CT for domain- and organisation-validated certificates in the future. Despite these new requirements, many certificate authorities continue to issue EV certificates that fail to receive the EV indicator in Chrome. This is often due to a lack of embedded SCTs meeting the independence requirement, but Netcraft has also identified some certificate authorities who have embedded SCTs with invalid signatures. During Netcraft’s June 2015 SSL survey, a significant proportion of all valid EV certificates were found to violate Chrome’s CT for EV requirements.
In order to guarantee EV treatment, certificate authorities should reissue all affected certificates with new certificates that meet the CT requirements.
Certificate Transparency allows interested parties to monitor and audit the issuance of SSL certificates in real time. It allows for early detection of mis-issued or maliciously-issued certificates, and can also assist in the identification of rogue certificate authorities.
In order for a certificate issued after 1st January 2015 to be treated as EV by Chrome, several signed certificate timestamps (SCTs) are required. SCTs are obtained from CT log servers, and serve as a promise that the certificate will be included in the log. These logs are at the centre of CT—they are publicly-auditable and append-only, ensuring the ability to detect foul play. SCTs can be delivered to a browser in a number of ways:
- Embedded within the certificate: a certificate authority can submit a pre-certificate to certificate logs, receive the SCTs, and embed them within the final certificate;
- OCSP stapling: the SCTs can be presented in a stapled OCSP (online certificate status protocol) response alongside the certificate;
- TLS extension the SCTs can be presented alongside the certificate using the
When considering SCTs embedded within a certificate, the number required by Chrome depends on the certificate’s validity period (e.g. 3 SCTs are required for a 27 month EV certificate). Alternatively, it is sufficient for two SCTs to be provided using either OCSP stapling or the TLS extension. Google also requires) independence for the presented SCTs – there must be at least one SCT from a Google-operated log, and another from a non-Google-operated log.
Since most TLS servers do not support OCSP stapling or the necessary TLS extension, embedding the SCTs within a certificate is the only viable option to meet Google’s CT requirements. In order for their EV certificates to be treated as such in Chrome, certificate authorities should be embedding SCTs within issued certificates.
Whitelist for Pre-2015 EV Certificates
SCTs are only required by Chrome in the TLS handshake (either within the certificate, or otherwise) for EV certificates issued after 1st January 2015. For EV certificates issued before then, Google produced a whitelist – certificates were included in this whitelist as long as they were present in at least one CT log and didn’t already qualify via SCTs embedded within the certificate. Any EV certificates issued before 2015 that were not included in Google’s whitelist are no longer treated as EV by Chrome, unless they are served with a sufficient number of SCTs through either OCSP stapling or the TLS extension, or the issuing certificate authority had already begun embedding SCTs within certificates.
Netcraft finds several SSL certificates that violate the CA/B Forum’s Baseline Requirements. Web browsers require their trusted certificate authorities to comply with these requirements, and the certificate authorities are audited annually. Netcraft automatically checks for many possible certificate violations, taking a certificate’s issuance date into account. Some of the most commonly violated certificate requirements are as follows:
- The Issuer Country Name field is required
- The Subject Alternative Name extension is required
- Any entry in the Subject Common Name field must also appear in the Subject Alternative Name extension
- Internal hostnames and IP addresses are prohibited in the Subject Common Name and Subject Alternative Name fields
- The period between the Not Before and Not After dates must not exceed 39 months
- At least one OCSP responder is required unless the site is both highly trafficked and uses OCSP stapling
Extended Validation (EV) Requirements
In addition to the Baseline Requirements, which also apply to EV certificates, the CA/B Forum maintains a separate document of requirements specific to EV certificates. Common mistakes made by certificate authorities with respect to these requirements are EV certificates with too long a validity period, missing required fields, and Subject Common Name and Alternative Names fields containing non-DNS values.
Using data from its SSL Survey
, Netcraft can identify certificates that violate any of the requirements described above, and bring them to your attention. We provide a monthly report on non-compliant certificates issued both directly by your certificate authority, and also by any subordinate certificate authorities. Data is also provided for all other publicly-trusted certificate authorities. Additionally, Netcraft provides an API that can be used to test certificates immediately pre- and post-issuance, solving compliance problems before certificates are publicly deployed. This API can optionally mimic the
add-chain endpoint of a CT log, allowing for easy integration by certificate authorities who already submit precertificates to logs.
Netcraft offers several other services that may also be of interest to certificate authorities, including: