Understand certificates and TLS

A TLS certificate connects a public key to an identity such as a domain name through a chain of signatures. A certificate authority signs the server’s certificate, an already-trusted root signs the CA’s certificate, and your system ships with the roots preinstalled. That chain is how your client trusts a public key it has never seen before.

You can watch the whole thing:

openssl s_client -connect flaviocopes.com:443 -servername flaviocopes.com
# Certificate chain
#  0 s:CN=flaviocopes.com
#    i:C=US, O=Let's Encrypt, CN=E7
#  1 s:C=US, O=Let's Encrypt, CN=E7
#    i:C=US, O=Internet Security Research Group, CN=ISRG Root X2
# Verify return code: 0 (ok)

During the handshake, at a high level: the client sends supported algorithms, the two sides run an ephemeral key agreement, the server presents this chain and proves possession of the private key by signing the handshake transcript. Only then do encrypted application bytes flow.

What verification checks

The client verifies the hostname (the certificate names the domain you asked for), the validity period, key usage, the certificate chain, and that it terminates at a trusted root. Inspect those fields yourself:

openssl x509 -in cert.pem -noout -subject -dates -ext subjectAltName
# subject=CN=flaviocopes.com
# notBefore=Jun 12 08:21:33 2026 GMT
# notAfter=Sep 10 08:21:32 2026 GMT
# X509v3 Subject Alternative Name:
#     DNS:flaviocopes.com, DNS:www.flaviocopes.com

Every check answers a specific attack. Skip hostname verification and a valid certificate for attacker.dev satisfies a connection to your API.

Never disable verification

Here is the incident that repeats everywhere. A developer disables certificate verification to fix a staging connection error. Traffic stays encrypted, but the client will now establish that encrypted connection with an attacker presenting any certificate. Disabling verification turns encryption into a connection with an unknown party — and the flag ships to production, because these flags always do.

Private certificate authorities and local test certificates need deliberate trust configuration instead: add your CA to the trust store, or pass it explicitly (NODE_EXTRA_CA_CERTS=ca.pem in Node). A global verification bypass turns one environment problem into a system-wide identity failure.

Certificates expire, so automate renewal and monitor expiry. An expired certificate is a full outage with a known date attached.

Practice

Inspect a real test certificate and save its names, validity period, key usage, issuer chain, and trusted root. Connect with the correct hostname and trust store. Then test a wrong hostname, expired certificate, or untrusted root and prove verification fails without a global bypass.