> Lesson 7 of PKI in 90 minutes: the TLS 1.3 handshake step by step, what the client checks, and how to read the certificate errors browsers and tools show. Source: https://pkizerotohero.com/course/handshake-and-errors/ · Last reviewed: 2026-10-20 # 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](https://pkizerotohero.com/handbook/glossary/#tls-handshake). Here is TLS 1.3, defined in RFC 9846: *Diagram: A sequence between client and server. The client sends ClientHello with the site name (SNI) and a key share. The server replies with ServerHello and its key share; everything after this is encrypted. The server sends its certificate chain, CertificateVerify (a signature over the handshake), and Finished. The client checks the chain, the name and the dates; each failed check maps to an error: AUTHORITY\_INVALID, COMMON\_NAME\_INVALID or DATE\_INVALID. If all pass, the client sends Finished and encrypted data flows.* 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](https://pkizerotohero.com/handbook/glossary/#server-name-indication); 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](https://pkizerotohero.com/handbook/glossary/#certificate-verify), 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`](https://pkizerotohero.com/errors/chrome-err-cert-authority-invalid/) | [`SEC_ERROR_UNKNOWN_ISSUER`](https://pkizerotohero.com/errors/firefox-sec-error-unknown-issuer/) | Missing intermediate, private or self-signed certificate, inspecting proxy, outdated trust store | | Name | [`NET::ERR_CERT_COMMON_NAME_INVALID`](https://pkizerotohero.com/errors/chrome-err-cert-common-name-invalid/) | [`SSL_ERROR_BAD_CERT_DOMAIN`](https://pkizerotohero.com/errors/firefox-ssl-error-bad-cert-domain/) | Name missing from the SAN, wildcard too narrow, wrong certificate served | | Dates | [`NET::ERR_CERT_DATE_INVALID`](https://pkizerotohero.com/errors/chrome-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](https://pkizerotohero.com/handbook/glossary/#hsts), browsers do not even offer that option. Why it matters to the business Ask your team When users report certificate warnings, do we log the exact error, the network and the device? Do our HTTPS-inspecting proxies, if any, have their root deployed to every managed device, and who approved the inspection? ## Try it *Interactive tool: Paste your error (runs in the browser at [/tools/error-finder/](https://pkizerotohero.com/tools/error-finder/))* 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 What happened CertificateVerify is a signature over the handshake, made with the certificate's private key. Only the real key holder can produce it. Why Anyone can copy and send a certificate. This signature ties this live connection to the private key behind it, so an impostor with a copied certificate fails here. The rule The certificate key signs to prove identity; ECDHE agrees the secret that encrypts the traffic. 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 What happened The laptop's clock is outside the validity period of perfectly good certificates. Why Many unrelated sites failing on one device, and only there, points at that device. Validity checks use the local clock. The rule When many sites fail with date errors on one device, check its date and time before blaming the sites. 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 What happened A device on that network intercepts HTTPS and re-signs sites with its own root, which is missing from your laptop's trust store. Why It may be an approved inspection proxy whose root is only installed on managed devices, or it may be an attack. The error looks the same in both cases. The rule When every site fails on one network only, report it to IT; do not click through, and do not install unknown roots. ## 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 - Handbook: [The TLS 1.3 handshake](https://pkizerotohero.com/handbook/tls-handshake/) - Error pages: [all certificate errors explained](https://pkizerotohero.com/errors/) - Next lesson: [When trust breaks](https://pkizerotohero.com/course/when-trust-breaks/) **Early edition.** Checked against the standards; an independent expert review is in progress. Found a mistake? [Tell us](https://pkizerotohero.com/contact/?topic=content-error&page=/course/handshake-and-errors/). Last reviewed 20 October 2026Edition 0.9 ## Go deeper in the handbook - [Chapter 15: The TLS 1.3 handshake](https://pkizerotohero.com/handbook/tls-handshake/)