Had to read it like 3 times before I could process. Unreal.
How is this not related to "the big distrust"? Unreal.
This implies that Trustico was sent the keys (or recieved them somehow) from a third party who had compromised them.
20k certs implies a tremendous number of clients; seems tome it's more likely one of Trustico's intermediate CA certs got compromised and these 20k are newly issues ones against that compromised CA cert.
They’re not the only party to do so either, e.g. DNSimple (which is otherwise a great company!) also provide APIs to have them generate and store certificates including private keys: https://developer.dnsimple.com/v2/certificates/#getCertifica...
Any company doing that deserves to have their decision makers crucified, head down, on the outer wall of the town church, with the nails hammered through their genitals.
If you didn't create the private key yourself, by definition it's not private. If generating CRSs and handling the certificates is too difficult, then feed improvements upstream. And yes, I know how horrible openssl's UI is for dealing with anything other than CN based certs. It's awful enough for those, an absolutely atrocious for pretty much anything else.
For the record, CN has been deprecated in certificates since ~2000 (RFC 2818), and practically obsoleted since 2011 (RFC 6125). Regardless of all this, I have dealt (in 2017) with parties who don't understand SAN over CN, and have even had their software stacks blow up when I provide a cert with SANs only, and no CN.
In fairness, though, your certificate vendor already has the power to issue a brand new certificate for your domain if they wanted to quietly snoop on traffic.
Same thing with AWS generating SSH keys if you want them to - they can get at all the data on your server anyways. No, it's not the greatest practice, but it probably does help a bit for making things easier for less-technical users.
If a hypothetical Bad Guy has got a different Certificate for my site they cannot "quietly snoop on traffic". They have to do an active Man-in-the-middle attack on each connection or else it's completely opaque to them. Each of the clients they do this to receives a free Smoking Gun, a copy of their illegitimate certificate showing who signed it and when. In a future where CT policy enforcement is completed (not yet but maybe soon) they must also have logged the certificate so that everybody can see it, or it won't work.
If the hypothetical Bad Guy has my Private Key, they can quietly snoop traffic using ciphersuites which lack "Forward Secrecy" although no popular browser will choose this unless forced to, and in TLS 1.3 Forward Secrecy is mandatory.
If the Bad Guy has my Private Key and is willing to do a Man-in-the-middle attack the same applies as above, except that I don't learn anything from Certificate Transparency since they can use my cert as they know the key for it.
You're the security hero we need, but not the one we deserve
> We have purchased thousands of certificates using Trustico as a reseller within the last years. Back in these days Trustico created CSR / Private Key pair within their online platform (Yes, you read it right - you can create CSR/Private Key on their webpage !!!) which was the default at this time and it is still possible to do so in their web interface.
For example, consider this page: https://www.trustico.com.au/ssltools/create/csr-pem/create-a...
The best part - it doesn't even use browser crypto. The private key is generated server-side and then rendered in the server response.
Private key generation on the reseller-side - what can go wrong.
However, even if we assume Trustico was an authorized party, the keys became compromised the moment they were disclosed to DigiCert unless the terms their users agreed to included DigiCert as an authorized party. Even if they were you could make an argument that those keys were compromised due to the fact that they were literally sent via email, unless they were properly encrypted and what not.
If you mean the Symantec distrust - it's financially related but not technically related.
In particular, it looks like Trustico ended their business agreement with Symantec (over the Symantec distrust) and signed a new contract with Comodo to resell Comodo certs instead. They wanted to move all their customers to the Comodo certs, and asked Digicert, the new owners of the old Symantec root, to issue revocations.
When Digicert said no, that's not how it works, they responded by sending over all of the private keys they had. The fact that they had those keys, and the fact that they sent them via email to Digicert, is entirely separate from any technical problem that Symantec or Digicert may have had.
I remember part of the Symantec problem was the uncontrolled resellers practices. Isn't this just some more dust under the rag coming out now?
They also state in the MDSP thread, "We were also a victim whereby Symantec mis-issued SSL Certificates owned by us, subsequently we were asked to keep the matter quiet, under a confidentially notice."
Symantec trusted the RAs to do Validation. So although we believe CrossCert (the Korean RA which made all this kick off) were actually making some sort of attempt to validate, since Symantec exercised no effective oversight and relied entirely upon third party auditors (whose role is _audit_ not actively overseeing everything) we can't be sure. We know CrossCert validated bogus certificates for example.com, which although it's scarcely google.com or a major bank is still very wrong. Executives at Symantec essentially did not do their job on this, that's why even if they hadn't quit the market voluntarily they were in the process of being forced to let somebody else do the actual oversight. Board-level incompetence is very widespread, but that's no reason we have to tolerate it in the Web PKI.
Trustico was not trusted to validate things, so if they tried to sell some customer certificates for example.com, the customer would have to prove to Symantec that they legitimately controlled example.com to get their certificate. They could still cause (as seen here) mayhem, but only for their own customers, so arguably caveat emptor.
Why would Trustico want to revoke certificates under the previous root anyway? Why not just start issuing certificates under the new, and just skip the part about broadcasting their little secret to the world?
This MIGHT have been a misguided attempt by Trustico to sow mistrust between Digicert and Trustico's own customers. If Trustico can convince people that Digicert (who purchased Symantec) wasn't to be trusted and this mass revocation was their fault, then Trustico might get more renews.
It also discontinues any relationship Digicert and Trustico's customers have with one another, since they'd all get nice shiny Comodo certs.
You can see Trustico's statement here:
https://www.trustico.com/news/2018/symantec-revocation/certi...
Only problem with Trustico's plan is that they shouldn't have even had over 20K's worth of private keys in cold storage. And while it was to their advantage in that they forced Digicert's hand, it also may have irreparably damaged Trustico's reputation.