
Everything you should know about certificates and PKI but are too afraid to ask - zodvik
https://smallstep.com/blog/everything-pki.html
======
tialaramex
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. We don't want untrustworthy
or incompetent CAs at all, this is not a guard against those. This is a guard
against trustworthy, competent CAs that you've got your own reasons to
disallow for your specific names.

Example: Facebook for years had a single preferred CA and their contract with
that CA said everything gets signed off by the certificates team. After Let's
Encrypt came on the scene a subcontractor developing example.facebook.com
needed HTTPS, didn't read all the paperwork from Facebook and just got a cert
from Let's Encrypt. Facebook security freaked out because their team hadn't
authorised this weird new certificate. Let's Encrypt did nothing wrong, but it
looked exactly like an attack. CAA lets Facebook tell every CA except the one
that knows about their internal policy, "Thanks, but no thanks". Let's Encrypt
would have checked CAA and told the subcontractor "Sorry, no, policy forbids,
check CAA" and when they went to Facebook to ask why they'd have got an earful
for not obeying policy.

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

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

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

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

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

------
DyslexicAtheist
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_ force you to deal with a lot of
technical debt. But don't blame PKI for it.

Blaming PKI has become rampant. Those that don't know can't dispute the
nonsense and those that do know may have an agenda (snake oil vendors).

Hating on PKI has become like a bad habit in IoT (vendors see an opportunity
to sell trash to an uninformed and ignorant audience). Be careful especially
in IoT: There are a lot of snake oil proposals which promise to replace PKI
here ... you should run as fast whenever you see these "proprietary, patent-
pending, post-quantum-proof, blockchain solutions !! (the correct response to
these vendors is: "BEGONE MAGICIAN!").

PKI isn't easy but neither is email, Kubernetes! It's as simply as it can be
given the circumstance and job it has to solve. And PKI is essential knowledge
as much as Latin is required for medicine.

~~~
coldtea
> _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_

Perhaps as knowledgeable engineers they can understand accidental complexity
when they see it.

~~~
therealdrag0
OTOH it's easy to dismiss something as overly complex before you understand it
yourself.

~~~
coldtea
It's even easier to build something that's more complex than needed, because
of original bad design or accumulated cruft.

~~~
therealdrag0
Definitely agree. Devs are often too comfortable with their first design
instead of iterating and simplifying.

------
sigsergv
Thanks for sharing, this kind of information is really rare and useful because
A LOT of (techincal) people just don't understand PKI and certificates
properly.

Also you've mentioned in the section “Naming things” that DN is deprecated,
strictly speaking it's not. The Subject field is deprecated when browser
matches certificate with domain, DN is still perfectly valid and Subject field
MUST contain a proper DN as stated in
[https://tools.ietf.org/html/rfc5280#section-4.1.2.6](https://tools.ietf.org/html/rfc5280#section-4.1.2.6).

~~~
juhanima
Actually it seems there is a mixup in the original text between DN
(Distinguished Name) and CN (Common Name). The former is a generic term for a
structured X.500 name, the latter a specific field in the Subject Name of a
certificate, which is technically a DN.

The convention used to be that the CN field must match the DNS name of the
server in a server TLS certificate, but this feature is indeed deprecated and
the DNS name extension should be used instead.

------
smartbit
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?

~~~
jlgaddis
It sounds like you've already figured it out.

You were requiring TLSv1.2 but some other remote mail systems didn't support
it and were unable to fallback and, as a result, couldn't negotiate a secure
connection.

Or did I miss something?

------
Wildgoose
Here's something nasty. The firewall where I am working (provided by Palo Alto
Networks) can decrypt https and other "secure" traffic passing through it. I
believe it auto-negotiates down to TLS 1.1 at which point it can decrypt
everything to plain-text and can examine it to its hearts content.

They are supposed to whitelist financial addresses (such as banking details)
but would you trust that to be happening?

~~~
black-tea
That's sadly quite normal in corporate networks. It only works because on your
computer you have the firewall installed a root CA, though. If you didn't you
would immediately be alerted of the man-in-the-middle attack the firewall is
doing.

------
shittyadmin
Hah, I think "Trust CA" deserves just as much of a "(lol)" as "Trust DMV"
given the shit some CAs have done in recent years, how many vulnerabilities
they've swept under the rug and how many of them are run by governmental
agencies in less than scrupulous places.

------
teddyh
See also _Everything you Never Wanted to Know about PKI but were Forced to
Find Out_ , by Peter Gutmann:

[http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf](http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf)

~~~
robinhowlett
It's funny how this area seems to attract titles like this. I used the same
for my blog post, "Everything You Ever Wanted to Know About SSL (but Were
Afraid to Ask)"

[http://www.robinhowlett.com/blog/2016/01/05/everything-
you-e...](http://www.robinhowlett.com/blog/2016/01/05/everything-you-ever-
wanted-to-know-about-ssl-but-were-afraid-to-ask/)

Disclaimer: I write blog posts to figure out if I understand something
correctly and appreciate any and all feedback, negative or positive.

------
yanslookup
This is really good. Reformat it and turn it in to a book. Market it as
essential reading for anyone running or thinking about running kubernetes or
vault.

Edit: actually this is way more in depth than is needed for k8s. But, I think
that's a good target market for a book you can sell like candy for $25.

~~~
viraptor
I'm curious - I've never seen tech books that short that people actually buy.
Could you link some example?

The closest I know of are the Julia Evans' zines, but I think you meant
something different.

~~~
coldtea
> _I 'm curious - I've never seen tech books that short that people actually
> buy._

Not sure about 20 pages or so, but there's a whole variety of short tech
books. O'Reilly had their "pocket reference" series, some of which are less
than 100 pages.

------
CHsurfer
At work, on Chrome I get this error: `ERR_SSL_PROTOCOL_ERROR`... oh the irony.

~~~
mmalone
That’s weird. Screen shot or something?

(Edit: work at smallstep; want to fix)

~~~
Sahbak
You should disable tls1.0 (and 1.1, preferably). Chrome has disabled the
support for that

------
viralpoetry
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](https://www.malgregator.com/key-management.html)

------
known
Love it. Very elaborate and informative.

------
teddyh
There is more to HTTPS than just certificates. For instance, the website lacks
an HSTS header.

------
zodvik
FYI - I'm not the author of the article. I found it very useful and hence
posted it here on HN.

------
cloudify
Thanks for the great tutorial, just wanted to point out a typo in your
homepage (permieter)

~~~
mmalone
Lol oops. Thanks.

------
geoffbp
Good article thanks for sharing

