TLS 1.2/1.3, mTLS + Certificate Lifecycle

Encryption at rest protects data sitting still. But data spends much of its life moving — between a browser and your app, between two microservices, between your app and a database. The control that protects it in motion is TLS (Transport Layer Security), the protocol behind every https://. When a framework says "data is encrypted in transit," it means TLS, and when an auditor tests that control, they are testing your TLS configuration and the certificates that anchor it.

This lesson gives you the working model: what the TLS handshake actually accomplishes, why TLS 1.3 matters, where mutual TLS (mTLS) fits, and the certificate lifecycle — because the single most common transit-security failure is not weak cryptography, it's a certificate that expired, was misconfigured, or was never rotated.

What TLS actually does

TLS combines all three primitives from the cryptography lesson to give a connection three guarantees at once:

• Confidentiality — nobody between the two endpoints can read the traffic. The bulk data is protected with fast symmetric encryption (AES).
• Integrity — nobody can tamper with the traffic undetected, enforced with hashing/authenticated encryption.
• Authentication — you are actually talking to the server you think you are, proven with an asymmetric key pair and a certificate signed by a trusted authority.

The clever part is how the two endpoints agree on a shared symmetric key over a network anyone can listen to. That is the handshake: asymmetric cryptography is used briefly to authenticate the server and establish a shared secret, and from then on the much faster symmetric key encrypts the actual data. This is exactly the envelope-style layering from earlier — slow asymmetric crypto to bootstrap trust, fast symmetric crypto to do the work.

TLS 1.2 vs 1.3: why the version matters

TLS versions are a control in their own right, because old versions carry weak options. SSL (all versions) and TLS 1.0/1.1 are deprecated and must be disabled — supporting them is a routine finding. The live choice is between:

• TLS 1.2 — still widely acceptable when configured well, but it permits weak cipher suites and older key-exchange modes, so a TLS 1.2 endpoint is only as safe as its cipher configuration.
• TLS 1.3 — the modern default. It removed the legacy weak ciphers entirely (so it is safe-by-default), made forward secrecy mandatory, and shortened the handshake (faster connections). Forward secrecy means that even if the server's long-term private key is later stolen, past recorded sessions cannot be decrypted — each session uses ephemeral keys.

When you review transit encryption, "TLS 1.2 minimum, weak ciphers disabled, TLS 1.3 preferred" is the clean target. "TLS 1.0 still enabled for an old client" is the gap.

Mutual TLS (mTLS): both sides prove identity

In ordinary TLS, only the server presents a certificate — the client verifies the server, but the server doesn't cryptographically verify the client (that's handled later by passwords, tokens, etc.). Mutual TLS adds the second half: the client also presents a certificate, so both ends authenticate each other before any data flows.

You'll see mTLS in service-to-service communication: microservices in a service mesh (Istio, Linkerd) use mTLS so every internal call is authenticated and encrypted, internal APIs use it so only holders of a valid client certificate can connect, and zero-trust architectures use it to make "the network is trusted" assumptions unnecessary. For a GRC Engineer, mTLS is how "service A is allowed to call service B" becomes a cryptographic fact rather than a firewall rule — and it ties directly to the zero-trust networking ideas in a later phase.

The certificate lifecycle: where transit security actually breaks

Certificates are the trust anchor of TLS, and they have a lifecycle that, when neglected, is the leading cause of both outages and findings:

1. Issuance — a Certificate Authority (CA) signs your certificate, vouching that the public key belongs to your domain. Public CAs (Let's Encrypt, DigiCert) for internet-facing services; a private/internal CA for internal mTLS.
2. Deployment — the cert and its private key are installed on the server, load balancer, or CDN. The private key must be protected like any other key (this is where KMS/secret stores reappear).
3. Rotation / renewal — certificates expire (public ones are now capped around 90 days or less), so they must be renewed before expiry. Automation (ACME, cloud-managed certs) is the control; manual renewal is the time bomb.
4. Revocation — if a private key is compromised, the certificate must be revoked (CRL/OCSP) so clients stop trusting it.

The classic failures are concrete and common: a cert expires and takes the site down at 3 a.m.; a wildcard cert's private key is shared across dozens of systems so one compromise means re-issuing everywhere; a renewal is manual and the one person who knew the process left. The control that prevents all three is automated lifecycle management plus an inventory of every certificate and its expiry.

What to carry forward

TLS gives a connection confidentiality, integrity, and authentication in one handshake; TLS 1.3 is the safe-by-default target and deprecated versions must be off; mTLS extends authentication to both ends for service-to-service trust; and the certificate lifecycle — issuance, deployment, rotation, revocation — is where transit security most often breaks, so automation and an expiry inventory are the real controls.

In the next lesson you'll put this to work: auditing a deliberately weak TLS configuration, identifying each issue, and writing the remediation plan an engineering team can execute.