Menu

The handshake and its errors

About 9 minutesCrash course

In one sentence

In the TLS 1.3 handshake the server proves it holds its certificate's key while ECDHE agrees the session secret; each failed check becomes a different error message.

The situation

Monday morning. You open a supplier portal that your team uses every day, and the browser shows a full-page warning: NET::ERR_CERT_AUTHORITY_INVALID. A colleague leans over and says: “Just click Advanced and carry on, it does that sometimes.”

Before anyone clicks: who made the mistake here? The website, the network you are on, or your own device? By the end of this lesson you will know how to tell.

What is going on

The handshake in one round trip

Before any page loads, browser and server run the TLS handshake. Here is TLS 1.3, defined in RFC 9846:

The TLS 1.3 handshake and the checks that produce certificate errors Client Server ClientHello: site name (SNI), key share ServerHello: key share everything below is encrypted Certificate: leaf + intermediates CertificateVerify: signed with the key Finished The client checks Chain to a trusted root? ✗ AUTHORITY_INVALID Name in the SAN? ✗ COMMON_NAME_INVALID Within its dates? ✗ DATE_INVALID ✓ all pass: Finished, then encrypted data
TLS 1.3: the certificate's key proves identity; ECDHE agrees the secret that protects the traffic.
  1. ClientHello. The browser lists what it supports, sends its ECDHE key share (lesson 2) and names the site it wants. That name is called SNI; unless the newer Encrypted Client Hello is in use, the network can see it.
  2. ServerHello. The server sends its own key share. Both sides compute the shared secret, and from here on the handshake is encrypted.
  3. Certificate, CertificateVerify, Finished. The server sends its leaf and intermediates (lesson 6). Then it signs the handshake so far with the certificate’s private key. That signature, CertificateVerify, is the proof that the server holds the key (lesson 4).
  4. The client checks, then sends its own Finished, and encrypted data flows.

Notice what the certificate’s key does: it signs. It never encrypts the traffic. The session keys come from the ECDHE exchange.

Three checks, three families of errors

The client checks that the chain leads to a root in its trust store, that the site’s name is in the SAN, and that the certificate is within its dates. Each failure has its own error, and every tool words it differently:

Failed check Chrome and Edge Firefox Usual causes
Chain and trust NET::ERR_CERT_AUTHORITY_INVALID SEC_ERROR_UNKNOWN_ISSUER Missing intermediate, private or self-signed certificate, inspecting proxy, outdated trust store
Name NET::ERR_CERT_COMMON_NAME_INVALID SSL_ERROR_BAD_CERT_DOMAIN Name missing from the SAN, wildcard too narrow, wrong certificate served
Dates NET::ERR_CERT_DATE_INVALID SEC_ERROR_EXPIRED_CERTIFICATE Expired certificate, or a wrong clock on the device

So who made the mistake?

For NET::ERR_CERT_AUTHORITY_INVALID, it can be any of the three:

  • The website: it serves a self-signed certificate or one from a private CA, or its chain is incomplete and the browser could not repair it.
  • The network: a company proxy or security product that inspects HTTPS re-signs every site with its own root. If that root is not in your device’s trust store, every site fails. An attacker in the middle produces the same error.
  • Your device: an old phone or operating system with an outdated trust store.

The error alone does not tell you which. Try the same site from another network and another device, then check the chain with a tool. If only one site fails everywhere, it is the website. If every site fails on one network, look at the network. Never click through by habit: on sites that use HSTS, browsers do not even offer that option.

Try it

Try it: Paste your errorOpen the full tool

Runs in your browser. Nothing you paste is sent anywhere.

The whole message or just the important line. A stack trace is fine; we look for the known parts.

Or browse all error pages by tool.

Paste a certificate error you have seen, or one from the table above. The finder shows the matching error page and its likely causes. Decide which check failed, and whether the causes point to the website, the network or your device.

Check

Check yourself

In a TLS 1.3 handshake, what does the server's CertificateVerify message prove?

  1. That the server holds the private key matching the public key in its certificate
  2. That the certificate has not been revoked
  3. That the client trusts the root CA
Show answer

Answer A That the server holds the private key matching the public key in its certificate

Check yourself

One laptop shows NET::ERR_CERT_DATE_INVALID on many different, well-known sites. Other devices are fine. What is the most likely cause?

  1. All those sites forgot to renew their certificates
  2. The Wi-Fi is too slow for the handshake
  3. The laptop's date or time is wrong
Show answer

Answer C The laptop's date or time is wrong

Check yourself

On the office network, every HTTPS site shows NET::ERR_CERT_AUTHORITY_INVALID on your personal laptop. At home everything works. What is the most likely explanation?

  1. Every website's certificate expired today
  2. Something on the office network presents its own certificates, signed by a root your laptop does not trust
  3. The browser's cache is full
Show answer

Answer B Something on the office network presents its own certificates, signed by a root your laptop does not trust

Takeaways

  • In TLS 1.3, ECDHE agrees the secret and the certificate’s key only signs to prove identity.
  • The client checks chain, name and dates; each failure is a family of errors with different names in every tool.
  • A certificate error can be the website’s, the network’s or the device’s fault. Test from another network and device before deciding.

Go further

In the gameLevel 15: The handshakeThe Barbican, Keystone. In development

Early edition. Checked against the standards; an independent expert review is in progress. Found a mistake? Tell us.

Last reviewed Edition 0.9

Go deeper in the handbook