Live data from Hacker News

Everything you should know about certificates and PKI but are too afraid to ask

smallstep.com

31–40 of 54 posts

Re: Everything you should know about certificates and PKI but are too afraid to ask

#31

The stuff about CAA is wrong. CAA is NOT checked by browsers, the BRs do not say browsers should check CAA, and indeed it is specifically NOT designed to be checked by RPs at all. CAA tells the Issuers (Certificate Authorities) whether the name owner authorises them to issue at a moment in time. If you think "that seems useless" it's probably because you completely misunderstood the security model it's written for. W…

And if a non-authorized CA ignores it and creates a cert anyway, that cert will still work. It's basically a kind of robots.txt file for CAs. I always wondered why there wasn't a secure way to prevent rogue CAs from creating valid certs, but your explanation pretty much sums it up: this is about enforcing corporate policies and making someone's job easier, not so much security.

> I always wondered why there wasn't a secure way to prevent rogue CAs from creating valid certs, but your explanation pretty much sums it up: this is about enforcing corporate policies and making someone's job easier, not so much security.

Pretty much the best attempt at this I've seen is the Certificate Transparency thing designed by Google and implemented in Let's Encrypt and a few other CAs. Having a public, auditable log of every certificate officially issued could can be used to validate certs, Chrome enforces this with new EV certs and Symantec certs.

Re: Everything you should know about certificates and PKI but are too afraid to ask

#33

Earlier quoted context omitted.

And if a non-authorized CA ignores it and creates a cert anyway, that cert will still work. It's basically a kind of robots.txt file for CAs. I always wondered why there wasn't a secure way to prevent rogue CAs from creating valid certs, but your explanation pretty much sums it up: this is about enforcing corporate policies and making someone's job easier, not so much security.

> I always wondered why there wasn't a secure way to prevent rogue CAs from creating valid certs, but your explanation pretty much sums it up: this is about enforcing corporate policies and making someone's job easier, not so much security. Pretty much the best attempt at this I've seen is the Certificate Transparency thing designed by Google and implemented in Let's Encrypt and a few other CAs. Having a public, audi…

> Chrome enforces this with new EV certs and Symantec certs.

Chrome enforces this for all new certs since earlier this year.

Re: Everything you should know about certificates and PKI but are too afraid to ask

#34

PKI works. Period. I don't understand how knowledgeable engineers complain about PKI being "too complex". The same people complain that SMTP, DNS and NTP is too difficult too (and claim it can only be solved with external services). Granted having your own home-grown authentication & identity management "salad", or a very complex system that never addressed identity/authenticity, ... then replacing this with PKI will…

> complain about PKI being "too complex"

Usually when people complain about PKI being too complex, they're complaining about the opacity of the implementations. Certificates just stop working, and you don't get anything, and there's nowhere to look to figure out why unless you're really an expert on the topic.

Re: Everything you should know about certificates and PKI but are too afraid to ask

#35
Shameless plug: For anybody interested in the cryptographic key management part there is a post about the hardware, people and processes behind the commercial cryptographic key management https://www.malgregator.com/key-management.html

Re: Everything you should know about certificates and PKI but are too afraid to ask

#36

PKI works. Period. I don't understand how knowledgeable engineers complain about PKI being "too complex". The same people complain that SMTP, DNS and NTP is too difficult too (and claim it can only be solved with external services). Granted having your own home-grown authentication & identity management "salad", or a very complex system that never addressed identity/authenticity, ... then replacing this with PKI will…

> PKI works. Period. I don't understand how knowledgeable engineers complain about PKI being "too complex".

Those are kind of two different things. Aircraft work. Brains work. CPUs work. Many things work and are still complex.

Re: Everything you should know about certificates and PKI but are too afraid to ask

#37
post #33

Earlier quoted context omitted.

> I always wondered why there wasn't a secure way to prevent rogue CAs from creating valid certs, but your explanation pretty much sums it up: this is about enforcing corporate policies and making someone's job easier, not so much security. Pretty much the best attempt at this I've seen is the Certificate Transparency thing designed by Google and implemented in Let's Encrypt and a few other CAs. Having a public, audi…

> Chrome enforces this with new EV certs and Symantec certs. Chrome enforces this for all new certs since earlier this year.

More specifically: Log servers can be shown either a normal X.509 certificate or a "pre-certificate" which is proof that a Certificate Authority intends or intended to issue some particular certificate. Right now these are actually X.509 certs that were "poisoned" to make them useless, but in future they will probably be some other format.

Anyway, when shown a new certificate or pre-certificate, the log server gives you a Signed Certificate Timestamp proving when it saw the document.

Chrome (and eventually Safari and Firefox) require suitable SCTs when shown any modern public certificate or they may conclude the certificate should not exist and fail the connection or mark it insecure, or even report it to Google/ Apple/ Mozilla for investigation.

SCTs get to the browser in one of three ways:

1. Most popular. The site's CA made pre-certificates, logged those, got back SCTs and baked the SCTs inside the real certificate. This changes nothing for a site operator, if you use Let's Encrypt and have never heard of SCTs, don't worry, all your current Let's Encrypt certs are done this way.

2. Less popular: The CA doesn't put SCTs inside the certificate, but it DOES staple them inside OCSP responses. Then you staple an OCSP response into your certificate responses and everything works.

3. Also less popular: The SCTs go in a separate TLS extension when a client connects, saying "Hey, I want SCTs" and they get them back only if they ask for them.

Re: Everything you should know about certificates and PKI but are too afraid to ask

#38
post #4

The other day I noticed that most mail doesn’t come through when disabling TLS 1.0 & TLS 1.1. To my dismay it seems some major smtp service don’t support TLS 1.2. After enabling 1.0 & 1.1 mail came rolling in. Anyone able to shed some light on what happened there to me?

Check your mail headers as they will show what protocol and cipher was negotiated - you'll be able to see if it was actually 1.0 or 1.1 that was used.

If it was TLS 1.2, disable 1.0/1.1 again and check you still have that cipher available.

Re: Everything you should know about certificates and PKI but are too afraid to ask

#39

PKI works. Period. I don't understand how knowledgeable engineers complain about PKI being "too complex". The same people complain that SMTP, DNS and NTP is too difficult too (and claim it can only be solved with external services). Granted having your own home-grown authentication & identity management "salad", or a very complex system that never addressed identity/authenticity, ... then replacing this with PKI will…

PKIs work. It's not a necessary condition to use the internet PKI / PKIX to make use of the advantages of a PKI.
Post reply on HN