DEV Community

Discussion on: Explain Certificates Like I'm Five

tailcall profile image
Anton Istomin

I really only know about TLS, so I'll explain how it works from TLS point of view. I believe this roughly applies to all digital certs systems.

A certificate is essentially a pair of private/public keys. It's split in halfs, public key part (with your domain name written in it) is sent to you. When establishing a TLS connection, server sends you some data encrypted with its private key. You decrypt it, and if decryption doesn't fail, you're (probably) talking to genuine owner of a certificate.

The funny part here is that a single certificate can't be considered trustworthy, somebody could probably hijack the connection and send you their own certificate instead of server's, and you'd never know. This is called a man-in-the-middle attack. That's where certificate authorities (CA) come into play.

Basically server owner just send their certificate for signing to a CA. Each CA has their own certificate which they use to sign other certificates. So now the server has to serve you not a single cert, but a certificate chain including CA's certificate. When you receive a server's certificate, you can always download CA's own certificate and validate a signature on a server's certificateโ€”that makes man-in-the-middle attacks not feasible.

The funniest part is that CAs can have their certificates signed by yet another CA to enforce even more trust, so in fact you're likely to receive a pretty long certificate chain:

Server's cert โ† CA1 cert โ† CA2 cert โ† CA3 cert

where โ† means "is signed by".

CA3 cert obviously is not verified by anyone. It's a so-called root certificate and the issuer of this certificate must be pretty well trusted. Root certificates are usually bundled with OS distributions and web browsers. They're usually issued by some big serious companies, but there are also community-driven root CAs, like CAcert (see