20,000 web certificate private keys outed in “business tiff” ~ TFN

Over the years, we’ve written about website security certificates many times.
That’s because HTTPS certificates (more properly, TLS certificates, formerly known as SSL certificates) are one of the cornerstones of online transaction security.

Web certificates put that padlock icon into your browser’s address bar – the padlock we’re always urging you to look out for if you’re a website visitor, and to provide if you’re a website operator.
To recap, TLS is short for Transport Layer Security. (TLS used to be known as SSL, or Secure Sockets Layer – you’ll still see the abbreviation SSL a lot.)

The TLS “chain of trust” provided by digital certificates, simplified very greatly, goes something like this:

I use a certificate to vouch for the fact that a website really is mine to own and operate.
I get a company called a Certificate Authority (CA) to vouch for my certificate by signing it with their certificate.
Your operating system or browser maker to vouches for the CA by adding its certificate to a “master trust” list

This forms a chain of trust – your browser tells you that the CA is likely to tell the truth, the CA tells you that the website operator is likely to tell the truth, and the website operator tells you, “This site really is mine.”

Note. A TLS certificate doesn’t tell you that the web server you’re connecting to is secure, patched, safe, truthful, and so on – it vouches for the owner and operator of the site, thus making it much harder for a crook to set up an imposter server that is indistinguishable from yours.

As you can see, there’s a lot that can go wrong here:

A trusted CA could go rogue, or get acquired by a sloppier company, or sign certificates without doing proper checks.
Crooks could steal a vendor’s certificate and start stamping that vendor’s official seal on their own malicious websites.
Crooks could steal your certificate and set up an imposter site that looks completely genuine.

And so on.
As a result, the TLS certificate ecosystem needs to be able not only to introduce new certificates and CAs into the mix, but also to be able to disavow (to revoke, in technical jargon) individual certificates as well as entire CAs.

In an ideal world, revoking an entire CA would be a once-in-a-lifetime sort of affair: firstly, it’s pretty much game over for the CA’s business; secondly, invalidating a CA automatically also invalidates any certificates already signed by it.

If your CA gets struck off abruptly, you need to get a new certificate, signed by a new CA, as soon as possible, or everyone who visits your website is going to see an ominous browser warning advising them that your website can’t be trusted.

Losing trust

CAs that have lost the trust of the community over the years include Dutch company Diginotar, the Turkish CA TURKTRUST, the Chinese Wosign…
…and most recently, computer security behemoth Symantec.

Google has been up in Symantec’s face for close to a year now, arguing strongly that the community should “reduce, and ultimately remove, trust in Symantec’s infrastructure in order to uphold users’ security and privacy when browsing the web.”

Google’s claim was that Symantec’s infrastructure for issuing certificates – which covered a range of different brands the company had acquired over the years – just wasn’t up to scratch, so Symantec ought to get its house in order and reissue all its certificates, allowing all the old and unreliable ones to be revoked for the greater good of all.

In the end, this stand-off was resolved without too many tears: Symantec sold off its certificate business to rivals Digicert, who agreed a timetable during which it would issue its customers with replacement certificates before existing Symantec certificates were automatically distrusted by the world’s browsers.

Regaining trust

In the UK, however, this transition hasn’t gone entirely smoothly – with new owners Digicert getting into a spat with one of its London resellers, a boutique security business called Trustico.

According to the Register, Trustico decided it wanted to switch its customers with Symantec certificates away from new owners Digicert to rival CA Comodo – after all, you’d need a new certificate anyway (some old Symantec certificates automatically become untrusted on 2018-03-15; the rest will expire on 2018-09-13).

At the same time, Digicert had emailed Trustico customers whose certificates needed replacing (these users were, after all, now Digicert customers, too) to advise them about the certificate swapout process.
Trustico then demanded that Digicert revoke the affected certificates outright,

Digicert refused, apparently on the understandable grounds that unilaterally revoking individual certificates – in the absence of any overarching security concern – is a matter for the owners of the certificates, not for the resellers or the CAs that issued them.

Things get weird

Here’s where things get weird.
According to Digicert, Trustico emailed over the private keys for more than 20,000 certificates.
Of course, the private key is what makes the certificate yours and stops other people from abusing it, so you should really be the only person with a copy of your private key.

Anyway, the guidelines of the TLS certificate ecosystem say that if a certificate’s private key is known to have been exposed, then for everyone’s peace of mind, that certificate should be revoked within 24 hours.

According to Digicert, that’s exactly what then happened, given that the keys have been emailed across the internet, so Trustico abruptly got what it wanted anyway, as a convenient procedural side-effect.

What we can’t quite understand is how Trustico came to have copies of so many customers’ private keys in the first place, and why those keys were sent via email as some sort of a pawn in the “Symantec Sells Its Certificate Business” endgame.

As Trustico itself admitted, on the day the news broke of the mass key disclosure:

Unfortunately things didn’t go very well for us today and we are extremely sorry for all the confusion and inconvenience that has been caused. We believed that we had acted in accordance with the agreements and information that both DigiCert and Symantec had imposed and provided upon us.

What next?

This sort of public brouhaha doesn’t reflect very well on the digital certificate world.
We’re all expected to operate our websites over HTTPS these days – indeed, there are many excellent reasons for getting rid of HTTP entirely, forever, in return for additional community security and privacy.

But a public spat like this, where customers’ private keys seem to have turned into business bargaining chips, doesn’t do anyone any favours.

Now it’ll be harder than ever to convince HTTP holdouts (or “HTTPS refuseniks”, if you prefer) to convert their websites to HTTPS.

by: Paul Ducklin