If you're using Chrome 53, which was released last week, you might find that some websites which worked under Chrome 52 now fail with "Your connection is not private" with an error code of NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED. For example, choosemyreward.chase.com shows the following error as of publication time:

The short explanation is that Chase's system administrators made a mistake when they requested their SSL certificate from their certificate authority, Symantec, but as we shall see, Symantec shares responsibility too.

The History of Certificate Transparency

The security of HTTPS relies on organizations called certificate authorities, who issue certificates that help ensure your connections to websites are secure and private. HTTPS is only secure if certificate authorities do their job properly. If a certificate authority messes up and issues an unauthorized certificate, an attacker can use it to intercept HTTPS connections.

Unfortunately, it's difficult to ensure that certificate authorities do their job properly, and certificate authorities have repeatedly violated the public's trust by issuing unauthorized certificates, including ones which have been used in real attacks against HTTPS connections.

In response, Google created Certificate Transparency. Under Certificate Transparency, all certificates are submitted to publicly-auditable logs by either the certificate authority or a third-party observer such as the Googlebot. Domain owners can monitor these logs using a service like Cert Spotter and take action if they see an unauthorized certificate for one of their domains.

Web browsers will eventually reject certificates that aren't logged using Certificate Transparency. However, Google is proceeding slowly towards mandatory logging so that they and others can gain operational experience first. The first milestone towards mandatory logging came in January 2015 when Chrome started requiring Certificate Transparency for Extended Validation certificates.

The second milestone came last October, when Google caught Symantec, a large certificate authority, issuing unauthorized "test" certificates for google.com and 75 other domains. Since issuing certificates for a domain without its owner's approval is such a serious violation of trust, Google announced that Chrome would require Certificate Transparency for all certificates issued by Symantec on or after June 1, 2016. This change rolled out last week in Chrome 53.

Symantec and Certificate Transparency

Symantec is, for the most part, complying with Google's logging requirement, and by default any certificate they issue will be properly logged and will work in Chrome 53. However, Certificate Transparency has a downside: it requires the complete contents of every certificate, including the hostnames, to be logged to a public log. For a public website, this is no big deal, but some organizations prefer to keep the hostnames of their internal servers private. Even the hostnames of public websites might need to be kept private until a certain date to avoid leaking information such as new product announcements or corporate acquisitions.

To address the privacy concerns, the IETF working group responsible for Certificate Transparency developed a redaction mechanism which would allow certificate authorities to redact components of the hostname beneath the registered domain. For example, a certificate for secretserver.secretdivision.example.com could be logged as ?.secretdivision.example.com, ?.?.example.com, but not ?.?.?.com. Redaction allows domain owners to keep their hostnames private, while still allowing them to detect that a certificate has been issued for some hostname under their domain.

Unfortunately for Symantec, there were some obstacles in the way of offering redaction to their privacy-sensitive customers.

First, redaction is only defined for the next version of Certificate Transparency, which is still a draft and has not been implemented by Chrome or any public log server.

Second, the Chrome team has raised several concerns with redaction, and stated that Chrome will not support redaction unless their concerns are addressed. Partly because of Chrome's concerns, the IETF working group removed redaction from the next version of Certificate Transparency and placed it in a separate document which has not yet been officially adopted by the working group.

Despite the fact that redaction, practically speaking, does not exist, Symantec forged ahead and grafted redaction onto the original version of Certificate Transparency. The result is a Franken-certificate that works fine in browsers that don't support Certificate Transparency, but fails to validate in Chrome.

Pointless Redaction

Symantec defaults to logging certificates in a compliant, unredacted form, but they provide their customers the option to log certificates in redacted form instead. Customers who choose this option get Franken-certificates that cause the above warning in Chrome 53.

Despite the incompatibility with Chrome and the utter pointlessness of redacting the certificates of public websites, both Chase Bank and United Airlines have chosen to redact such certificates. United fixed their websites before Chrome 53 became stable by replacing their certificates with fully-logged ones, but as of publication time, choosemyreward.chase.com is still serving a Franken-certificate that's rejected by Chrome 53.

Data collected from Certificate Transparency logs reveal quite a few other websites that are probably public yet use redaction, including websites at Amazon, Fedex, Goldman Sachs, Mitsubishi, and Siemens.

Why would someone choose redacted logging for a public website? Symantec's documentation might be to blame. Their documentation describes the two options as follows:

• Full domain names: Publicly logs root domain names and subdomains in the certificate. Recommended for all public websites.
• Only root domain names: Publicly logs only root domain names in the certificate. Intended only for private internal domains.

Although they say that logging root domain names is "intended only for private internal domains" while recommending full domain name logging for public websites, they don't mention the downside until later in the document:

All certificates with root domain logging may display browser warnings when users connect to the website.

Saying that a warning "may" be displayed doesn't seem adequate when a warning absolutely will be displayed, by the world's most popular web browser to boot!

Symantec needs to do a better job informing their customers of the downsides of choosing redaction. Too many websites have chosen redaction incorrectly, and I expect this to continue unless Symantec improves their messaging. Meanwhile, Chrome users will encounter avoidable browser errors when visiting these websites, which is a horrible experience for Symantec's customer's customers, and risks desensitizing people to security warnings.

Finally, if you represent an organization that wants to use redaction appropriately (that is, to hide the hostnames of a non-public server), please send an email to the IETF working group mailing list. The working group has had a difficult time designing redaction, and addressing Chrome's concerns will require hearing from the people who want to use redaction. The fate of redaction depends on your input!

If you're worried about certificate authorities like Symantec issuing unauthorized "test" certificates for your domains, you should check out Cert Spotter, a tool to monitor Certificate Transparency logs for unauthorized certificates. Available as open source or a hosted service.