
DigiCert Statement on Trustico Certificate Revocation - el_duderino
https://www.digicert.com/blog/digicert-statement-trustico-certificate-revocation/
======
praseodym
The situation is unfolding in this Mozilla security policy mailing list
thread:
[https://groups.google.com/forum/m/#!topic/mozilla.dev.securi...](https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/wxX4Yv0E3Mk)

~~~
jaas
I hope it's not overly pedantic to point out that what you linked to is not a
CAB forum thread. That's a thread on the Mozilla security policy list, which
many root programs and CAs make use of for disclosure and discussion.

CAB forum has its own lists elsewhere. A relevant difference is that CAB forum
discusses creating and modifying policy but is not involved in enforcement.
The root programs typically deal with enforcement.

~~~
tialaramex
To elaborate slightly::

The CA/B is a standing meeting between two groups with very different
objectives that have an ongoing need to reach some sort of agreement: the
Certificate Authorities and the Browsers (in reality more or less the
Operating System vendors except Mozilla represents the Free Unixes). This
meeting must not appear to be a cartel because cartels are illegal, so it
mustn't discuss prices or agree what products should or should not be
marketed.

m.d.s.policy is de facto the only public oversight for the entire Web PKI.
Mozilla as a Browser vendor (and as hinted above, on behalf of all the Free
Unixes) gets to insist upon Rules, not only enforcing rules agreed at CAB, but
also making its own rules on top for Certificate Authorities in its Trust
Store. As a Charity one of its rules is that it insists on doing almost
everything in Public using m.d.s.policy, there is no other obligation on a
Certificate Authority to engage with the public at all, but Mozilla's rules
force them to tell Mozilla important things via this public group and to
answer questions impertinent members of the public (like me) ask them on
m.d.s.policy.

Mozilla (and other Browser vendors) is entirely free to insist upon whatever
rules they want. The CA/B does not bind them, like the UN it is a forum to
meet, and to come to agreements, but it cannot force you to agree to anything
you don't want. Two recent illustrative examples:

The CA/B took ages to reform the Domain Validation methods, terribly weak
methods had been popular for years, with all sorts of stupid design flaws, and
after it did finally vote on a reformed list of methods, CA members claimed a
bunch of patents needed to be licensed stalling things for months extra.
Mozilla cut through the bullshit and said essentially "See that list of ten
methods you voted on that's stuck in Lawyer hell? Too bad, our policy now
requires you obey the list which we're naming the Ten Blessed Methods"

Google wanted to reduce the maximum lifetime of new certificates. It takes
ages to get CAs to introduce a new rule, and then years while the old
certificates made under the old rule expire, too long for Google. So they made
an ultimatum, fix it or we'll just tell Chrome to reject certificates after 90
days, and that's the new maximum certificate lifetime. The CA/B eventually
voted through a compromise 825 days (which goes into effect tomorrow, 1 March
2018) instead of the previous 39 month limit.

------
heywire
"Trustico’s CEO indicated that Trustico held the private keys for those
certificates, and then emailed us approximately 20,000 certificate private
keys."

Well, that's one way to ensure they're considered "comprimised".

------
pfg
Trustico now posted a statement on their site[1]. My favourite part is this:

> Trustico® followed the requests of DigiCert by initially recovering Private
> Keys from cold storage and subsequently e-mailing the associated order
> number and Private Keys to DigiCert in a ZIP file. The file did not contain
> any other type of data.

[1]: [https://www.trustico.com/news/2018/symantec-
revocation/certi...](https://www.trustico.com/news/2018/symantec-
revocation/certificate-replacement.php)

~~~
Lazare
What a bizarre defense. Do they think this makes them look...better?

The core issue is 1) they had the keys at all 2) they decided to compromise
them by emailing them DigiCert

Saying "hey, we did nothing wrong, all we did is email the keys we had to
DigiCert" just isn't a very compelling defense to claims they had the keys and
emailed them to DigiCert. More like a "total admission of guilt" than a
defense, really.

~~~
lathiat
The secondary part is that they requested mass revocation of active
certificates, including from brands such as RapidSSL which were not being
browser distrusted AFAIK (even though some others were.. if I need to be
corrected on this please let me know).

They did this without notifying their customers in advance, so literally, they
were going to intentionally screw their customers by revoking all their active
SSL certificates without their authorisation and without any notice. Which
then happened.

This would have affected ALL certificates, but since Digicert said no, they
then pulled all of these generated private keys from storage which they should
NOT have been storing -- on their reseller web interface when you generate a
certificate (which is a questionable activity but lets just go with it for the
argument).. a few days after you place the order the private key disappears
from the web interface. You would therefor assume they deleted it. It seems
they kept a copy of all of them this whole time - which is doubly
irresponsible let alone stupid.

All I can say is thankfully LetsEncrypt is making these guys mostly
irrelevant...

The good news is, as far as I know, they're only revoking the certificates
that used the generator at least (though I haven't confirmed that) -- so
hopefully most people that used a normal CSR certificate won't have them
revoked.

Bunch of morons, I can't see why they thought this was a good idea, and as the
commentator above said, this response doesn't sound better in any way. It just
proves they are intentionally screwing their customers for no real reason.
Even if they were intent on this distrust process, they should have at least
been ensuring customers got new certificates first and had plenty of notice --
e.g. how the chrome distrust worked. They didn't.

~~~
pfg
> The secondary part is that they requested mass revocation of active
> certificates, including from brands such as RapidSSL which were not being
> browser distrusted AFAIK (even though some others were.. if I need to be
> corrected on this please let me know).

To my knowledge all CAs under Symantec's control, including RapidSSL, are
affected[1], with only a handful of exceptions for cross-signed intermediates
where Symantec was not under control of issuance. IIRC they belong to Apple
and Google (and maybe a few others).

[1]: [https://security.googleblog.com/2017/09/chromes-plan-to-
dist...](https://security.googleblog.com/2017/09/chromes-plan-to-distrust-
symantec.html)

------
0x0
The DV CA space is such a mess. I still wish DV certificate issuance was the
responsibility of the domain registrar, with technical measures taken to
prevent competing registrars from misissuance. This way, you don't need to
play whack-a-mole around your certificates, just pick a reputable registrar
when you buy your domain, avoid the need to "prove" you hold the domain (your
registrar control panel is today already the sole security barrier protecting
your domain), and avoid the possibility that a third party can play the
impostor game. And it would bring some meaning back to the reputation of
different TLDs and their various registrars.

~~~
brightball
CAA records help with that now. You can just specify your certificate issuer
at the DNS level.

~~~
0x0
See, that requires trusting that all CAs actually respect the CAA records.
AFAIK, CAA records aren't validated by end-user client software during SSL
negotiation.

I would love to see some technical measure implemented where DV SSL
certificate issuance and validation was tied to the TLD registry and the
domain's particular registrar. It would eliminate the frankly unnecessary
trust we put in all root CAs and their sub-CAs to behave. (Well, at least CT
logs are becoming a thing now)

It would also eliminate today's more or less awkward validation routines that
depend on third parties querying DNS/HTTP/whois-email addresses. The registry
has the definite database, mapping the domain to your account at your
registrar, anyways. They should simply have a public key upload button next to
your domain name in your registrar's domain name control panel that
immediately returns an appropriate certificate, no further validation needed
:)

~~~
toast0
> See, that requires trusting that all CAs actually respect the CAA records.
> AFAIK, CAA records aren't validated by end-user client software during SSL
> negotiation.

I think the CAB rules require respecting CAA records? If a CA gets caught on
that, they'll have some amount of hell to pay.

Client software can't go back in time to verify what the CAA records were at
the time the certificate was issued. CAA records are not intended as a means
to revoke previously issued certificates, only an indication of which CAs are
_currently_ allowed to issue new certificates.

That said, I agree with you, but the general consensus doesn't seem to, that
we de facto trust registries/registrars as stewards of domain ownership, so we
may as well de jure make them CAs, since they already have an account
relationship.

~~~
0x0
I found your last paragraph especially well phrased!

You're also on point regarding the CAA records. But to me the current system
still feels too reactionary. I'd love to see a system where we need to put
less trust in all third parties playing by the rules pinkie-promise.
Diginotar, StartSSL and Symantec are all examples of CAs gone wild, and I
think we've just seen the tip of the iceberg yet.

~~~
zaarn
And all examples of CAs essentially no longer in business (or bought up by
DigiCert).

~~~
0x0
Yes, but after the damage was done and only because the damage happened to be
uncovered.

~~~
zaarn
Well, obviously yes.

The CA/B mailing list can't do much about shady behaviour they don't know
anything about.

I do trust in Mozilla to ensure that the game rules for CAs are strict enough
that my trust in the green lock isn't 0. It's not 100% either but it's above
50%. When I connect to a website and it has SSL, I'm fairly certain it's the
right place.

Most likely there will never be a replacement for it, any PKI requires some
third party to vouch for an endpoint otherwise you get easy MitM (I believe
there is a proof floating around somewhere from the area of Signal Theory).

------
xwvvvvwx
Apparently they had a web front end where customers could _request private
keys_...

[https://twitter.com/GossiTheDog/status/968834765888589825](https://twitter.com/GossiTheDog/status/968834765888589825)

~~~
regecks
Had? Have.

[https://www.trustico.com.au/ssltools/create/csr-
pem/create-a...](https://www.trustico.com.au/ssltools/create/csr-pem/create-a-
new-csr-instantly.php)

Generated server-side.

[http://termbin.com/eu4c](http://termbin.com/eu4c)

~~~
piracykills
Yeah, that's actually surprisingly common, I remember working with a few
before that did it. StartSSL and a Comodo reseller of some sort I think.

I'm done with these companies, Let's Encrypt seems to be the only people doing
it right.

------
olliej
To clarify trustico disclosed private keys to an entity other than the owner
of the key, which automatically starts a 24 hour countdown for the CA.

regardless of who discloses the private key, a CA is required to revoke any
keys that they learn have been compromised within 24 hours. CAs have been
reprimanded in the past for failing to do so.

The only ambiguity is the initial request to revoke by trustico - essentially
for a CA the question is whether trustico is the agent for the certificatesTo
clarify they disclosed private keys to an entity other than the owner of the
key, which automatically starts a 24 hour countdown for the CA.

The only ambiguity here is whether a reseller like trustico gets to decide to
revoke certificates that they sold or whether the end users are the owner and
so are the only people who can request revocation without proof of key
compromise.

From the point of view of the CA the initial “revoke all these certs “ email
could have been any random person on the internet collecting public
certificates, and then telling the CA to revoke them.

The communication that needlessly included the private keys was equivalent to
someone trawling github or what have you, then reporting all private keys that
they found to the appropriate CA. It doesn’t matter how someone proves access
to the private key, and it doesn’t matter who demonstrates it, all that
matters is that someone said “here is evidence this key is no longer under
complete control by its owner”.

At that point a CA must revoke and no one gets to stop that.

------
albinowax_
This is insane. I guess Trustico emailed the private keys because Digicert was
acting reluctant to revoke them? Pretty bold move.

Hopefully the fact that revocation is largely broken doesn't make this
worse...

------
dwd
Having receiving multiple emails and free certificate replacements from all
parties involved, it's really just a turf war.

Trustico want to sell their customers their own branded certs, and DigiCert
aren't going to just let those customers go.

I for one am done with all of them and had any affected sites shifted to auto-
renew certs within about 20 min.

------
rzr999
On a side note they have a shady business model. When it comes to using
certificates regularly they withhold funds if you don't buy enough
certificates from them until you top up with 200 USD again. That means funds
just get stuck. They won't return them even if you cancel the account.

------
an_account_name
I won't be too surprised if Comodo decides not to do business with Trustico
after this.

------
ggm
Nobody who has depth in the business would create keypairs online if they
could avoid it. So I ask myself if key escrow requirements "back then"
permitted this kind of engagement with an agent, on behalf of government or
other constrained PKI contexts where escrow was a requirement.

If its just "for your convenience" I would have walked off this keypair years
ago.

Private key generated for me one line and held in your keystore? No thank you.

------
acd
Interesting move by the CEO.

Personally thinks that centralized CA proving trust of unknowns of long
distance again and again prove that the security of centralized trust is weak!

------
xwvvvvwx
Had to read it like 3 times before I could process. Unreal.

~~~
dullgiulio
Help me understand: this CEO has 20k private certificates he obviously should
never have seen, yet alone stored.

How is this not related to "the big distrust"? Unreal.

~~~
jackfraser
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.

~~~
praseodym
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’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...](https://developer.dnsimple.com/v2/certificates/#getCertificatePrivateKey)

~~~
bostik
> _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.

~~~
zokier
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.

~~~
icebraining
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...](http://webcache.googleusercontent.com/search?q=cache:87MSSBjLHGkJ:shop-
js.sourceforge.net/crypto2.htm+&cd=2&hl=en&ct=clnk&gl=lu&client=ubuntu)

------
jrochkind1
I do not understand.

------
kentbrew
Does anyone know the name of Trustico's CEO?

~~~
kentbrew
Ah, never mind. Zane Lucas, who is listed as a "director" most places.

------
smpetrey
Fucking insanity.

------
QML
I recently learned in my security class that certificates are the way by which
domains are publicly identified. But I don’t understand why there hasn’t been
any alternatives besides trusting these companies to issue certificates...

~~~
SteveNuts
It would be really hard to keep everyone's browsers/operating systems updated
with a list of certificates as they're generated and renewed.

You pretty much have to concentrate it down to a small subset of trusted
certificate authorities to sign your certificate.

Also, it _should_ be a way to verify that random people aren't able to get
certificates on behalf of a domain they don't own (there's nothing stopping me
from generating a cert for google.com - but it should be impossible for me to
get it trusted by your browser).

