Beyond the browser, and what comes next

The situation

A partner bank emails: “From next quarter, calls to our payment API require mutual TLS. Please send us your client certificate.” The same week, your usual public CA announces that its certificates will no longer support client authentication.

Where will that certificate come from? And what else in your company quietly depends on certificates outside the browser?

What is going on

Everything in this course so far (key pairs, signatures, certificates, chains and trust stores) works the same way far beyond websites.

Swipe sideways to see the whole diagram.

Both sides show ID: mutual TLS

In mutual TLS (mTLS), the server asks the client for a certificate during the handshake. The client sends its certificate and the same kind of CertificateVerify signature the server gives (lesson 7). Both sides are now authenticated. It is common for APIs, for traffic between services, and for devices.

Public CAs are leaving this job. Chrome's root program starts phasing out root hierarchies that are not dedicated to TLS server authentication (from 15 June 2026), and Let's Encrypt certificates no longer include the TLS client authentication purpose (from 11 February 2026 for the default profile, and 8 July 2026 for the last opt-in profile). Client certificates therefore come from a private CA (lesson 9) or a provider dedicated to them. Agree with the partner which CA they will trust for your clients.

Signed and sealed: code signing

Publishers sign software with a code-signing certificate, and operating systems can check the signature before installing or running it. A valid signature says who published the code and that nobody changed it. It does not say the code is safe. Malware signed with stolen keys is a known problem, which is one reason code-signing keys belong in hardware.

A trusted timestamp, added while the certificate is still valid, proves when the signature was made. Checkers can then still verify the signature after the certificate expires.

The same idea signs PDFs and contracts. In the EU, the eIDAS Regulation says that a qualified electronic signature shall have the equivalent legal effect of a handwritten signature (Regulation (EU) No 910/2014, Article 25(2)).

Machines with passports: device identity

Routers, smart-home devices, smart meters and industrial sensors increasingly get a certificate at the factory. The private key is generated inside secure hardware on the device and never leaves it, so the device can prove what it is without a shared password.

The quantum storm

A large enough quantum computer would break today’s public-key algorithms, RSA and elliptic curves, in both key exchange and signatures. Symmetric ciphers and hashes are only weakened; 256-bit keys such as AES-256 keep a comfortable margin. The urgent risk is “harvest now, decrypt later”: traffic recorded today could be decrypted in the future. So key exchange moves first.

NIST published the first post-quantum standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), on 13 August 2024. X25519MLKEM768 hybrid post-quantum key exchange is on by default in Chrome, Firefox and Apple's operating systems. Post-quantum signatures and certificates come later; they are much larger, which affects every handshake.

Timelines are taking shape: NIST proposes deprecating quantum-vulnerable public-key algorithms at the 112-bit security level after 2030 and disallowing all of them after 2035, according to NIST IR 8547 (initial public draft, November 2024). The EU’s coordinated roadmap says EU member states should start the transition by the end of 2026, finish it for high-risk use cases by the end of 2030 and complete as much as feasible by 2035. Being ready to swap algorithms, called crypto-agility, starts with the inventory and automation from lesson 9.

Try it

Try it: Certificate decoderOpen the full tool

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

Paste a certificate

Try a sampleChoose a sample…A website certificate (www.example.com)An expired certificateA wildcard certificate (*.example.com)A certificate with a Common Name but no SANA self-signed root CAA complete chain: leaf, intermediate and root

-----BEGIN CERTIFICATE----- MIIC1zCCAnygAwIBAgIQWTTOzqWiPshGdQhNb6kmNjAKBggqhkjOPQQDAjB+MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UECxMe U2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSswKQYDVQQDEyJQS0kgWmVy byB0byBIZXJvIFNhbXBsZSBJc3N1aW5nIENBMB4XDTI2MTAwMTAwMDAwMFoXDTM2 MTAwMTAwMDAwMFowGjEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tMFkwEwYHKoZI zj0CAQYIKoZIzj0DAQcDQgAEw4og6Y/SOr+WrqSv+ng7tOBEsc5N3A3yZRk+9hsR XzPQvB9672aHZHTYFNlSY93RWVcTRieE+8XnIbWIYfwxIqOCAT4wggE6MAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMCcG A1UdEQQgMB6CD3d3dy5leGFtcGxlLmNvbYILZXhhbXBsZS5jb20wHQYDVR0OBBYE FALMipe4vcXJTpwO926S15Y/bobzMB8GA1UdIwQYMBaAFN+ph37v40SN23r6Fg/z OvSNjJqeMEgGCCsGAQUFBwEBBDwwOjA4BggrBgEFBQcwAoYsaHR0cDovL3BraS5l eGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcnQwPQYDVR0fBDYwNDAyoDCg LoYsaHR0cDovL3BraS5leGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcmww EwYDVR0gBAwwCjAIBgZngQwBAgEwCgYIKoZIzj0EAwIDSQAwRgIhAM5dJUPhL+qV artvWtQinfnykhVflJTjMXe8M6PnqQfaAiEAhOLGj1hSEkNxQoMrYNXRaIe69nq6 2unibVFSVw1AC80= -----END CERTIFICATE-----

PEM text, several PEM blocks, or a .pem, .crt, .cer or .der file (drop it on the box). Certificates are public, so they are safe to paste.

DecodeClearChoose a file

Find the Extended Key Usage field. A website certificate lists TLS server authentication (serverAuth); a client certificate for mutual TLS needs client authentication (clientAuth). Which does this one allow?

Check

Check yourself

In mutual TLS, what does each side prove?

1. Both the server and the client present a certificate and prove they hold its private key
2. Only the server proves its identity; the traffic is then encrypted twice
3. The client sends a password inside its certificate

Show answer

Answer A Both the server and the client present a certificate and prove they hold its private key

What happened

Both sides send a certificate and sign the handshake with the matching private key, so each authenticates the other.

Why

mTLS is not 'HTTPS twice'. The encryption is the same; what changes is that the client is authenticated with a certificate instead of a password or API key.

The rule

In mTLS, both sides prove possession of a private key whose certificate the other side trusts.

Check yourself

A code-signing certificate expired last month. An installer signed with it two years ago carries a trusted timestamp. What happens when someone checks the installer today?

1. The signature can no longer be verified
2. The installer must be signed again by its users
3. The signature still verifies, because the timestamp proves it was made while the certificate was valid

Show answer

Answer C The signature still verifies, because the timestamp proves it was made while the certificate was valid

What happened

The signature still verifies.

Why

The timestamp authority's own signature shows when the code was signed. The checker confirms the certificate was valid at that moment, not today.

The rule

Timestamp every code signature while the certificate is valid; it keeps signed software verifiable after the certificate expires.

Check yourself

Why are browsers already switching key exchange to post-quantum hybrids, while certificates still use classic signatures?

1. Recorded traffic could be decrypted later by a future quantum computer, but a signature only has to resist forgery at the moment of the handshake
2. Quantum computers can already forge today's certificates
3. Post-quantum signatures are not allowed in the EU

Show answer

Answer A Recorded traffic could be decrypted later by a future quantum computer, but a signature only has to resist forgery at the moment of the handshake

What happened

Key exchange protects secrets that must stay secret for years, so it is upgraded first.

Why

An attacker can record traffic now and decrypt it once a quantum computer exists: harvest now, decrypt later. A forged signature, by contrast, is only useful while the handshake is happening.

The rule

Move key exchange to post-quantum first; plan signatures and certificates next, with crypto-agility.

Takeaways

• Mutual TLS, code signing and device identity use the same parts as HTTPS. Client certificates are moving to private or dedicated CAs.
• A signature says who published code and that it is unchanged, not that it is safe; a timestamp added while the certificate is valid keeps it verifiable after expiry.
• Quantum computers threaten public-key algorithms: move key exchange first, then signatures, and use your inventory and automation to make the switch.

Go further

• Handbook: Both sides show ID: mutual TLS
• Handbook: Signed and sealed: code and document signing
• Handbook: Machines with passports: device identity
• Handbook: Post-quantum cryptography
• Where next: the handbook for depth, the browser tools, and the game, whose first levels are playable now.

In the gameLevel 23: Both sides show IDGuild Hall, Keystone. In development