WEBINAR: Phishing Campaigns Deconstructed | Watch now  

Resources > Blog > Certificate Authorities struggle to comply with Baseline Requirements
Robert Duncan

Certificate Authorities struggle to comply with Baseline Requirements

SSL Certificate Authorities (CAs) are responsible for issuing the SSL certificates which are used to protect billions of secure transactions across the internet against eavesdroppers and impersonators. The CA/B forum — a group of CAs and browser vendors — drew up the Baseline Requirements in 2011 outlining a set of minimum standards to which all CAs should operate.

Since the “effective date” of the document, 1st July 2012, compliance with the Baseline Requirements has been mixed — Netcraft has previously discovered non-compliant certificates, including short RSA public keys and irrevocable certificates. More than a year on and several months after Mozilla incorporated the Baseline Requirements into its CA policy (albeit with a transition period allowed) CAs are still issuing non-compliant certificates.

By examining the certificates found in Netcraft’s SSL Survey and evaluating them against a small subset of rules extracted from the Baseline Requirements document, Netcraft found more than 2,500 non-compliant certificates. The non-complaint certificates fall into one or more of the categories described below: some of the problems are serious security vulnerabilities, and others are less critical but are still violations of the Baseline Requirements.

  • Short RSA public key — the shorter a public key is; the easier it is for an attacker (such as the NSA) to brute-force the secret private key, and hence decrypt communication. NIST recommended that certificates should not use RSA public keys shorter than 2048 bits after December 2013 and the CA/B forum imposes the same rule.
  • Missing OCSP URL — OCSP is one of the two available revocation mechanisms available to CAs to disable the certificate after it has been issued. As web-browser support for certificate revocation varies, non-EV certificates without an OCSP URL are effectively irrevocable in Firefox. Without the ability to revoke certificates, if the certificate were ever to be compromised — by criminals or government agencies — it could be used for up to five years. The Baseline Requirements do allow certificates to omit the OCSP URL if and only if they are used on “high traffic” websites and the website staples the OCSP response to the TLS handshake — none of the websites with missing OCSP URLs highlighted here did so.
  • SAN extension — the Baseline Requirements document discourages the use of the Subject Common Name field to contain the hostname for which the certificate is valid. Instead, the Subject Alternative Name extension should be used and it must contain at least one record. Additionally, any hostname in the Subject CN field must also be duplicated in the SAN extension — a multi-domain certificate intended for www1.example.com and www2.example.com must contain both in the SAN extension and at most one in the Subject CN (for backwards compatibility).
  • Validity Period — as of the effective date, the Baseline Requirements limit the maximum validity period of a certificate to 5 years (60 months). Whilst exceeding this validity period constraint isn’t itself a security problem it slows downs the pace of change within the industry — with a shorter maximum validity period, browsers can rely on legacy behaviour disappearing and can remove insecure functionality more rapidly.

A short key warning for a 512-bit certificate in Google Chrome. This type of warning is proposed to be applied to certificates violating the maximum validity period.

Several large CAs have issued non-compliant certificates since July 2013, a year after the original deadline, including Symantec, Go Daddy, and Verizon Business.

  • Symantec — a BMW certificate issued by TC Trust Center (a Symantec company) is missing an OCSP URL and does not include a stapled OCSP response, making it irrevocable in Firefox. An SSL certificate used for online banking was issued by VeriSign on August 2nd 2013 without the required SAN extension.
  • Verizon Business — a certificate issued by Etisalat (a UAE-based telecoms provider which operates a Verizon Business signed sub-CA) for ADCO, an onshore oil drilling company, violates a number of Baseline Requirements: it has a short RSA key valid after 31st December 2013, it has no OCSP URL and it does not have the mandatory SAN extension. Etisalat has previously been associated with SSL interception. Cybertrust, operated directly by Verizon Business, has also issued more than its fair share of non-compliant certificates including certificates belonging to Target [Short Key, no OCSP URL], the US Dept. for Homeland Security [no SAN, no OCSP URL], and American Express [an EV certificate without an OCSP URL!]. A number of other sub-CAs signed by Verizon Business have issued non-compliant certificates including Microsoft [missing SAN, no OCSP URL] and Vodafone [missing SAN].
  • SwissSign — Nestlé, a customer of SwissSign with its own intermediate certificate, has issued non-compliant certificates including: those missing SAN records and OCSP URLs.
  • Go Daddy — a significant number of Go Daddy certificates exceed the maximum permitted validity period of 5 years. These certificates are likely “re-issued” (the meaning of which is debated by Google, see below) and otherwise do not obviously violate the Baseline Requirements. Go Daddy have proposed a modification to the Baseline Requirements to allow such re-issued certificates to be exempt from maximum validity period constraints.

Google Chrome, in the first quarter of 2014, will reject all certificates issued after the effective date, 1st July 2012, which violate the maximum validity period (60 months). A number of CAs have issued such certificates, often as part of a re-issuance process, which Google deems to be non-compliant with the Baseline Requirements.

In the September 2013 SSL Survey, using the criteria from the proposed Google Chrome patch, Netcraft found 3,243 certificates which will be considered invalid in Google Chrome as a result of this change. Go Daddy issued over three-quarters of these certificates (2,498) and Comodo also issued a significant number (606). The longest-lived non-compliant certificate issued by a member of the CA/B Forum and discovered by the SSL Survey has a validity period of over 82 months.

Furthermore, Google’s technical enforcement is set to get tougher: Ryan Sleevi has stated that certificates with short public keys – that is, RSA public keys shorter than 2048 bits expiring after 31st December 2013 are “next up” on Google’s list. Google’s proposal to use the original July 2012 date as a threshold for enforcement isn’t popular with some of the CAs in the CA/B forum: GlobalSign and Comodo have argued that such technical constraints should only be enforced for certificates issued after the announcement.

Despite Google’s aggressive stance, many of Google’s own certificates did not comply with some of the Baseline Requirements: in the September 2013 Netcraft SSL survey, almost 500 Google certificates did not contain a URL to an OCSP responder or include a stapled OCSP response (making the certificates irrevocable in Firefox). Since the survey ran in mid-August, a large number of Google’s certificates have been replaced and now contain an OCSP URL, but a few non-compliant certificates are still in use including one on Zagat.com. The Zagat.com certificate also has an incomplete SAN record (it does not contain the hostname from the Subject Common Name field).