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 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 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.
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.
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 had 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.
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 deniers”, if you prefer) to convert their websites to HTTPS.
9 comments on “20,000 web certificate private keys outed in “business tiff””
“This site reallys is mine.” – could do with correcting
I can’t get past “business tiff” — perhaps it’s just my experience with file format in the 90s, but I read it and think that the information was acquired via a flatbed scanner on an original apple Macintosh.
I received an email that a certificate was being revoked within 24 hours, so after much scrambling around we got a replacement direct from digicert. However the certificate still hasnt been revoked. This is more confusing than ever
I would think Trustico should have it’s ability to issue certificates revoked for breaking the agreement by keeping copies of 20,000 private certs.
Reminds me of the “Honest Achmed’s root certificate” request in Mozilla’s bug DB. (Bug 647959) Just goes to show that all certificate authorities are snake oil vendors to a greater or lesser extent.
I think a corporate name change is in order. From Trustico to Untrustico, or perhaps Distrustico.
I believe the reason Trustico had so many private keys came about through a feature on their web site, whereby instead of the customer supplying a CSR you could ask Trustico to generate a CSR and private key on your behalf. I confess to having done this one day, and as a result the three certificates which were purchased using that mechanism were revoked last week. Luckily two of them had already been replaced by wildcard certificates from another vendor and the third was for a server with only one user who relied on the certificate. That certificate was replaced using Digicert’s own offer of a free replacement which worked flawlessly.
I have another certificate from Trustico for which I supplied the CSR when purchasing (and hence only I have the private key). This certificate has not been automatically revoked but Trustico offered a free replacement. However their online ordering system has no provision for free replacements and repeated attempts to get this clarified have been met with silence. Instead they keep sending me automated emails to remind me their is a partially-completed order in their system.
Trustico have not so much shot themselves in the foot with this fiasco, it’s more like they’ve blown the entire leg off. I won’t purchase from them again.
I think that Trustico acted extremely unprofessionally, and broke the trust of the people who owned those 20,000 leaked certificates. I understand those certificates were replaced with new ones but what about the lost time in retrieving them? What about the distrust in their company they have caused? I certainly hope that they fired whoever made that decision.