If they operate as any other CA does, there's no reason to assume that they would have had any way to have the private keys which would only ever be on customer systems.
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 apparently have a “certificate wizard” that will generate the certificate and corresponding private key for you. Of course that’s practical for the end user (generating a CSR can be cumbersome), but obviously insecure.
> They apparently have a [webgui] “certificate wizard” that will generate the certificate and corresponding private key for you.
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.
That's bit harsh. I bet that significant amount of the impacted people had only the vaguest idea what they were actually buying ("a lock icon for the web thingy"), and never even heard of private keys, never mind CSRs or actually understanding public-key crypto and PKI.
I find this argument unconvincing, but even if you really feel the need to help people generate keys, you do it in JS in the browser, without ever sending them to your server! Open source code to do this has been around since 2001: http://webcache.googleusercontent.com/search?q=cache:87MSSBj...
> If you didn't create the private key yourself, by definition it's not private.
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.
> 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.
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.
They are still effectively subject to the CA/B rules. The issuer of the certs is subject to the rules, and they must ensure compliance of any companies they delegate to.
Given that they have access to private keys they shouldn't, should Comodo (their new CA partner) then think about stopping them from reselling? Obviously, they've already terminated their relationship with Symantec...
This is not wrong, but in the context of them generating and storing private keys for their users it means there's nothing in the Baseline Requirements preventing them from doing so if the subscriber (user) agrees to it.
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.
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.