Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DigiCert Statement on Trustico Certificate Revocation

digicert.com

Post reply on HN
Print view View original

31–40 of 76 posts

Re: DigiCert Statement on Trustico Certificate Revocation

#31

Post by brightball »

0x0 wrote: post #30

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…

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

Re: DigiCert Statement on Trustico Certificate Revocation

#32

Post by bostik »

praseodym wrote: post #9
jackfraser wrote: post #7

Earlier quoted context omitted.

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…

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://devel…

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

Re: DigiCert Statement on Trustico Certificate Revocation

#33

Post by [deleted] »

brightball wrote: post #31
0x0 wrote: post #30

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…

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

[deleted]

Re: DigiCert Statement on Trustico Certificate Revocation

#34

Post by 0x0 »

brightball wrote: post #31
0x0 wrote: post #30

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…

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

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 :)

Re: DigiCert Statement on Trustico Certificate Revocation

#35

Post by zokier »

0x0 wrote: post #34
brightball wrote: post #31

Earlier quoted context omitted.

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

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…

> 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

Tying PKI to DNS veers pretty close to DANE, and I imagine most of the criticism against DANE would remain valid.

Re: DigiCert Statement on Trustico Certificate Revocation

#36

Post by 0x0 »

zokier wrote: post #35
0x0 wrote: post #34

Earlier quoted context omitted.

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…

> 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 Tying PKI to DNS veers pretty close to DANE, and I imagine most of the criticism against DANE would remain valid.

Maybe, but today's DV PKI is already trusting DNS 100%, since certificates are issued based on using DNS responses to validate the certificate request. If you don't trust the governing body of a specific ccTLD, for example, you are already worse off today - a hostile ccTLD DNS operator could very well arrange to fake DNS responses for the duration of a certificate request?

Maybe it's not so bad to make it more obvious what a fancy .ly or .lol TLD really stands for?

Re: DigiCert Statement on Trustico Certificate Revocation

#37

Post by ceejayoz »

bostik wrote: post #32
praseodym wrote: post #9

Earlier quoted context omitted.

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://devel…

> 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 certif…

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

Re: DigiCert Statement on Trustico Certificate Revocation

#38

Post by zokier »

bostik wrote: post #32
praseodym wrote: post #9

Earlier quoted context omitted.

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://devel…

> 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 certif…

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.

Re: DigiCert Statement on Trustico Certificate Revocation

#39

Post by jackfraser »

praseodym wrote: post #9
jackfraser wrote: post #7

Earlier quoted context omitted.

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…

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://devel…

Ah, didn't know that. While it lowers the barrier to entry for getting a cert, the idea is fundamentally insecure.

Re: DigiCert Statement on Trustico Certificate Revocation

#40

Post by jackfraser »

bostik wrote: post #32
praseodym wrote: post #9

Earlier quoted context omitted.

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://devel…

> 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 certif…

> 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

Post reply on HN