TLS 1.3, PKI & Cert Lifecycle

TLS protects a connection under an authentication policy. PKI helps decide which public key represents the intended service, and certificate operations keep that policy working through renewals and failures. The three layers are related but not interchangeable: encryption can succeed while you authenticate the wrong name, and a valid certificate says nothing about whether a user may read a tenant's invoice.

Preparation and optional resources

Bring HTTP over TCP, command-line literacy and the identity-versus-permission distinction from S081. The old “S060 Linux fundamentals” cue meant tool familiarity, not a dependency on a particular OpenSSL installation. No command here authorizes a remote probe or key access.

These restored links are optional discovery pointers. Historical video labels are not verified attribution, runtime, viewing, quality or reachability claims; the search remains a search.

• HTTPS, CAs and self-signed certificates — preview chain trust, then distinguish it from service-name validation below.
• TLS Handshake Explained — historical Computerphile label — the old annotation described TLS 1.2. Do not transfer its flights or key-exchange details unchanged into the TLS 1.3 walkthrough.
• TLS 1.3 Wireshark walkthrough search — optional packet-reading preparation; no capture, traffic interception or external handshake was performed here.
• Cloudflare TLS-handshake primer — supplementary overview; RFC 8446 governs the mechanism, not a claim that one tutorial covers every mode.
• How Let's Encrypt works — prepare domain-control and ACME questions; automated issuance alone does not ensure installation or timely renewal.
• Smallstep PKI overview — optional long-form context on certificates and trust distribution; compare claims against the pinned PKIX and service-identity specifications.

What TLS protects and where protection stops

TLS provides confidentiality and integrity for protected records and peer authentication according to the negotiated mode. Ordinary certificate-based HTTPS authenticates the server; client authentication is optional. The application still enforces authorization, input handling and data-at-rest protections. TLS does not promise availability or that a site's operator is honest. A phishing domain can have a valid certificate for its own name.

An envelope analogy separates the functions: symmetric traffic keys protect bulk records; authenticated handshake information establishes the peer and keys. Unlike a literal envelope, TLS records expose some metadata such as size and timing. Server names can also be exposed depending on ClientHello/ECH deployment. “Every byte is invisible” is too broad.

In a terminating load balancer, the client-to-edge TLS connection ends at the edge. A second validated TLS connection to the backend protects that hop, but the proxy sees plaintext; this is not cryptographic end-to-end confidentiality from browser to backend. Plain HTTP behind the edge leaves that hop unencrypted. mTLS authenticates both peers under their certificate policies but does not decide tenant permissions.

TLS 1.3: key agreement, identity and transcript checks

RFC 8446 (August 2018) defines three key-exchange modes: (EC)DHE, PSK-only, and PSK with (EC)DHE. This walkthrough is a fresh certificate-authenticated (EC)DHE handshake, without HelloRetryRequest or client certificates. Those scope conditions matter when discussing message count, latency and forward secrecy.

1. ClientHello offers supported versions, cipher suites, groups/signature algorithms and usually a key share. SNI indicates the requested server name; it is not itself a certificate validation result.
2. ServerHello selects mutually supported parameters under server policy, not a universally defined “strongest” cipher, and provides the key share for this mode. Key agreement and transcript-derived HKDF secrets produce separate traffic keys.
3. EncryptedExtensions carries negotiated extensions after ServerHello. The server's Certificate chain and CertificateVerify follow in a certificate-authenticated exchange. CertificateVerify signs a context-bound transcript, proving possession of the certificate key and binding identity to this handshake. The certificate's public key is used for this signature verification, not to encrypt application data to the server in TLS 1.3.
4. Finished is a MAC over the transcript using derived material. The client validates the server's identity and messages and sends its own Finished; optional client authentication inserts additional messages. The peers then use application traffic secrets rather than a single undifferentiated “session key.”

The common full TLS 1.3 handshake requires one round trip before the client's ordinary application data, versus two for a common full TLS 1.2 handshake, excluding TCP establishment and other network costs. Resumption, 0-RTT, HelloRetryRequest and connection reuse change the comparison. Not every HTTP request performs a new handshake, and no global 100 ms bound or universal “all HTTPS latency halved” follows.

Why raw Diffie–Hellman is insufficient

An unauthenticated key exchange can resist passive observers under its cryptographic assumptions but does not identify the peer. An active intermediary can establish one key with each endpoint and relay traffic. Signing the handshake binds it to a key; the client still needs a trusted way to bind that key to the intended service name. A trust store, configured certificate/public key, or a previously established PSK supplies an out-of-band trust basis. Public Web PKI is one approach, not proof that every TLS mode must use certificates.

Ephemeral (EC)DHE can protect recorded past traffic against later theft of a certificate's long-term private key when ephemeral secrets are erased and the cryptographic assumptions hold. TLS 1.3 PSK-only and 0-RTT early data do not share all of those properties. Early data is replayable under the protocol's limitations; encrypted purchase requests are not automatically safe to replay. Applications need explicit early-data acceptance rules and anti-replay/idempotency design. A normal idempotent-looking GET may still have side effects in a poorly designed application.

Version history as protocol evolution

TLS 1.2 (2008) and TLS 1.3 (2018) are distinct protocol revisions, not marketing synonyms for SSL. RFC 8446 removed static RSA key exchange and older cipher constructions, encrypts handshake messages after ServerHello, and separates key derivation stages. That supports the lesson without an unsourced story about cryptographers laughing at SSL 1.0 or a fixed adoption percentage. Post-quantum/hybrid groups are separately versioned deployments; a 2024 Kyber experiment is not a universal current TLS 1.3 requirement. Consult the chosen client/server's current supported-group policy before making interoperability claims.

X.509 anatomy and chain validation

RFC 5280 (2008) describes the X.509 PKIX certificate profile and path validation. A certificate includes subject and issuer names, serial number, validity interval, subject public-key information, signature algorithm/value and extensions. Important extensions include Basic Constraints, Key Usage, Extended Key Usage, Subject Alternative Name (SAN), policy/name constraints, revocation locations and—in applicable Web PKI profiles—transparency information.

A leaf is the end-entity certificate. An intermediate has CA authority subject to constraints and is signed along a path. A trust anchor is trusted through local policy; sending a self-signed root in a server's chain does not make it trusted. Public roots are often kept offline with strongly protected keys, but “always offline for exactly 25 years” is not a protocol rule. Intermediate and leaf validity periods are also policy choices. The root need not be sent by the server; typically send the leaf plus needed intermediates.

Validation involves chain signatures, acceptable algorithms, validity, permitted usages, constraints and a trust anchor, plus service-identity matching and the client's revocation/transparency policy. An expired intermediate can break a chain even if the leaf is current. A self-signed certificate is signed with its own key; subject equal to issuer is only “self-issued” and does not alone prove the signature is self-signed.

SAN, hostname, IP and revocation

RFC 9525 (November 2023) puts service identity in the applicable SAN types, not the subject Common Name. Match a DNS reference name to dNSName; an IP reference to an iPAddress SAN. DNS:127.0.0.1 is not the same encoding as an IP SAN. Wildcards have restricted matching rules and are not arbitrary substrings. Do not infer name correctness from a successful chain verification that did not check the expected hostname.

Expired means outside the validity interval under the verifier's clock. Revoked means the issuer has invalidated the certificate before natural expiry under the relevant mechanism. Untrusted/self-signed means the configured trust policy cannot establish an accepted path; a deliberately distributed local trust anchor may be valid for a controlled environment. Revocation checking behavior varies by client, mode and failure policy; do not promise every browser performs a hard-fail live OCSP check. Short lifetimes reduce some exposure but do not make key theft harmless.

CAA expresses which CAs a domain authorizes to issue under its policy; Certificate Transparency provides public issuance visibility in applicable ecosystems. They do different jobs. Neither can make a compromised endpoint or a malicious authorized operator safe. Name constraints and trust-store restrictions also mean the simplistic “every root can always issue any accepted name” statement needs qualification.

Certificate lifetimes and CA choice, dated explicitly

The original universal “public certificates cap at 398 days” is stale for this review date. The CA/Browser Forum requirements schedule maximum subscriber validity at 200 days for certificates issued from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. This concerns publicly trusted TLS subscriber certificates under that policy, not every internal certificate or an old certificate's retroactively shortened validity.

Let's Encrypt's 2 December 2025 lifetime announcement describes profile-specific changes: the opt-in tlsserver profile moves to 45-day certificates on 13 May 2026; the default classic profile is scheduled for 64 days on 10 February 2027 and 45 days on 16 February 2028. Its short-lived profile is another option. Therefore “all Let's Encrypt certificates last 90 days” is not a safe 2026 operational assumption. Read the actual notAfter, selected profile and ACME renewal information; do not hard-code day 60. These are the announcement's schedule and policy, not a claim that this review issued a certificate to confirm a live profile.

Private roots can be installed on managed browsers; “private CA can never be browser-facing” is false. Public CAs cannot generally issue publicly trusted certificates for private internal names such as payments.svc.cluster.local; use an appropriate internal identity system. There is no universal certificate price or root-store count, and EV does not certify application safety. Inspect support/validation terms rather than assuming a green company-name UI.

Certificate renewal, private-key rotation and browser policy

Renewal obtains a new certificate with a new validity interval; it does not, by definition, prove a new private key was generated. Key rotation replaces the signing key and distributes the corresponding certificate/verification material. Trust-anchor rollover changes what clients trust. Treat these as three coordinated changes: a renewed certificate with an old compromised key does not repair key theft; a new key with the old certificate cannot prove possession of that certificate's key; a valid new chain rooted in an undistributed private CA fails at the client. CertificateVerify's proof-of-possession requirement explains the key/certificate correspondence check.

Work an offline incident scenario: the certificate file is renewed but the edge still serves the old serial. This is an activation/reload failure, not proof the CA failed. If the served certificate is current but the intended DNS name is absent from SAN, renewal timing is irrelevant: repair the name/profile deployment. If name and dates pass but the client's configured anchor cannot validate the supplied chain, distinguish a missing intermediate from missing intended trust; never turn off verification to blur the cases. If the private key is compromised, replace the key, obtain matching certificates and apply revocation/acceptance policy rather than merely extending validity.

HSTS is an additional browser transport policy, not a substitute for these checks. Under RFC 6797 §8.1 a valid HTTPS response can establish a cached host policy for max-age; the browser ignores the header over insecure transport, and zero removes the learned policy. includeSubDomains broadens scope and can break subdomains not ready for HTTPS. A first visit before a policy is learned has a bootstrap exposure unless another mechanism such as preloading supplies it; a preload token alone is not enrollment. HSTS neither supplies a missing trust anchor nor authorizes an invoice. Discuss rollout/recovery before enabling broad scope.

ACME and reliable rotation

Let's Encrypt's protocol explanation separates domain control from certificate issuance. The ACME client proves control through a supported challenge, requests a certificate for a key, obtains it and installs it. HTTP/DNS challenge reachability, scoped DNS credentials, account-key safety and authorization reuse matter. DNS-01 is useful for wildcards but introduces DNS credential risk; HTTP-01 depends on the appropriate public HTTP path. A successful issuance log does not prove the serving process loaded the new certificate.

A rotation playbook:

1. Inventory endpoint, owner/team, names, issuer/profile, trust consumers, key location, validity and reload mechanism.
2. Automate issuance and installation with overlap; validate key/certificate correspondence, chain, SAN, permissions and usages before activation.
3. Reload safely and verify the served serial/fingerprint/expiry from the intended client path. Preserve a valid rollback plan; never restore an expired or compromised key merely to satisfy a restart.
4. Monitor renewal attempts and remaining lifetime. Choose warning/escalation thresholds proportionate to lifetime and recovery time, not fixed 30/14/7-day alerts for a six-day certificate.
5. Rehearse emergency reissuance, revocation and trust-root/intermediate rollover in an authorized nonproduction environment. New trust must reach clients before removing old trust where overlap is required.

KMS/HSM key protection is not itself an ACME certificate-renewal service. A mesh or cert-manager can automate parts of the process but still needs correct issuer policy, permissions and failure monitoring.

Diagnose the failure without disabling verification

openssl x509 -text inspects, while openssl verify validates under supplied options. s_client diagnostics need explicit verification behavior/name checking before a successful connection means an authenticated peer. Suppressing stderr or || true can conceal the very error being investigated. A normal curl https://... is encrypted with verification enabled; it is not the “unencrypted” case. -k disables important authentication checks and is not a remedy.

Offline OpenSSL reference exercise

This complete reference creates only disposable lab material in a newly chosen private directory when a learner runs it. It was syntax/source-reviewed, not executed in this review; no keys or live certificates were written. It has no network commands or listener. The unencrypted private key is only for this temporary fixture, never an operational credential.

#!/usr/bin/env bash
set -euo pipefail
umask 077
LAB=$(mktemp -d)
# Intentionally retain the private lab directory for inspection; remove it securely
# using your platform's approved cleanup after the exercise. Never commit the key.
cd "$LAB"
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 \
  -noenc -keyout server.key -out server.crt -sha256 -days 2 \
  -subj '/CN=unused-legacy-name' \
  -addext 'subjectAltName=DNS:localhost,IP:127.0.0.1'
openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName
openssl verify -CAfile server.crt -verify_hostname localhost server.crt
openssl verify -CAfile server.crt -verify_ip 127.0.0.1 server.crt
# A trusted certificate still fails the wrong reference identity.
if openssl verify -CAfile server.crt -verify_hostname wrong.example.test server.crt; then
  echo 'ERROR: unexpected name acceptance' >&2
  exit 1
fi
printf 'Lab certificate inspected and matching/mismatching identities tested.\n'

Use OpenSSL 3.x for these documented flags. -noenc avoids the original passphrase prompt mismatch; real private-key storage follows the threat model and service's supported protection mechanism. -CAfile server.crt is an explicit trust decision for this fixture, not general public PKI. For a leaf signed by an intermediate, put the root in the trusted file and the intermediate in an -untrusted chain file; do not silently promote a server-supplied intermediate into a trusted root. OpenSSL verification documentation defines those roles.

Corrected local-server reference, not executed

If a separately authorized learner wants to observe a handshake with the lab files, this single-request loopback adapter provides a bounded example. The review did not start it. Its response computes the exact byte length (the original 12-byte length for this body was correct); TLS 1.3 depends on the linked OpenSSL build, not merely the Python version.

# Reference only; requires the disposable server.crt/server.key above.
import socket
import ssl
 
context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
context.minimum_version = ssl.TLSVersion.TLSv1_3
context.load_cert_chain("server.crt", "server.key")
body = b"hello, TLS!\n"
response = (b"HTTP/1.1 200 OK\r\nConnection: close\r\nContent-Length: "
            + str(len(body)).encode("ascii") + b"\r\n\r\n" + body)
with socket.socket() as listener:
    listener.settimeout(15)
    listener.bind(("127.0.0.1", 8443))
    listener.listen(1)
    raw, address = listener.accept()
    with raw:
        raw.settimeout(5)
        with context.wrap_socket(raw, server_side=True) as stream:
            request = bytearray()
            while b"\r\n\r\n" not in request and len(request) < 4096:
                chunk = stream.recv(min(1024, 4096-len(request)))
                if not chunk:
                    break
                request.extend(chunk)
            if b"\r\n\r\n" in request:
                stream.sendall(response)

The approved local client would use curl --cacert server.crt https://127.0.0.1:8443/, not -k. Removing the IP SAN should produce an identity failure even with the same trusted certificate. This minimal adapter is not a general HTTP server: it handles one bounded request header, not arbitrary methods, bodies or concurrency. Production TLS/HTTP belongs to maintained server software with full protocol handling.

Executed certificate-policy model

This exact CPU-only model teaches conjunctive checks and boundary conditions. It performs no cryptography, file/key generation, network probes or TLS handshakes; passing it is not X.509 path-validation certification.

from dataclasses import dataclass
from ipaddress import ip_address
 
@dataclass(frozen=True)
class Leaf:
    dns: frozenset
    ips: frozenset
    not_before: int
    not_after: int
    issuer: str
    server_auth: bool = True
 
def permitted(cert, reference, now, trusted_issuers, signature_ok=True, revoked=False):
    if not signature_ok or revoked or cert.issuer not in trusted_issuers:
        return False
    if not cert.server_auth or not cert.not_before <= now <= cert.not_after:
        return False
    try:
        ref_ip = ip_address(reference)
    except ValueError:
        return reference.lower() in {x.lower() for x in cert.dns}
    return ref_ip in {ip_address(x) for x in cert.ips}
 
leaf = Leaf(frozenset({"localhost"}), frozenset({"127.0.0.1"}), 100, 200, "lab-root")
assert permitted(leaf, "localhost", 100, {"lab-root"})
assert permitted(leaf, "127.0.0.1", 200, {"lab-root"})
assert not permitted(leaf, "localhost", 201, {"lab-root"})
assert not permitted(leaf, "wrong.example.test", 150, {"lab-root"})
assert not permitted(leaf, "localhost", 150, set())
assert not permitted(leaf, "localhost", 150, {"lab-root"}, revoked=True)
assert not permitted(leaf, "localhost", 150, {"lab-root"}, signature_ok=False)
assert len(b"hello, TLS!\n") == 12
print("time, trust, identity, signature-status and revocation-policy gates: PASS")

The model supports exact DNS/IP names only; real wildcard, IDNA, chain constraints, algorithms and revocation retrieval require a real verifier. Try changing just one gate at a time: adding trust cannot fix a name mismatch, and adding a SAN cannot fix expiry. Then explain why an mTLS-authenticated service still cannot skip tenant authorization.

Production case studies and operational tradeoffs

Let's Encrypt's 29 February 2020 CAA incident report describes a rechecking bug: for multiple names Boulder could recheck one name repeatedly instead of each name. The original lesson's May date and blanket “everyone automatically renewed and barely noticed” story were unsupported. The durable lesson is that emergency reissuance can be necessary before expiry; renewal automation must react to issuer/security events as well as a fixed timer.

Fastly's 8 June 2021 report describes a latent software bug triggered by a valid customer configuration, with 85% of its network returning errors and 95% operating normally within 49 minutes. It was not a certificate-expiry incident. A generic TLS timeout may be a symptom of infrastructure failure; that report does not prove a particular downstream handshake pattern. Correlate before replacing certificates.

The original Microsoft Teams spreadsheet/departed-owner explanation is not established by a first-party passage in this review. Retain the operational question as a hypothetical expiry scenario, not that invented causal account: issuance succeeds but a process keeps serving the old cert; fix deployment/reload verification and served-certificate monitoring, not merely a reminder email.

For internal traffic, edge termination with plaintext has the fewest certificate endpoints but leaves the internal hop exposed. Re-encryption authenticates the backend and protects that hop while another layer authenticates clients. mTLS adds certificate-based client identity and enrollment/rotation complexity. It is not “twice the security at three times the cost,” nor is it sufficient for zero trust on its own. Pick from threat model, identity policy, operational capability and failure recovery; name the trust anchor and authorization boundary on every hop.

Recall and worked answers

1. Three protections and a non-goal? Record confidentiality/integrity and mode-dependent peer authentication; not application authorization or availability.
2. Handshake RTT? Common full TLS 1.3 is one RTT versus common full TLS 1.2 two, excluding transport setup; HRR/resumption/early data/reuse change the picture.
3. Unknown local issuer? Check both the served intermediate chain and local trust policy. Correct the server chain or distribute intended trust securely; do not blindly trust a received intermediate.
4. Hostname field? Applicable SAN identifier, with DNS/IP rules; RFC 9525 rejects CN fallback for service identity.
5. Leaf/intermediate/root? End-entity identity, constrained issuing CA, locally trusted anchor; lifetimes and root operations are policy, not fixed 90-day/5-year/25-year constants.
6. Teams expiry story? Do not repeat unsupported spreadsheet/personnel details. Explain instead how a monitored renewal can still fail at installation/reload and how served-cert checks expose it.
7. HSTS? HTTP Strict Transport Security, defined in RFC 6797. A valid HTTPS response can establish a max-age policy; includeSubDomains and preload require careful scope/readiness, and preload enrollment is not achieved by a header token alone. First-visit coverage differs from an already learned policy.
8. When is the certificate encrypted? In the certificate handshake after ServerHello, using handshake traffic keys; include EncryptedExtensions and CertificateVerify, not a fictional four-message total.
9. Why short lifetimes? Limit some compromise exposure and encourage reliable renewal; actual Let's Encrypt profiles and schedules vary. Use current validity/renewal information rather than assuming 90 days forever.
10. Internal mTLS CA? A controlled private/workload PKI with authenticated enrollment, narrowly distributed trust, automated renewal, authorization and outage recovery. A hypothetical 24-hour cert renewed after eight hours can still expose a stolen key for its remaining lifetime unless revocation/other policy intervenes.

Explain the difference between inspection and verification, between an expired and an untrusted certificate, and between authenticated transport and an authorized business operation.

Prerequisites and study route

Bring HTTP/TCP, public-key versus symmetric cryptography and identity-versus-permission concepts. Apply these checks to load balancers, gRPC, workload identity and ingress automation; add observability and application authorization rather than assuming TLS supplies them.

Continue to OWASP to place crypto and authentication failures in a versioned risk map. Revisit load balancing to identify the terminating edge and backend hop; gRPC to ask which peer identity is checked; observability to monitor the served certificate; and Kubernetes/ingress automation to inspect issuer and trust distribution. A payment-system design adds explicit data-handling and key-protection requirements; this lesson does not certify PCI compliance. These retain the old branch functions without pretending the old S070/S057/S105/S123 labels identify current articles or that every gRPC service uses mTLS.

Optional historical pointer: the original Teams forum discussion. Preserve it for investigation, not as proof of the unsupported spreadsheet/departed-owner story. The Let's Encrypt and Fastly primary accounts remain linked where their mechanisms are taught.

Next: S083 — OWASP risks and threat modelling, to carry trust boundaries into application design. Hub: The 6-Month Learning Plan.

Study pacing: the original pre-read block suggested 30 minutes, separately from its 90-minute session cue; individual resource durations were not verified. The session proposed intuition (5), visual walkthrough (15), hands-on (25), production cases (15) and recall/stretch (10). These are planning cues, not measured completion times; the five named blocks total 70 minutes, leaving 20 minutes of the stated session budget unallocated. Use the safe local fixtures or source-only references as marked, then explain the failure cases without notes. This retains the original 130-session-series context without promising the current catalog is an unchanged evergreen set.

Sources and verification boundary

Primary source passages were read and captured on 2026-10-08, with raw/canonical hashes, exact quote offsets and claim-specific entailment retained in the batch evidence. Historical pins describe their own versions, not current deployment recommendations.

The exact certificate-policy model was executed; it is not a cryptographic path validator. OpenSSL/loopback-server references were syntax/source-reviewed only; no certificates/keys/listener/network handshake were created.

• RFC 8446, August 2018 — RFC 8446, August 2018.
• RFC 9525, November 2023 — RFC 9525, November 2023.
• RFC 5280, May 2008 — RFC 5280, May 2008.
• Latest Baseline Requirements | CA/Browser Forum — Mutable official documentation snapshot accessed 2026-10-08T15:35:51.524388+00:00.
• Decreasing Certificate Lifetimes to 45 Days - Let's Encrypt — Let’s Encrypt announcement 2025-12-02; scheduled transitions explicitly dated.
• How It Works - Let's Encrypt — Mutable official documentation snapshot accessed 2026-10-08T15:35:51.138335+00:00.
• openssl-verify - OpenSSL Documentation — OpenSSL 3.0 verify documentation.
• RFC 6797, November 2012 — RFC 6797, November 2012.
• 2020.02.29 CAA Rechecking Bug - Incidents - Let's Encrypt Community Support — Let’s Encrypt incident report 2020-02-29.
• Summary of June 8 outage | Fastly — Fastly June 8 2021 outage report.
• RFC 8996, March 2021 — RFC 8996, March 2021.