SSLMate Blog

Chronicling the revolution of SSL certificate management.

April 26, 2018

Yes, it's OK if GitHub Requests Certificates for Sub-Domains Delegated to Them

And you can now exclude delegated sub-domains from Cert Spotter monitoring.

Last week, Mickaël Bergem published a blog post about his surprise when GitHub obtained an HTTPS certificate for his blog sub-domain, which was hosted on GitHub Pages. Bergem had not explicitly requested the certificate, and described its issuance as unpleasant.

There is no question that the certificate was legitimately issued under the rules governing publicly-trusted certificate issuance. As Bergem showed in his blog post, he had delegated the DNS for blog.securem.eu to mickaelbergem.github.io using a CNAME record. This gave GitHub technical control over blog.securem.eu, enabling them to request a certificate for the hostname using an "Agreed-Upon Change to Website" (section 3.2.2.4.6 of the Baseline Requirements).

But just because GitHub was allowed to do this, should they have? Was it OK for them to go and request a certificate for mickaelbergem.github.io without Bergem's explicit permission?

We think yes, it was completely OK. Furthermore, this practice should be encouraged and normalized.

The Web is moving to HTTPS, and in just a few months, Google Chrome is going to start labeling websites without HTTPS as "Not secure" in the address bar. If someone outsources the hosting of their website to a service such as GitHub Pages, that service has a responsibility to provide the site with HTTPS, and to do so, they must obtain a certificate. This process needs to be automatic. If it requires manual interaction with the user, such as requesting permission, it adds friction to the process of setting up a website and makes HTTPS unnecessarily more difficult compared to unencrypted HTTP. Even notifying the user that the service is about to request a certificate takes away their valuable attention that could be better spent elsewhere. And not all domain owners even know what a certificate is, nor should they need to. People outsource website operation so they don't have to concern themselves with details like the HTTP protocol, system administration, or TLS certificates.

What if you are a domain owner who operates sites yourself, but have delegated some sub-domains to third parties such as GitHub? Since you operate sites, you know what a certificate is and you're monitoring your domain for unauthorized certificates using Certificate Transparency. How should you handle your delegated sub-domains?

We think you shouldn't monitor these sub-domains. Since you're not the operator of the sub-domain, you have no way of knowing whether a certificate issued for it is legitimate. Alerts about certificates for the sub-domain would be unactionable noise. Instead, the third party operator (GitHub in this case) should monitor the sub-domain, since only they know which certificates they've requested. (Unfortunately, they won't know if you requested a certificate for the sub-domain, but this is an atypical case and could be handled by them sending you an email.)

To help domain owners with delegated sub-domains, we've rolled out a new Cert Spotter feature: you can now specify a list of sub-domains which are excluded from monitoring. We recommend you list any sub-domain which you've delegated to a third party operator. To add an excluded sub-domain, just visit your Cert Spotter Account Page and enter a sub-domain under the "Excluded Sub-Domain List" section. You will no longer receive alerts for certificates issued for this sub-domain.

If you're a company which operates websites on behalf of your customers, and you want to make HTTPS easy for you and them, check out SSLMate for SaaS.

April 11, 2018

Introducing SSLMate for SaaS - Get Certificates For Your Customers' Vanity Domains

The Web is moving to HTTPS. 70% of all page loads in Firefox now use HTTPS, up from 55% a year ago. Web browsers are increasing the pressure on websites to adopt HTTPS, and in July, Chrome will display "not secure" in the address bar for non-HTTPS sites.

If you're a SaaS or marketing company that hosts websites on your customers' vanity domains (or sub-domains), now is the time to start provisioning HTTPS for your customers' domains. This can be a hard problem: you need to get an SSL certificate for every domain you host, ideally in a way that doesn't burden your customers with extra work. This is an even harder problem at scale, when you have thousands of certificates and multiple frontends that need to be in sync.

You've always been able to use SSLMate or integrate with a certificate authority's API to automate issuance of certificates for your app. However, this still requires significant engineering effort. You need to generate a private key and synchronize it securely with your web frontends. You need to demonstrate control of each domain, which either burdens your customer with approval emails and extra DNS records, or requires you to track and respond with challenge codes over HTTP. When the certificate is issued, you need to correctly install it on your web frontends. You need to track when a certificate is about to expire and repeat all of the above.

You also need to plan for when something goes wrong: a renewal fails due to a misconfiguration, a security incident such as Heartbleed requires rapid replacement of keys and certificates, or someone tries to connect to your server from a device with an incorrect clock.

We know you don't want to spend time on this. We're happy to say you don't have to anymore. Today, SSLMate is proud to announce SSLMate for SaaS, a new service tailored specifically for SaaS and marketing companies who need certificates for their customers' vanity domains. We take care of the hard work of getting certificates, freeing up your engineering time to work on your own business.

Using SSLMate for SaaS is a breeze. First, you configure your web servers to proxy two special URLs used for certificate validation to SSLMate servers. This lets us approve certificates on your behalf, freeing you from having to track and respond with challenge codes, or from making your customer do extra work like responding to an email or publishing a special DNS record. Second, you install a lightweight, stateless agent on your web frontends. The SSLMate Agent installs private keys and certificate files for your existing load balancer or web server stack to consume (we know it works great with nginx, Apache, and haproxy; no need for you to replace the software you're familiar with). You can install the SSLMate Agent on any number of servers and it will automatically synchronize keys and certificates between them, letting you scale horizontally without worry.

Getting a certificate for a customer's domain is as easy as making a single API call to the SSLMate API containing the name of your customer's domain. You don't need to generate and submit a CSR, track and respond to challenges, or make additional API calls to renew the certificate. The API call can be integrated into your existing onboarding process for vanity domains. As soon as your customer's domain is pointed at your web servers, we'll request and approve the certificate, and within a couple minutes, the SSLMate Agent will install the key and certificate files across your entire frontend server fleet.

Of course, we monitor the entire process and alert you if something goes wrong that might cause a renewal to fail, letting you proactively fix the problem before it affects your uptime.

SSLMate for SaaS starts at $100/month for 100 certificates. Pricing is SaaS-friendly: if you delete a certificate, you can immediately reuse the credit for another - you don't have to commit to an entire year for one customer's certificate.

Sign up for a 30 day free trial of SSLMate for SaaS, or learn more about SSLMate for SaaS. If you're an existing SSLMate customer who would like to convert your account to SSLMate for SaaS, please get in touch. Let's get the Web to 100% HTTPS!

December 7, 2017

How Cert Spotter Parses 255 Million Certificates

When Cert Spotter scans Certificate Transparency logs to find SSL certificates for your domain, it has one job: do not miss certificates. In a perfect world, this would be easy. Cert Spotter is written in Go, and Go's standard library has a delightfully easy-to-use certificate parser that extracts all the pertinent information about a certificate: domain names, public key, expiration date, and so on.

Unfortunately, the real world is not so easy. Although there are standards that say how a certificate should be encoded, the standards are complex and hard-to-follow, and even when they are crystal clear, certificate authorities still find a way to violate them. Consequentially, Certificate Transparency logs are rife with nonconformant certificates. Since Go's certificate parser is strict with standards conformance, it cannot parse many of these certificates. If Cert Spotter used Go's certificate parser, it would miss certificates. Ideally, these certificates would be harmless because TLS clients would reject them also, but in practice many TLS clients have very permissive certificate parsers. Therefore, Cert Spotter needs to be at least as permissive as the most permissive TLS client imaginable.

After ruling out Go's standard parser, we tried using a fork of Go's parser from Google's Certificate Transparency library which treats several of the most common encoding errors as warnings. Unfortunately, this wasn't enough and some certificates still failed to parse. We considered special casing additional errors until every logged certificate would parse, but this seemed brittle and prone to failure under an adversarial model: an attacker who compromised a certificate authority could issue a certificate with an encoding error that Cert Spotter had not yet special-cased.

Instead, we wrote a custom, extra-lenient certificate parser using Go's excellent ASN.1 library. (ASN.1 is the syntax used to represent certificates.) Here are some of the techniques we use to make sure Cert Spotter is able to parse every single certificate ever logged to Certificate Transparency logs - all 255 million of them.

Lazy Parsing

A certificate contains many bits of information, but not all of them are equally important. The most important information for a monitor is the domain name, since the domain name tells us who should know about a certificate. Even if Cert Spotter can't understand the rest of the certificate, we want to at least alert the domain owner so they can take the appropriate action. Therefore, Cert Spotter uses lazy parsing, and parses different parts of the certificate separately and only as necessary, so that a problem in one part of the certificate doesn't affect the ability to parse the rest of the certificate.

Go's ASN.1 library makes lazy parsing easy thanks to its asn1.RawValue data type, which allows part of a data structure to remain unparsed. Cert Spotter uses asn1.RawValue when parsing the overall certificate structure, and then separately parses the individual RawValues. Below is the definition of the TBSCertificate struct used by Go's parser followed by the equivalent struct used by Cert Spotter. Both structs have the same fields, but where Go's parser uses actual types that must all be parsed successfully for the certificate to parse, Cert Spotter uses asn1.RawValues.

Go Parser Struct:
type tbsCertificate struct {
        Raw                asn1.RawContent
        Version            int `asn1:"optional,explicit,default:0,tag:0"`
        SerialNumber       *big.Int
        SignatureAlgorithm pkix.AlgorithmIdentifier
        Issuer             asn1.RawValue
        Validity           validity
        Subject            asn1.RawValue
        PublicKey          publicKeyInfo
        UniqueId           asn1.BitString   `asn1:"optional,tag:1"`
        SubjectUniqueId    asn1.BitString   `asn1:"optional,tag:2"`
        Extensions         []pkix.Extension `asn1:"optional,explicit,tag:3"`
}
Cert Spotter Struct:
type TBSCertificate struct {
	Raw                asn1.RawContent
	Version            int `asn1:"optional,explicit,default:1,tag:0"`
	SerialNumber       asn1.RawValue
	SignatureAlgorithm asn1.RawValue
	Issuer             asn1.RawValue
	Validity           asn1.RawValue
	Subject            asn1.RawValue
	PublicKey          asn1.RawValue
	UniqueId           asn1.BitString `asn1:"optional,tag:1"`
	SubjectUniqueId    asn1.BitString `asn1:"optional,tag:2"`
	Extensions         []Extension    `asn1:"optional,explicit,tag:3"`
}

Once the overall structure is parsed, Cert Spotter can parse individual RawValues by accessing their FullBytes member like so:

serialNumber := big.NewInt(0)
asn1.Unmarshal(tbs.SerialNumber.FullBytes, &serialNumber)

Cert Spotter also uses lazy parsing when parsing the certificate subject. The subject is a sequence of attributes such as organization name, country code, and common name. Cert Spotter only cares about the common name, since it might contain a domain name (this is deprecated, but some TLS clients still support it so Cert Spotter needs to understand it). Cert Spotter uses asn1.RawValue for the attribute values and only bothers to parse the RawValue if the attribute type is common name.

Lax String Decoding

ASN.1 defines a multitude of string types, any of which might be used to encode a certificate's common name. Two string types in particular, PrintableString and IA5String, cause problems. PrintableString is a subset of ASCII that forbids some characters, such as the asterisk. CAs routinely include these characters, particularly for wildcard certificates. IA5String is ASCII, but CAs routinely include Latin-1 characters. Therefore, Cert Spotter treats both PrintableString and IA5String as Latin-1 and doesn't care if the string contains forbidden characters.

IP Addresses in DNS Names

Although there are separate Subject Alternative Name (SAN) types for DNS names and IP addresses, Windows used to lack support for IP address SANs and would instead interpret a string-encoded IP address in a DNS SAN as an IP address. Therefore, Cert Spotter checks if a DNS SAN could be interpreted as an IP address, and treats it as one if so.

NUL Bytes in DNS Names

In 2009, Moxie Marlinspike was able to get a certificate for the DNS name www.paypal.com<NUL>.secureconnection.cc. Since Marlinspike owned the domain secureconnection.cc, he was able to authorize the certificate's issuance. However, due to the NUL byte in the middle of the DNS name, some TLS clients thought the certificate was for www.paypal.com instead, allowing Marlinspike to impersonate PayPal to those clients.

When Cert Spotter sees a DNS name containing a NUL byte, it treats the certificate as being valid for not only the complete DNS name, but also the DNS name before the NUL byte. For www.paypal.com<NUL>.secureconnection.cc, Cert Spotter would alert the owners of both paypal.com and secureconnection.cc.

URLs in DNS Names

Incredibly, certificate authorities have put entire URLs in a certificate's DNS name. Although such DNS names don't work in TLS clients, the owner of the domain in the URL should still know about the certificate, as it may be evidence of a larger attack against the domain. Therefore, Cert Spotter parses URLs, extracts the domain name from them, and notifies the domain owner.

Duplicate Extensions

Certificate authorities have sometimes issued certificates containing more than one extension of the same type. If a certificate includes more than one subject alternative name extension, Cert Spotter extracts domain names from all of them. A naive parser might only use the first or last SAN extension, which would miss critical information.

Ongoing Monitoring

Although Cert Spotter is able to parse all 255 million logged certificates, and has tried to anticipate all types of encoding errors, a new certificate may appear that Cert Spotter cannot parse. SSLMate continuously monitors for unparseable certificates, and should one be discovered (which hasn't happened yet), we'll fix Cert Spotter so it can parse the certificate, and then reprocess the certificate so the domain owners are notified.

Conclusion

When picking a Certificate Transparency monitor to track your domain's SSL certificates, it's important to pick a monitor that won't miss certificates, even those that are very badly encoded. A monitor that uses a standard certificate parser will miss malformed certificates, even though these certificates pose a risk to your infrastructure. Cert Spotter's custom, extra permissive certificate parser is carefully written to catch every certificate, so you'll be notified when you need to be.

Cert Spotter finds SSL certificates issued for your domains, so you won't be caught off-guard by an expiring or unauthorized certificate.

September 7, 2016

Why Chrome 53 is Rejecting Chase Bank's Symantec Certificate

Update (Thursday, November 10, 2016): Due to a bug in Chrome, versions of Chrome 53 that are more than 10 weeks old now display this error message for all websites using Symantec certificates that were issued on or after June 1, 2016 (including from Symantec-owned brands like Thawte and GeoTrust). As of Friday, November 11, 2016, Chrome users can simply restart Chrome to avoid the bug. Chromium users must upgrade. Website operators can switch to a certificate from a different certificate authority. (SSLMate issues Comodo certificates, which are not affected.) The rest of this post still applies to new versions of Chrome.

Update (Saturday, November 26, 2016): Out-of-date versions of Android 5 and higher are affected by this bug when viewing websites from within apps. The solution is to upgrade Android System WebView from the Play Store.

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:

Chrome error page saying that the connection to choosemyreward.chase.com is not private

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.

September 2, 2016

What Will Happen to WoSign? A Look at Past Certificate Authority Sanctions

Certificate authority (in)security is in the news again, with the recent revelation of several security vulnerabilities and other serious oversights at the WoSign certificate authority. The Mozilla community is currently debating what sanctions should be taken against WoSign. While we wait for Mozilla and other browser vendors to make their decisions, I thought it would be interesting to explore what sanctions other certificate authorities have faced in the past.

Note that this post will focus on sanctions imposed by Mozilla and Google, since they discuss certificate authorities more openly than other browser vendors.

2011: Comodo avoids consequences for reseller compromise

Although security researchers had discovered flaws in certificate authorities prior to 2011, the first serious compromise occurred in 2011 when a Comodo reseller was breached and used to issue unauthorized, publicly-trusted certificates for high profile domains such as google.com, mozilla.org, and skype.com. Although Comodo themselves were not breached, at the time Comodo trusted their resellers to perform domain control validation, meaning a compromised reseller could cause the issuance of publicly-trusted certificates for arbitrary domains.

Since Comodo weren't breached, they were able to detect and contain the compromise quickly, which likely helped them avoid sanctions. They remain widely trusted to this day, but no longer allow resellers to perform domain control validation.

2011: Death penalty for DigiNotar

Not long after the Comodo reseller compromise, a much more serious compromise occurred that remains the most serious certificate authority incident to date, and which resulted in the most severe sanctions possible. DigiNotar, a Dutch certificate authority, was totally compromised. Over 500 unauthorized certificates were detected and a rogue wildcard certificate for google.com used for mass interception of Internet traffic in Iran. Since DigiNotar was so thoroughly compromised, the full extent of the breach was never known.

Due to the seriousness of the breach, all major browsers (Mozilla, Google, Microsoft, Apple) revoked trust in DigiNotar. A few months later, DigiNotar declared bankruptcy and shut down.

2012: Amnesty for MITM certificates

In 2012, Trustwave disclosed that they had willfully issued an intermediate CA certificate to a company for the express purpose of signing unauthorized, publicly-trusted certificates to intercept and inspect encrypted traffic.

Although the certificates issued by this intermediate CA were clearly not authorized by domain owners, there was some concern that this practice was neither clearly prohibited nor uncommon, and that it would be unfair to punish the first CA to admit to it. After a public discussion, Mozilla opted for an amnesty policy instead of sanctioning Trustwave. Certificate authorities were explicitly informed that this practice was forbidden and given two months to comply or face sanctions.

2013: No green bar for TURKTRUST

In 2013, Google learned that TURKTRUST had "mistakenly" issued two intermediate CA certificates to subscribers instead of regular certificates, and that one of them had been used to sign a rogue certificate for google.com. TURKTRUST provided a plausible explanation for their mistake and there was no indication that they had been compromised. Google decided to revoke TURKTRUST's ability to issue extended validation certificates, and Mozilla temporarily suspended the inclusion of a new TURKTRUST root certificate. No further action was taken, making this a fairly mild sanction.

2013 - 2014: Regional death penalty for ANSSI and India CCA

In 2013, ANSSI, a French certificate authority, was caught doing what was expressly prohibited after the Trustwave revelation: they issued an intermediate CA that was used to intercept and inspect encrypted traffic. Google and Mozilla responded by "name constraining" ANSSI so that it could only issue certificates for domain names ending in .fr or one of the other top-level domains used by French territories. Although this sanction fell short of a full death penalty, it killed off ANSSI for most of the world.

In 2014, an intermediate certificate authority signed by India CCA was compromised and used to issue rogue certificates for Google and Yahoo. After investigating the compromise, India CCA found only four rogue certificates. However, Google was aware of additional rogue certificates that India CCA did not detect and concluded that India CCA was unaware of the full scope of the breach. Consequentially, they decided to name constrain India CCA to a small set of Indian domains.

2015: Suspension of CNNIC

In 2015, Google learned that CNNIC, like ANSSI and Trustwave, had issued an intermediate certificate authority that was used to intercept encrypted traffic. CNNIC did this in violation of their own Certificate Practice Statement, which said that they would not issue intermediate certificate authorities to external organizations. In response, both Google and Mozilla revoked trust in new CNNIC certificates.

Since existing certificates remained trusted, this was a less severe sanction than DigiNotar faced. To implement this sanction, Chrome and Firefox embedded a whitelist containing the hash of every existing CNNIC certificate. Since there were only a couple thousand CNNIC certificates, this was practical.

Google welcomed CNNIC to reapply for inclusion, but stipulated that all CNNIC certificates would have to be logged to Certificate Transparency logs. Unlike DigiNotar, CNNIC remains operational.

2015: Certificate Transparency required for Symantec

In 2015, Google discovered that Symantec had issued over 100 publicly-trusted "test" certificates for 76 different domains, including google.com, without the authorization of domain owners. In response, Google announced that all Symantec certificates issued on or after June 1, 2016 would have to be logged to Certificate Transparency logs. Chrome 53, released this week, enforces this requirement and rejects any unlogged Symantec certificate with an issuance (a.k.a. notBefore) date on or after June 1, 2016.

2016: What will WoSign face?

As we can see from the above, every certificate authority incident was different and therefore merited a different response. Would any of the above sanctions work with WoSign?

  • Death penalty, like DigiNotar: Although WoSign has not been compromised like DigiNotar was, they have displayed a shocking amount of sloppiness for an organization entrusted to sign certificates for any domain on the Internet, which arguably warrants distrust. However, there are over 100,000 unexpired WoSign certificates in existence. Distrusting WoSign would cause any site using one of these certificates to break, which risks desensitizing people to security warnings. Does the security benefit from distrusting WoSign outweigh this risk?

  • Revoking extended validation status, like TURKTRUST: Is this a strong enough sanction for WoSign's failures?

  • Name constraining, like ANNSI: Since WoSign has issued certificates worldwide, there is no set of name constraints that could be meaningfully applied to WoSign.

  • Suspension, like CNNIC: Could new WoSign certificates be distrusted, but existing certificates grandfathered? Unfortunately, since there are over 100,000 unexpired WoSign certificates, it would be impractical to include a whitelist in browsers as was done with CNNIC. And since WoSign has been caught backdating certificates, it would be imprudent to rely on the notBefore date to decide if an existing certificate should be grandfathered.

  • Require Certificate Transparency, like Symantec: WoSign has already promised to log all certificates issued after July 5, 2016 to Certificate Transparency logs and has asked browsers to block certificates issued after this date that are not logged. But how can a browser really know if a certificate was issued after July 5, 2016 or not? WoSign can't be trusted to set the notBefore date faithfully, and there are too many existing certificates to embed a whitelist in the browser.

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

All posts

Get Started with SSLMate Today

Buy a new certificate, or import your existing certs for free.

Click to sign up