Part I · How it works
11.3 Certificates: how HTTPS proves who it is
alsocertificatecertificatesx509x.509cacertificate authorityca certificatesca bundleself-signedself-signed certificatelet's encryptcertificate expiredupdate-ca-certificatesopenssl s_clientssl certificateunable to get local issuer certificatecertificate verify failed
TL;DR
- A certificate says "this public key belongs to example.com", signed by a certificate authority (CA). Your system trusts 100 to 150 root CAs.
- During the TLS handshake the server sends its certificate and the intermediates; your client checks the chain up to a trusted root, the name, and the dates.
- Let's Encrypt gives free certificates that renew automatically; their lifetime is short, and getting shorter across the industry.
openssl s_client -connect example.com:443 </dev/null # chain, dates
openssl x509 -in cert.pem -noout -subject -issuer -dates
On your machine
$ atfq 11.3 Trusted 3 certificate authorities, in /etc/ssl/certs/ca-certificates.crt AES aes-aesni, with the CPU's AES instructions · SHA-256: sha256-ni RNG hardware generator tpm-rng-0 feeds the kernel TPM version 2: can hold keys and seal disk keys
An example: Alice's laptop, one of the test machines. In your terminal, this block shows your own machine, read live.
Pitfalls
- "unable to get local issuer certificate": the server doesn't send its intermediate certificate, or the CA is a private one you must add.
- Adding a company CA: copy it to
/usr/local/share/ca-certificates/and runsudo update-ca-certificates(Debian, Ubuntu), or/etc/pki/ca-trust/source/anchors/andupdate-ca-trust(Fedora). - Python's requests and Node.js often use their own CA list, not the
system's:
REQUESTS_CA_BUNDLE,NODE_EXTRA_CA_CERTS. curl -kturns all checking off: it hides the problem and invites a man in the middle.
Deep dive 2 questions
Why trust a chain?
Root CAs keep their keys offline and sign a few intermediate CAs, which sign servers' certificates. Your client only stores the roots; each link's signature proves the next was approved by the one above. Every certificate issued is also logged publicly (Certificate Transparency), so a CA issuing one for your domain behind your back gets noticed.
What does a CA check before signing?
That the requester controls the domain: by serving a token on the site over HTTP, or creating a DNS record (the ACME protocol automates it). Basic certificates prove nothing more, not who runs the site, just that you're talking to whoever controls the name.