> How is this not related to "the big distrust"? Unreal.
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.
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?
Both Digicert and Trustico were trying to compete for the former Symantec customers. Both sent customers a replacement key for their soon-to-be broken Symantec keys (with Digicert's needing to be renewed directly with them, and Trustico (via Comodo) with them).
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.
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.
Probably. In some amount of fairness, Trustico's stated motivation was that they didn't feel like they trusted Symantec (reasonable!) and the same people were involved with the move to Digicert (which I think is correct, some employees moved but technical oversight should have moved to the more organizationally-competent Digicert team) and the same problems were likely to happen again (I think Digicert is generally good at being a competent CA, but it's not unreasonable for them to decide the risk is too high if some of the same people were around).
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."
The big Symantec problem was RAs rather than resellers. The difference probably doesn't mean much to customers, but it means a lot in terms of trust.
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.
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.
