TLS · XB Field Notes

SNI lets one IP host many TLS sites

Mon, 07 Feb 2028 00:00:00 +0000

Server Name Indication (SNI) sends the requested hostname in the TLS handshake, letting one IP address serve different certificates and sites. Without SNI, separate addresses were one solution, but a shared certificate covering several subject alternative names (SANs) or an appropriate wildcard could also serve multiple sites. The problem is ordering: in a full certificate-based HTTPS handshake without early data, certificate selection precedes the encrypted HTTP request that identifies the application.

This article focuses on nginx configuration: which server block supplies the certificate, what unmatched names encounter, and what an inspection command actually proves. Certificate selection, client verification, and application routing are separate decisions.

The name goes first

The client includes SNI in ClientHello. nginx can use that name while choosing the TLS server configuration; the extension does not require a separate request round trip. Avoid describing everything as happening before encryption: TLS 1.3 encrypts the certificate message after ServerHello.

The client must send SNI for name-based selection at this stage. Without it, nginx starts from the default server for the listening address and port. That server may offer a certificate or reject the handshake. If a certificate is offered, the client still needs to validate its chain and expected identity; receiving a certificate is not acceptance.

Match by server_name block

nginx compares the SNI name against server_name entries for the relevant listener. Matching prioritizes exact names, then the longest leading wildcard, the longest trailing wildcard, and the first matching regular expression. Certificate settings may be inherited or shared; every name does not require its own certificate.

Keep a record linking each intended name, certificate SAN, server_name rule, and application route. nginx wildcard matching and certificate wildcard matching have different scopes: a configuration match alone does not establish certificate coverage.

A correct certificate does not guarantee the correct application. nginx can select a server configuration again while processing the HTTP request line and Host header. SNI for one site and Host for another do not replace the handshake’s certificate, and TLS does not certify the response’s business meaning. Define the intended cross-name routing policy and check both layers.

Control the default fallback

For each listening address and port, use default_server to make the intended default explicit. Without that designation, the first server for that listener is the default. Missing or unmatched SNI therefore needs a deliberate policy, rather than an assumption that the first certificate always wins.

The default may serve a suitable certificate or reject the TLS handshake with ssl_reject_handshake, available since nginx 1.19.4. An HTTP landing page or return 444 acts later, after TLS; it cannot repair a certificate mismatch that prevents the client from sending HTTP. Test unknown-name and no-SNI cases separately against the chosen policy.

When it breaks

If a new hostname receives an unexpected certificate, inspect the listener, included configuration, server_name spelling, and certificate assignment. A successful nginx -T checks and prints configuration files; it does not prove the running workers loaded that version. The filtered excerpt below can omit relevant settings and errors. Compare the full output and reload result before blaming name matching.

Without Encrypted Client Hello (ECH), ordinary ClientHello SNI is visible to network observers. TLS 1.3 alone does not hide it. Successfully negotiated ECH protects the inner ClientHello, including its target name, but does not conceal every traffic characteristic. No ECH deployment or privacy measurement is established here.

The TLS name arrives before HTTP. Static mechanism illustration; no TLS connection or article command was run.

Check it quickly

This is an unexecuted diagnostic template, not a verified deployment. Replace the documentation address and example names with targets in your own authorized environment before use:

nginx -T 2>&1 | grep -B2 -A4 'server_name\|ssl_certificate ' | head -n 40
openssl s_client -connect 203.0.113.10:443 -servername shop.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer
openssl s_client -connect 203.0.113.10:443 -servername unknown.invalid </dev/null 2>/dev/null | openssl x509 -noout -subject

The pipelines print certificate subject/issuer fields. They neither display SAN coverage nor establish hostname and chain validation. Diagnostics are suppressed, and s_client normally continues after verification errors unless configured otherwise; empty output alone does not prove intentional rejection.

Separately check SAN identity, trust chain, validity dates, and verification failures using the installed OpenSSL version’s documented verification controls. Confirm known-name selection, unknown-name and no-SNI policy, and application routing in that authorized environment. Shared certificates are valid when they cover the intended identities; an unmatched name may receive the configured default or be rejected. These outcomes remain untested here.

Sources

Official documentation accessed 2026-10-18 for the claims above; this is source review, not runtime verification.

nginx HTTPS configuration, shared SAN/wildcard certificates and inherited certificate settings, checked 2026-10-18.
nginx server names and selection stages, name-matching precedence and separate TLS/request-line/Host selection stages, checked 2026-10-18.
nginx request processing and defaults, listener-scoped explicit defaults and later HTTP request processing, checked 2026-10-18.
nginx handshake rejection, TLS handshake rejection policy and its nginx 1.19.4 introduction, checked 2026-10-18.
nginx command-line parameters, configuration testing/dumping versus the separate reload operation, checked 2026-10-18.
RFC 6066, section 3: Server Name Indication, ClientHello server-name indication and unrecognized-name handling, checked 2026-10-18.
RFC 8446: TLS 1.3 handshake, encrypted handshake messages and full-handshake/early-data boundaries, checked 2026-10-18.
RFC 9849: Encrypted Client Hello, inner ClientHello name protection and remaining information exposure, checked 2026-10-18.
OpenSSL s_client diagnostics and verification, SNI selection and verification-error handling controls, checked 2026-10-18.
OpenSSL x509 certificate printing, subject/issuer/SAN inspection versus identity and chain verification, checked 2026-10-18.
OpenSSL verification options, hostname/IP identity verification and trust-policy controls, checked 2026-10-18.

OCSP stapling delivers status evidence under a client policy

Mon, 06 Dec 2027 00:00:00 +0000

OCSP stapling lets a TLS server deliver a signed certificate-status response during a handshake. A client that would otherwise make an online OCSP request may avoid that request. The saving depends on the client’s revocation policy: not every browser performs an OCSP lookup for every connection, and not every certificate issuer still operates an OCSP service. Stapling is one transport for status evidence, not a replacement for certificate validation.

Deliver evidence without transferring trust

The server obtains a response from the issuer or an authorized responder and caches it for eligible handshakes. The client still needs to check the response signature, signer authority, certificate identifier, status, and acceptable time bounds. A server cannot make a response trustworthy merely by attaching it. A good OCSP status also does not prove hostname coverage, certificate validity, or the complete trust chain.

The wire representation depends on the TLS version. TLS 1.2 uses the status-request extension and a CertificateStatus handshake message. TLS 1.3 places the status response in an extension of the corresponding Certificate entry. Calling either mechanism a generic certificate_status extension obscures that distinction. Ordinary network attackers cannot simply strip authenticated handshake messages while leaving the Finished checks valid; availability and revocation failures require a more precise threat model.

Check support before enabling anything

An operator must first confirm that the issuer supplies usable status responses and that the deployed TLS server and clients support the desired policy. Let’s Encrypt ended its OCSP service on August 6, 2025 and moved to CRLs. A missing staple on a certificate without OCSP support is therefore not automatically a broken refresh job. Check current issuer documentation instead of copying an unconditional “enable stapling everywhere” checklist.

For an issuer that supports it, refresh before expiry and after certificate rotation. Inspect the certificate association, freshness and actual edge response, not just cache presence. Different processes can hold different caches. A cached good response can remain acceptable while newer revocation information exists; stapling does not provide instantaneous revocation knowledge.

When it breaks

Missing, expired, invalid, and revoked responses are different conditions. Clients may reject, consult another mechanism, or apply a documented soft-fail policy. A missing response does not universally trigger a direct CA request, and an invalid supplied response does not universally become a harmless delay. Describe the behavior of the specific validator rather than promising that every handshake continues.

The TLS Feature extension, often called Must-Staple, can require status evidence when enforced by a supporting client. It does not force clients without that support to enforce the policy. The server must be prepared for cold starts, renewal, and responder outages before relying on such a requirement. An outage does not instantly invalidate a still-acceptable cached response, but the remaining freshness window bounds that protection.

Clock problems can change acceptance decisions. thisUpdate and nextUpdate describe status timing, while producedAt describes response production. Actual validators have age and skew rules; some valid protocol responses omit nextUpdate. Keep those implementation details explicit. Do not conclude that a Boolean labeled “signature valid” demonstrates real cryptographic verification.

OCSP evidence delivery: mechanism and evidence boundaries.

Check it quickly

Save this as stapling_policy.py and run python3 stapling_policy.py with Python 3.9 or newer. The standalone model uses synthetic post-verification inputs, requires both time bounds, and deliberately applies strict rejection to supplied invalid evidence. It has no network, certificate parser, signature implementation, TLS server, or browser.

"""Post-verification policy model. Booleans are fixtures, not cryptography."""
from dataclasses import dataclass, replace
from datetime import datetime, timedelta, timezone

@dataclass(frozen=True)
class Response:
 cert_id: str
 status: str
 signature_ok: bool
 signer_authorized: bool
 this_update: datetime
 next_update: datetime

def decide(response, now, cert_id, require_staple):
 if response is None:
 return "reject-missing" if require_staple else "consult-other-policy"
 if response.cert_id != cert_id:
 return "reject-wrong-certificate"
 if not (response.signature_ok and response.signer_authorized):
 return "reject-untrusted"
 if not response.this_update <= now < response.next_update:
 return "reject-time"
 if response.status == "revoked":
 return "reject-revoked"
 if response.status != "good":
 return "reject-unknown"
 return "status-good-only"

now = datetime(2026, 10, 15, 12, tzinfo=timezone.utc)
good = Response("synthetic-cert", "good", True, True,
 now - timedelta(hours=1), now + timedelta(hours=1))
cases = [
 (good, False, "status-good-only"),
 (None, False, "consult-other-policy"),
 (None, True, "reject-missing"),
 (replace(good, status="revoked"), False, "reject-revoked"),
 (replace(good, status="unknown"), False, "reject-unknown"),
 (replace(good, signature_ok=False), False, "reject-untrusted"),
 (replace(good, signer_authorized=False), False, "reject-untrusted"),
 (replace(good, cert_id="another-cert"), False, "reject-wrong-certificate"),
 (replace(good, next_update=now), False, "reject-time"),
 (replace(good, this_update=now + timedelta(minutes=1)), False, "reject-time"),
]
for response, required, expected in cases:
 actual = decide(response, now, "synthetic-cert", required)
 assert actual == expected, (actual, expected)
 print(actual)
assert decide(good, now + timedelta(hours=2), "synthetic-cert", False) == "reject-time"
print("PASS: 11 explicit policy cases; no certificate or TLS validation performed")

Eleven checks distinguish an acceptable status from missing, revoked, unknown, wrong-certificate, unauthorized-signer, bad-signature, expired, and future-dated inputs. The final time shift demonstrates expiration under this model’s strict interval. An optional missing response returns consult-other-policy, which is not an acceptance result and does not claim that a fetch occurred.

The success result is deliberately status-good-only: the rest of certificate validation remains outside this function. Retained Python 3.12.14 records report successful runs of these exact fences; this source review did not rerun them. Assertions must stay enabled, without -O or PYTHONOPTIMIZE. Live validation still needs the actual issuer, signed response, TLS delivery, client policy, renewal, and refresh failure.

Sources

RFC 6960, OCSP response authority, certificate binding, status and time semantics, checked 2026-10-15.
RFC 6066, TLS 1.2 status-request and CertificateStatus messages, checked 2026-10-15.
RFC 8446, TLS 1.3 certificate-entry status extension and authenticated transcript, checked 2026-10-15.
RFC 7633, TLS Feature requirements and client support, checked 2026-10-15.
Let’s Encrypt OCSP retirement, issuer ended OCSP on August 6 2025, checked 2026-10-15.
Python assert statement, optimization removes assertions and their expressions, checked 2026-10-18.

Certificate transparency makes issuance observable

Wed, 03 Nov 2027 00:00:00 +0000

Certificate Transparency makes public TLS certificate issuance observable. It does not determine whether a domain owner authorized an issuance, replace certificate-chain validation, or guarantee that every certificate everywhere is logged. A misissued certificate can have valid transparency evidence. The benefit is a public trail that monitors and affected owners can investigate.

A promise is not an inclusion proof

An SCT, or Signed Certificate Timestamp, is a log’s signed promise to incorporate a submitted certificate or precertificate within its Maximum Merge Delay. It is not another certificate and is not itself proof that the entry already exists in the tree. Its timestamp records the log’s statement, not necessarily the exact issuance instant.

A Merkle inclusion proof connects a particular serialized leaf to a particular tree root and size. The verifier must authenticate that root through the relevant signed log statement and trusted log key. Accepting whatever root accompanies an untrusted proof establishes no useful external fact: an attacker can construct an entirely different tree.

Consistency proofs answer another question: whether a later tree extends an earlier tree without changing its existing prefix. One inclusion proof cannot establish that history. Signed checkpoints, consistency verification, and comparisons between independently observed views help expose a log that equivocates. Hashes make alterations detectable under these checks; they do not physically prevent a malicious operator from changing data.

Chrome applies its own CT policy to publicly trusted TLS certificates, considering SCT delivery, accepted log states, counts, and operator diversity. That is not equivalent to searching a public log during every page load, nor to deciding whether the owner requested the certificate. RFC 9162 specifies version 2 and obsoletes RFC 6962; publication alone does not establish which protocol a particular deployed log supports.

When it breaks

A valid SCT from an unacceptable log, an insufficient set of SCTs, or an incorrect delivery mechanism may fail the target client’s policy. Conversely, satisfying CT does not fix an expired, untrusted, or wrongly named certificate. Keep normal TLS validation, CT compliance, and issuance authorization as separate decisions.

Domain monitoring also needs interpretation. A newly observed name may belong to an authorized CDN, wildcard, or renewal. Compare issuer, names, fingerprints, and your issuance inventory before escalating; unexplained issuance needs investigation and corrective action, not an assumption that logging already blocked it.

Public logging can reveal certificate names. Do not submit private certificates or sensitive internal naming solely to try an experiment. A monitor’s incomplete coverage or stale data also cannot prove absence. Operational monitoring needs a declared scope and freshness, rather than treating an empty search result as a universal guarantee.

Check it quickly

Save this as ct_probe.go and run go run ct_probe.go with Go 1.23 or newer. This offline exercise uses RFC 6962’s SHA-256 Merkle construction with three synthetic strings, not real certificates or serialized CT leaves. It verifies only the middle leaf at index one in this fixed tree.

package main

import (
 "crypto/sha256"
 "fmt"
 "runtime"
)

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func leaf(data string) [32]byte {
 return sha256.Sum256(append([]byte{0}, []byte(data)...))
}

func branch(left, right [32]byte) [32]byte {
 var data [65]byte
 data[0] = 1
 copy(data[1:33], left[:])
 copy(data[33:], right[:])
 return sha256.Sum256(data[:])
}

// Only verifies index 1 of a three-leaf fixture; not a general CT verifier.
func middleOfThree(data string, proof [][32]byte, root [32]byte) bool {
 return len(proof) == 2 && branch(branch(proof[0], leaf(data)), proof[1]) == root
}

func main() {
 a, b, c := leaf("fixture-A"), leaf("fixture-B"), leaf("fixture-C")
 root := branch(branch(a, b), c)
 check(fmt.Sprintf("%x", root) == "111b905d16e9388f6e9079aaec820ab176d649b9daecabcdb3aca45fe4b6b646", "root differs from independent fixture vector")
 check(fmt.Sprintf("%x", leaf("")) == "6e340b9cffb37a989ca544e6bb780a2c78901d3fb33738768511a30617afa01d", "empty leaf vector differs")
 check(leaf("") != sha256.Sum256(nil), "an empty tree and an empty leaf are different")
 proof := [][32]byte{a, c}
 check(middleOfThree("fixture-B", proof, root), "correct inclusion proof must pass")
 check(!middleOfThree("fixture-X", proof, root), "altered entry must fail")
 badProof := append([][32]byte(nil), proof...)
 badProof[0][0] ^= 1
 check(!middleOfThree("fixture-B", badProof, root), "altered sibling must fail")
 check(!middleOfThree("fixture-B", [][32]byte{c, a}, root), "sibling order matters")
 check(!middleOfThree("fixture-B", proof[:1], root), "short proof must fail")
 check(!middleOfThree("fixture-B", append(proof, b), root), "extra proof element must fail")
 badRoot := root
 badRoot[0] ^= 1
 check(!middleOfThree("fixture-B", proof, badRoot), "wrong trusted root must fail")
 nextRoot := branch(branch(a, b), branch(c, leaf("fixture-D")))
 check(nextRoot != root, "appending an entry changes this fixture root")
 check(!middleOfThree("fixture-B", proof, nextRoot), "old proof must not verify against the new root")
 fmt.Println("correct proof accepted; altered entry, sibling, order, length, and root rejected")
 fmt.Println("empty tree differs from empty leaf; fourth entry changes root; old proof fails")
 fmt.Printf("three-leaf fixture root: %x\n", root)
 fmt.Println(runtime.Version())
}

A leaf hashes a 0x00 byte followed by its data; an internal node hashes a 0x01 byte followed by its two child hashes. These prefixes provide domain separation. For three leaves, the left subtree contains A and B, while C stands alone on the right. An empty tree and a single empty leaf also have different hashes.

The correct proof contains A’s hash and C’s hash. Recombining them with B reproduces the expected root, which was independently cross-checked with Python’s hashlib. Changing B, a sibling, their order, proof length, or the expected root fails. Appending D changes this fixture’s root, and the old three-leaf proof no longer verifies against it.

The article uses three synthetic strings and RFC 6962 hash prefixes. The fixed proof for B consists of A and C hashes, rebuilding branch(branch(A, B), C). Its hardcoded root is trusted only within the exercise. No SCT signature, live log key, consistency proof, browser policy, or issuance authorization is established.

The retained article reports that all assertions passed with Go 1.27.0 on macOS; this review did not rerun the Go fixture. The hardcoded test root represents an already trusted three-leaf checkpoint only within this exercise. No SCT signature, real log key, certificate encoding, network endpoint, generic inclusion verifier, or consistency proof is implemented. In particular, observing a changed root does not prove append-only growth. Browser policy enforcement and live misissuance monitoring remain separate, untested operations.

Sources

RFC 6962: Certificate Transparency, version-1 Merkle hashing, SCT promises, and proof distinctions, checked 2026-09-09.
RFC 9162: Certificate Transparency version 2, protocol scope, misissuance limits, and version history, checked 2026-09-09.
Chrome Certificate Transparency policy, client-specific SCT and log acceptance requirements, checked 2026-09-09.

The forward-secrecy boundary of TLS ECDHE

Wed, 27 Oct 2027 00:00:00 +0000

Forward secrecy limits the damage from later compromise of a long-term authentication key. For a correctly authenticated ephemeral Diffie-Hellman exchange, that key alone does not reveal earlier session secrets. The claim assumes those ephemeral secrets were not also captured. It does not make a compromised endpoint, key log, or recorded plaintext safe.

Fresh agreement, authentication and key derivation are separate jobs. Forward secrecy limits a specific later-signing-key compromise scenario; it does not protect exposed session secrets or compromised endpoints.

Two kinds of keys do different jobs

In ECDHE, each side generates an ephemeral private key and sends its public share. Combining a local private key with the peer’s public share produces the same shared secret at both ends. An observer sees public shares, not the private values needed to reproduce that computation under the algorithm’s security assumptions.

TLS does not simply use the raw ECDH output as an application encryption key. Its key schedule derives distinct handshake and application traffic secrets, binds them to the handshake context, and separates directions and purposes. Fresh exchange material is one ingredient in that larger protocol, not a substitute for the protocol.

A certificate binds an identity to a public key under a trust policy. The corresponding private key signs handshake material; the certificate object does not itself sign anything. In TLS 1.3, CertificateVerify authenticates the handshake transcript in certificate-based handshakes. Without authentication, an active intermediary could replace public shares and establish separate secrets with each side.

An RSA or Ed25519 authentication key can coexist with an ephemeral exchange; the signature algorithm and key-exchange group are separate choices. TLS 1.3 also defines PSK-only resumption, which lacks DHE’s forward-secrecy property, while PSK-with-DHE adds fresh exchange material. Optional early data has weaker guarantees still. Do not infer forward secrecy for every traffic epoch solely from a TLS version or certificate label.

When it breaks

Reusing an exchange private key over long periods weakens the intended compromise boundary. Poor randomness, exposed ephemeral values, crash dumps, or TLS key logging can expose the very secrets that the guarantee assumes remain unavailable. Later disclosure of a traffic secret is a different threat from later disclosure of the certificate’s signing key.

Endpoint compromise during a session can reveal plaintext directly. A stolen authentication key can also support impersonation of future connections when an attacker can intercept them. Forward secrecy protects a particular past-traffic scenario; it does not revoke credentials or repair ongoing compromise.

Erasure is an implementation concern, not a line of reassuring prose. Setting a Go variable to nil is not proof that all copies disappeared from memory, swap, or diagnostics. Keep secrets out of logs and manage credential compromise separately from claims about recorded traffic.

Check it quickly

Save this as ecdhe_probe.go and run go run ecdhe_probe.go with Go 1.23 or newer. It uses standard-library X25519 and Ed25519 operations entirely in memory. The signing public key represents an already trusted identity for this exercise. The signed message is explicitly not a TLS transcript; this is a primitive-level experiment, not a new TLS implementation.

package main

import (
 "bytes"
 "crypto/ecdh"
 "crypto/ed25519"
 "crypto/rand"
 "fmt"
 "runtime"
)

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 identity, signingKey, err := ed25519.GenerateKey(rand.Reader)
 must(err)
 curve := ecdh.X25519()
 var previous []byte
 for round := 1; round <= 2; round++ {
 client, err := curve.GenerateKey(rand.Reader)
 must(err)
 server, err := curve.GenerateKey(rand.Reader)
 must(err)
 message := []byte("ECDH learning probe; not a TLS transcript\x00")
 message = append(message, client.PublicKey().Bytes()...)
 message = append(message, server.PublicKey().Bytes()...)
 signature := ed25519.Sign(signingKey, message)
 check(ed25519.Verify(identity, message, signature), "trusted signature must verify")
 altered := append([]byte(nil), message...)
 altered[len(altered)-1] ^= 1
 check(!ed25519.Verify(identity, altered, signature), "altered share must fail authentication")

 clientSecret, err := client.ECDH(server.PublicKey())
 must(err)
 serverSecret, err := server.ECDH(client.PublicKey())
 must(err)
 check(bytes.Equal(clientSecret, serverSecret), "peers must agree")
 if previous != nil {
 check(!bytes.Equal(previous, clientSecret), "fresh exchange must produce a different observed secret")
 }
 previous = clientSecret
 fmt.Println("round", round, "agrees; altered share fails signature verification")
 }
 _, err = curve.NewPublicKey(make([]byte, 31))
 check(err != nil, "wrong-length X25519 key must fail parsing")
 zero, err := curve.NewPublicKey(make([]byte, 32))
 must(err)
 client, err := curve.GenerateKey(rand.Reader)
 must(err)
 _, err = client.ECDH(zero)
 check(err != nil, "all-zero shared result must be rejected")
 fmt.Println("two fresh exchanges differ with one signing identity; malformed and low-order inputs rejected")
 fmt.Println(runtime.Version())
}

Each round produces matching secrets at both participants, and the two fresh rounds produce different observed secrets while retaining one signing identity. Changing a byte of the signed public-share message fails signature verification. A thirty-one-byte X25519 public key fails parsing; a length-correct all-zero input parses but fails ECDH’s all-zero-result check.

The retained article reports that all assertions passed with Go 1.27.0 on macOS; this review did not rerun the Go fixture. Only result labels are printed. The example deliberately retains the previous shared secret for comparison, so it demonstrates no secure-erasure property. It also does not prove cryptographic hardness by exhausting possible keys.

The experiment isolates agreement, freshness, authentication, and invalid-input handling. It does not exercise a real TLS transcript, certificate chain, traffic-key derivation, packet encryption, resumption, or production key disposal. Use a maintained TLS implementation for those duties and verify the actual negotiated mode; assembling these primitives is not sufficient to build a secure transport.

Sources

RFC 8446: TLS 1.3, CertificateVerify, the key schedule, PSK modes, and forward-secrecy boundaries, checked 2026-09-09.
Go crypto/ecdh, X25519 agreement and invalid public-key behavior, checked 2026-09-09.
Go crypto/ed25519, signing and verification operations, checked 2026-09-09.

DoT and DoH protect the connection to the resolver you authenticate

Thu, 07 Oct 2027 00:00:00 +0000

DNS over TLS and DNS over HTTPS protect DNS traffic on the encrypted connection between their endpoints. For a typical client, that connection ends at the selected resolver. The resolver can read the question and answer, and its later queries may follow different transports. Encrypting this hop does not automatically encrypt every recursive exchange or make the resolver unable to log the names it handles.

Read the encryption boundary and the authentication evidence separately. Ports 853/443 are normal protocol choices; 8531/8443 belong to the article’s loopback fixture. Its certificate-failure diagnostics override an exit code of zero. This is source-based illustration only: the encrypted-DNS runtime review remains pending, and the exercise was not rerun.

When it breaks

An encrypted socket without the intended certificate validation can connect to the wrong endpoint. Verify both the certificate’s trust chain and the resolver identity expected by the client. A successful handshake alone does not prove those checks were enabled. Configuration that silently uses a different resolver or a plaintext path on failure also changes the privacy contract and must be understood through the actual caller.

DoH uses HTTPS, but port 443 does not make its traffic unidentifiable, unblockable, or indistinguishable in every network. Destination addresses, connection timing, and other metadata remain observable. TLS termination points can inspect plaintext HTTP. Choose a resolver and transport policy with those boundaries in mind rather than assuming that an HTTPS URL removes every source of DNS-related information exposure.

The two protocols also have different message framing. DoT normally uses port 853 and carries DNS messages with the TCP two-byte length prefix inside TLS. DoH normally uses an HTTPS endpoint on port 443. Standard DoH carries DNS wire-format messages using application/dns-message; POST places the message in the body, while GET uses a base64url-encoded dns parameter. It is not defined as arbitrary JSON over HTTPS.

Check it quickly

Save this as check-encrypted-dns.py and run python3 check-encrypted-dns.py with Docker. The pinned BIND 9.18.49 environment supports DoT and DoH through its linked TLS and HTTP/2 libraries. The script creates a disposable certificate, trusts it explicitly for successful probes, and uses isolated loopback ports 8531 and 8443. It does not install a new host-wide trust anchor:

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,uuid
recipe='FROM python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84\nRUN apt-get update && apt-get install -y --no-install-recommends bind9=1:9.18.49-1~deb12u2 bind9-dnsutils=1:9.18.49-1~deb12u2 dnsmasq-base=2.90-4~deb12u2 python3-dnspython=2.3.0-1 && rm -rf /var/lib/apt/lists/*\nCMD ["/usr/bin/python3"]\n'
program=r"""
from contextlib import ExitStack,contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import json,re,signal,subprocess,time
import dns.exception,dns.message,dns.query,dns.rcode,dns.rdatatype

def run(*args,check=True):
 result=subprocess.run(args,capture_output=True,text=True,timeout=15)
 if check:assert result.returncode==0,(args,result.returncode,result.stdout,result.stderr)
 return result
def query(name,kind='A',port=1053):
 return dns.query.udp(dns.message.make_query(name,kind),'127.0.0.1',port=port,timeout=1)
def values(response,kind='A'):
 wanted=dns.rdatatype.from_text(kind)
 return [item.to_text() for rrset in response.answer if rrset.rdtype==wanted for item in rrset]
def show(response):
 def section(records):return [{'name':str(rr.name),'type':dns.rdatatype.to_text(rr.rdtype),'ttl':rr.ttl,'data':[item.to_text() for item in rr]} for rr in records]
 return {'rcode':dns.rcode.to_text(response.rcode()),'answer':section(response.answer),'authority':section(response.authority)}
def wait(predicate,timeout=15):
 deadline=time.monotonic()+timeout
 while time.monotonic()<deadline:
 try:
 if predicate():return
 except (OSError,dns.exception.Timeout):pass
 time.sleep(.05)
 raise AssertionError('DNS fixture condition did not become true')
def stop(process):
 if process.poll() is None:
 process.terminate()
 try:process.wait(timeout=5)
 except subprocess.TimeoutExpired:process.kill();process.wait(timeout=5)

@contextmanager
def lab(records,soa_ttl=8,minimum=4,extra=''):
 with TemporaryDirectory(prefix='xbcatm-dns-') as directory,ExitStack() as stack:
 root=Path(directory);zone=root/'zone';conf=root/'named.conf';log=root/'named.log';serial=1
 def save(body):
 zone.write_text(f'$ORIGIN lab.test.\n$TTL 30\n@ {soa_ttl} IN SOA ns.lab.test. hostmaster.lab.test. ({serial} 60 60 3600 {minimum})\n@ IN NS ns.lab.test.\nns IN A 127.0.0.1\n'+body+'\n')
 run('named-checkzone','lab.test',str(zone))
 save(records)
 conf.write_text(f'''options {{ directory "{root}"; listen-on port 1053 {{127.0.0.1;}}; listen-on-v6 {{none;}};
recursion no; dnssec-validation no; notify no; querylog yes; max-cache-size 8m; pid-file "{root}/named.pid"; session-keyfile none;
{extra} }};
controls {{}};
zone "lab.test" {{ type primary; file "{zone}"; }};
''')
 run('named-checkconf',str(conf))
 output=stack.enter_context(log.open('w'))
 authority=subprocess.Popen(['named','-g','-c',str(conf),'-n','1','-U','1'],stdout=output,stderr=subprocess.STDOUT)
 stack.callback(stop,authority)
 def ready():
 assert authority.poll() is None,log.read_text()
 response=query('lab.test.','SOA');return response.rcode()==0 and response.answer[0][0].serial==serial
 wait(ready)
 def update(body):
 nonlocal serial
 serial+=1;save(body);authority.send_signal(signal.SIGHUP);wait(ready)
 def cache(port=1054,upstream=1053,size=150,options=()):
 logfile=root/('cache-'+str(port)+'.log');stream=stack.enter_context(logfile.open('w'))
 command=['dnsmasq','--no-daemon','--conf-file=/dev/null','--no-resolv','--no-hosts','--bind-interfaces',
 '--listen-address=127.0.0.1','--port='+str(port),'--server=127.0.0.1#'+str(upstream),
 '--cache-size='+str(size),'--log-queries','--log-facility=-',*options]
 process=subprocess.Popen(command,stdout=stream,stderr=subprocess.STDOUT);stack.callback(stop,process)
 def cache_ready():
 assert process.poll() is None,logfile.read_text()
 return query('lab.test.','SOA',port).rcode()==0
 wait(cache_ready);return process,logfile
 def queries(name,kind='A'):
 return sum(bool(re.search(r'query: '+re.escape(name.rstrip('.'))+r' IN '+kind+r'\b',line)) for line in log.read_text().splitlines())
 yield root,update,cache,queries

@contextmanager
def named_process(root,config):
 root.mkdir(exist_ok=True);conf=root/'named.conf';log=root/'named.log';conf.write_text(config)
 run('named-checkconf',str(conf))
 with log.open('w') as output:
 process=subprocess.Popen(['named','-g','-c',str(conf),'-n','1','-U','1'],stdout=output,stderr=subprocess.STDOUT)
 try:
 def ready():
 assert process.poll() is None,log.read_text()
 return re.search(r'\brunning\s*$',log.read_text(),re.M) is not None
 wait(ready);yield process,log
 finally:stop(process)
import socket,ssl,struct
def exact(stream,count):
 data=b''
 while len(data)<count:
 more=stream.recv(count-len(data));assert more,'unexpected EOF';data+=more
 return data
with TemporaryDirectory(prefix='xbcatm-dot-') as directory:
 root=Path(directory);certificate=root/'certificate.pem';key=root/'key.pem'
 run('openssl','req','-x509','-newkey','rsa:2048','-nodes','-days','2','-subj','/CN=resolver.lab.test',
 '-addext','subjectAltName=DNS:resolver.lab.test,IP:127.0.0.1','-keyout',str(key),'-out',str(certificate))
 zone=root/'zone';zone.write_text('$ORIGIN lab.test.\n$TTL 30\n@ IN SOA ns.lab.test. hostmaster.lab.test. (1 60 60 3600 30)\n@ IN NS ns.lab.test.\nns IN A 127.0.0.1\nservice IN A 127.0.0.2\n')
 config=f'''tls local-tls {{ key-file "{key}"; cert-file "{certificate}"; }};
http local-http {{ endpoints {{ "/dns-query"; }}; }};
options {{ directory "{root}"; listen-on port 1053 {{127.0.0.1;}};
listen-on port 8531 tls local-tls {{127.0.0.1;}};
listen-on port 8443 tls local-tls http local-http {{127.0.0.1;}};
listen-on-v6 {{none;}}; recursion no; dnssec-validation no; notify no;
pid-file "{root}/named.pid"; session-keyfile none; max-cache-size 8m; }};
controls {{}}; zone "lab.test" {{ type primary; file "{zone}"; }};
'''
 with named_process(root,config):
 context=ssl.create_default_context(cafile=str(certificate));context.set_alpn_protocols(['dot'])
 with socket.create_connection(('127.0.0.1',8531),timeout=2) as raw,context.wrap_socket(raw,server_hostname='resolver.lab.test') as stream:
 q=dns.message.make_query('service.lab.test.','A');wire=q.to_wire();stream.sendall(struct.pack('!H',len(wire))+wire)
 count=struct.unpack('!H',exact(stream,2))[0];response=dns.message.from_wire(exact(stream,count))
 assert response.id==q.id and values(response)==['127.0.0.2'];tls_version=stream.version();alpn=stream.selected_alpn_protocol()
 failures={}
 for name,ctx,hostname in [('untrusted',ssl.create_default_context(),'resolver.lab.test'),('wrong_name',context,'different.lab.test')]:
 try:
 with socket.create_connection(('127.0.0.1',8531),timeout=2) as raw,ctx.wrap_socket(raw,server_hostname=hostname):pass
 raise AssertionError('certificate validation unexpectedly succeeded')
 except ssl.SSLCertVerificationError as error:failures[name]=error.verify_code
 https={}
 for mode in ('https-get','https-post'):
 output=run('dig','@127.0.0.1','-p','8443','service.lab.test.','A','+'+mode,'+tls-ca='+str(certificate),
 '+tls-hostname=resolver.lab.test','+short','+tries=1','+time=2').stdout
 assert output.strip()=='127.0.0.2',output;https[mode]=output.strip()
 doh_rejections={}
 for label,verification in [('untrusted',['+tls-ca','+tls-hostname=resolver.lab.test']),
 ('wrong_name',['+tls-ca='+str(certificate),'+tls-hostname=different.lab.test'])]:
 rejected=run('dig','@127.0.0.1','-p','8443','service.lab.test.','A','+https-get',*verification,'+short','+tries=1','+time=2',check=False)
 diagnostic=rejected.stdout+rejected.stderr
 assert 'TLS peer certificate verification' in diagnostic and 'failed:' in diagnostic,(label,diagnostic)
 assert not re.search(r'^127\.0\.0\.2$',diagnostic,re.M)
 doh_rejections[label]={'exit':rejected.returncode,'diagnostic':diagnostic.strip(),'no_DNS_answer':True}
 wrong_path=run('dig','@127.0.0.1','-p','8443','service.lab.test.','A','+https=/wrong',
 '+tls-ca='+str(certificate),'+tls-hostname=resolver.lab.test','+tries=1','+time=2',check=False)
 assert wrong_path.returncode!=0
 print(json.dumps({'DoT':{'answer':values(response),'TLS_version':tls_version,'ALPN':alpn},'certificate_rejections':failures,
 'DoH_verified_TLS':https,'DoH_certificate_rejections':doh_rejections,'wrong_DoH_path_exit':wrong_path.returncode,
 'wrong_DoH_path_diagnostic':wrong_path.stdout+wrong_path.stderr},sort_keys=True))
"""
name='xbcatm-dns-'+uuid.uuid4().hex[:10]
def docker(*args,**kwargs):return subprocess.run(['docker',*args],capture_output=True,text=True,timeout=300,**kwargs)
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'Dockerfile').write_text(recipe)
 built=docker('build','-t',name,str(root));assert built.returncode==0,built.stderr
 result=docker('run','--rm','-i','--name',name,'--network','none','--memory','384m','--pids-limit','128',name,
 '/usr/bin/python3','-',input=program)
 assert result.returncode==0,result.stderr
 print(json.dumps(json.loads(result.stdout),sort_keys=True))
finally:
 docker('rm','-f',name);docker('image','rm',name)

The Python DoT client authenticates resolver.lab.test, negotiates TLS 1.3 with ALPN dot in the recorded run, and sends a length-prefixed DNS question. It reads the complete framed response, verifies the message ID, and receives A 127.0.0.2 for service.lab.test. Supplying the loopback connection address separately from the expected TLS hostname keeps endpoint location and authenticated identity explicit.

Two DoT controls fail certificate verification: using the system trust store without the disposable certificate, and requesting a different hostname while trusting that certificate. These failures demonstrate both trust and name checks. The test catches the specific certificate-verification exception; it does not classify an arbitrary socket failure as successful proof that certificate validation worked.

For DoH, dig performs HTTPS GET and POST queries against /dns-query with explicit CA and hostname validation. Both return 127.0.0.2. The untrusted-certificate and wrong-hostname controls emit certificate-verification errors without a DNS answer, despite exiting zero in this version. The assertions inspect those diagnostics instead of trusting exit status. Querying /wrong with valid trust settings also fails: authenticated HTTPS still needs the correct endpoint path.

The bad-path diagnostic is a failed exchange, not NXDOMAIN and not evidence that service.lab.test disappeared. This example does not extract a specific HTTP status from that diagnostic. It preserves the distinction between transport or endpoint failure and a completed DNS response carrying a DNS response code, preventing a generic command failure from being reported as an authoritative negative answer.

Keep the resolver and bootstrap configuration visible

A client needs an address for its encrypted resolver before it can connect. Deployments can provide bootstrap addresses or another documented discovery path. The fixture supplies loopback directly, avoiding a circular dependency on the same resolver. In production, verify how bootstrap, certificate renewal, endpoint changes, and connection failures behave for the client implementation actually in use.

Check whether application queries traverse the configured encrypted connection. Other processes may use the operating system’s resolver, another browser setting, or cached data. One successful DoH command demonstrates that command’s path, not a machine-wide policy. Observe the intended applications and their failure behavior before claiming that all their name lookups receive the same transport protection.

Finally, DNSSEC and encrypted DNS address different properties. DNSSEC can authenticate signed DNS data through a trust chain; TLS protects and authenticates the selected transport endpoint. Neither mechanism automatically supplies the other’s guarantee. Use both where the service contract requires them, and keep evidence for certificate validation, actual encrypted queries, resolver trust, and DNS-data validation distinct.

Sources

RFC 7858 DNS over TLS, TLS transport, dedicated port, and connection framing, checked 2026-09-12.
RFC 8484 DNS over HTTPS, DoH GET and POST mapping and application/dns-message, checked 2026-09-12.
BIND 9.18.49 tools, dig encrypted transports and explicit certificate validation, checked 2026-09-12.

Client certificates authenticate control of a private key

Mon, 06 Sep 2027 00:00:00 +0000

Mutual TLS authenticates a client’s control of a certificate’s private key as well as the server’s identity. It does not inherently identify a physical device. A copied software key can be used elsewhere; hardware binding and device attestation require additional mechanisms. An enrollment policy can associate a key with a device, but TLS alone does not establish that association.

mTLS authenticates control of a private key. Application authorization follows the verified identity; valid credentials can still receive 403. Physical device identity and credential lifecycle need additional controls.

Authentication still needs authorization

During certificate-based TLS 1.3 client authentication, the server requests a certificate and the client proves control of the corresponding private key through CertificateVerify. Sending certificate bytes alone is insufficient. Both peers must apply their intended trust rules, including chain validity and appropriate certificate usage; the client must also verify the server’s name.

The server’s client-CA trust pool and the client’s server trust pool serve different directions. Trust only the intended issuers, and define which verified certificate field identifies a workload. A URI SAN can supply an application identifier, but the issuer’s enrollment rules determine who may receive it. A name in a certificate is not automatically permission to call every API.

Requiring a certificate is also different from merely requesting one. In Go, RequireAndVerifyClientCert requires a valid client certificate; optional modes can allow a connection without one. After authentication, apply authorization to the verified identity. A valid guest may deserve HTTP 403 rather than an authenticated reader’s HTTP 200.

When it breaks

A missing certificate, unknown issuer, expired credential, or inappropriate extended key usage can prevent client authentication. Changing the server policy to accept any certificate or disabling server verification conceals the boundary instead of repairing the credential. Separate handshake failures from application denials so that operators investigate the right layer.

Private keys need controlled storage, issuance, rotation, and incident response. Certificate renewal does not necessarily replace the key. A stolen usable key may support impersonation until acceptance is withdrawn; waiting for expiry is not the only response. Go’s certificate Verify does not perform revocation checking, so do not assume a published revocation is automatically enforced.

TLS termination also changes where identity is established. A backend receiving a caller-controlled identity header has not thereby verified the caller’s certificate. Any trusted identity propagation must have its own authenticated boundary and spoofing protections. Existing connections and resumed sessions additionally need explicit lifecycle policy when credentials or permissions change.

Check it quickly

Save this as mtls_probe.go and run go run mtls_probe.go with Go 1.23 or newer. It generates client CAs and credentials in memory, backdating notBefore by one minute and setting notAfter one hour ahead. The loopback server uses httptest’s test server certificate; the supplied test client trusts that certificate. Neither trust store is installed globally, and private keys are never printed or written.

package main

import (
 "crypto/ed25519"
 "crypto/rand"
 "crypto/tls"
 "crypto/x509"
 "crypto/x509/pkix"
 "errors"
 "fmt"
 "io"
 "log"
 "math/big"
 "net/http"
 "net/http/httptest"
 "net/url"
 "runtime"
 "sync/atomic"
 "time"
)

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func authority(serial int64) (*x509.Certificate, ed25519.PrivateKey) {
 public, private, err := ed25519.GenerateKey(rand.Reader)
 must(err)
 now := time.Now()
 template := &x509.Certificate{
 SerialNumber: big.NewInt(serial), Subject: pkix.Name{CommonName: fmt.Sprint("fixture-ca-", serial)},
 NotBefore: now.Add(-time.Minute), NotAfter: now.Add(time.Hour),
 IsCA: true, BasicConstraintsValid: true, KeyUsage: x509.KeyUsageCertSign,
 }
 der, err := x509.CreateCertificate(rand.Reader, template, template, public, private)
 must(err)
 certificate, err := x509.ParseCertificate(der)
 must(err)
 return certificate, private
}

func credential(serial int64, identity string, usage x509.ExtKeyUsage, ca *x509.Certificate, signer ed25519.PrivateKey) tls.Certificate {
 public, private, err := ed25519.GenerateKey(rand.Reader)
 must(err)
 name, err := url.Parse("urn:example:" + identity)
 must(err)
 now := time.Now()
 template := &x509.Certificate{
 SerialNumber: big.NewInt(serial), URIs: []*url.URL{name},
 NotBefore: now.Add(-time.Minute), NotAfter: now.Add(time.Hour),
 KeyUsage: x509.KeyUsageDigitalSignature, ExtKeyUsage: []x509.ExtKeyUsage{usage},
 }
 der, err := x509.CreateCertificate(rand.Reader, template, ca, public, signer)
 must(err)
 certificate, err := x509.ParseCertificate(der)
 must(err)
 return tls.Certificate{Certificate: [][]byte{der}, PrivateKey: private, Leaf: certificate}
}

func main() {
 ca, signer := authority(1)
 foreignCA, foreignSigner := authority(2)
 reader := credential(3, "reader", x509.ExtKeyUsageClientAuth, ca, signer)
 guest := credential(4, "guest", x509.ExtKeyUsageClientAuth, ca, signer)
 foreign := credential(5, "reader", x509.ExtKeyUsageClientAuth, foreignCA, foreignSigner)
 serverOnly := credential(6, "reader", x509.ExtKeyUsageServerAuth, ca, signer)
 roots := x509.NewCertPool()
 roots.AddCert(ca)
 options := x509.VerifyOptions{Roots: roots, KeyUsages: []x509.ExtKeyUsage{x509.ExtKeyUsageClientAuth}}
 _, err := foreign.Leaf.Verify(options)
 var unknown x509.UnknownAuthorityError
 check(errors.As(err, &unknown), "foreign issuer fixture must fail trust")
 _, err = serverOnly.Leaf.Verify(options)
 var invalid x509.CertificateInvalidError
 check(errors.As(err, &invalid) && invalid.Reason == x509.IncompatibleUsage, "server-only fixture must fail client usage")

 var handled atomic.Int64
 server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 handled.Add(1)
 check(len(r.TLS.VerifiedChains) > 0, "handler requires a verified client chain")
 identities := r.TLS.VerifiedChains[0][0].URIs
 if len(identities) != 1 || identities[0].String() != "urn:example:reader" {
 http.Error(w, "forbidden", http.StatusForbidden)
 return
 }
 fmt.Fprintln(w, "reader allowed")
 }))
 server.Config.ErrorLog = log.New(io.Discard, "", 0)
 server.TLS = &tls.Config{
 MinVersion: tls.VersionTLS13, MaxVersion: tls.VersionTLS13,
 ClientAuth: tls.RequireAndVerifyClientCert, ClientCAs: roots, SessionTicketsDisabled: true,
 }
 server.StartTLS()
 defer server.Close()
 request := func(certificate *tls.Certificate) (int, error) {
 config := server.Client().Transport.(*http.Transport).TLSClientConfig.Clone()
 check(!config.InsecureSkipVerify, "server identity verification must remain enabled")
 config.MinVersion = tls.VersionTLS13
 if certificate != nil {
 config.GetClientCertificate = func(*tls.CertificateRequestInfo) (*tls.Certificate, error) {
 return certificate, nil
 }
 }
 transport := &http.Transport{TLSClientConfig: config, DisableKeepAlives: true}
 defer transport.CloseIdleConnections()
 client := &http.Client{Transport: transport, Timeout: 2 * time.Second}
 request, err := http.NewRequest(http.MethodGet, server.URL, nil)
 must(err)
 request.Header.Set("X-Client-ID", "urn:example:reader")
 response, err := client.Do(request)
 if err != nil {
 return 0, err
 }
 defer response.Body.Close()
 _, err = io.Copy(io.Discard, response.Body)
 must(err)
 check(response.TLS.Version == tls.VersionTLS13 && len(response.TLS.VerifiedChains) > 0, "client requires a verified TLS 1.3 server")
 return response.StatusCode, nil
 }
 for _, test := range []struct {
 name string
 certificate *tls.Certificate
 status int
 }{
 {"reader", &reader, 200}, {"guest", &guest, 403},
 {"missing", nil, 0}, {"foreign issuer", &foreign, 0},
 {"wrong usage", &serverOnly, 0}, {"reader again", &reader, 200},
 } {
 status, err := request(test.certificate)
 if test.status == 0 {
 check(err != nil && status == 0, "invalid client must fail before HTTP")
 } else {
 must(err)
 check(status == test.status, "wrong authorization result")
 }
 fmt.Println(test.name, "HTTP status:", status)
 }
 check(handled.Load() == 3, "only reader, guest, and reader again may reach HTTP")
 fmt.Println("three TLS rejections; authenticated guest denied despite claimed reader header")
 fmt.Println(runtime.Version())
}

The reader returns 200; a guest signed by the same trusted CA returns 403 despite claiming the reader identity in X-Client-ID. Authorization reads the verified certificate’s exact URI SAN, not that header. The fixture’s URNs are application labels, not network addresses, and only urn:example:reader is authorized.

Missing credentials, a foreign issuer, and server-only extended key usage each fail before HTTP. The zero printed for them is an internal no-response marker, not an HTTP status code. Separate X.509 checks confirm UnknownAuthorityError and IncompatibleUsage for the two invalid certificate fixtures. The final reader succeeds again, and exactly three requests reach the handler.

The callback deliberately offers each supplied client credential, including the foreign one, rather than silently selecting no certificate from the server’s advertised CA preferences. This exercises the server rejection path. Production selection should respect the certificate request. Each request uses a fresh transport with a two-second timeout; connection reuse and session tickets are disabled.

The retained article reports that all assertions passed with Go 1.27.0 on macOS; this review did not rerun the Go fixture. This tests actual mutual TLS plus one explicit authorization rule, not hardware-backed identity or a production PKI. It does not test revocation delivery, automated renewal, expired clients during a handshake, resumed sessions, reverse-proxy identity forwarding, or authorization changes on existing connections. Those remain separate deployment checks.

Sources

RFC 8446: TLS 1.3, certificate requests and proof of private-key control, checked 2026-09-09.
Go crypto/tls, client-authentication modes, trust pools, and certificate selection, checked 2026-09-09.
Go crypto/x509, client-authentication usage, verified chains, and revocation limitations, checked 2026-09-09.
Go net/http/httptest, isolated TLS servers and trusted test clients, checked 2026-09-09.

TLS 1.3 resumption reuses authentication state

Sun, 08 Aug 2027 00:00:00 +0000

Saving a round trip depends on the protocol and early-data mode. In TLS 1.3, an ordinary full handshake and a resumed handshake without early data normally both take one TLS round trip. Resumption can still reduce certificate transmission and authentication work. Enabling tickets does not make every HTTPS request start one RTT sooner.

TLS 1.3 resumption reuses authentication state on a new connection and derives fresh traffic keys. Ordinary resumption does not promise one fewer round trip. Optional early data has separate replay, forward-secrecy and rejection limits.

New connection, fresh traffic keys

TLS resumption establishes a new connection using a PSK derived from an earlier handshake. A NewSessionTicket supplies an opaque identity associated with that state; it is not permission to reuse old traffic keys unchanged. The new handshake derives traffic keys for its own context. Servers may protect ticket state cryptographically or keep state behind an opaque identifier; applications should not parse tickets as portable credentials.

When the server accepts PSK authentication, it omits its Certificate and CertificateVerify messages. Resumption can include a fresh ephemeral Diffie-Hellman exchange for forward secrecy. TLS 1.3 also permits PSK-only operation, which lacks that protection. Do not infer either the selected mode or a latency saving from the existence of a ticket.

Optional 0-RTT lets eligible application data accompany ClientHello. That is separate from ordinary resumption. Early data is not forward secret and can be replayed across connections; even completing one handshake does not undo a replay elsewhere. HTTP deployments must decide which operations tolerate replay and handle rejection appropriately, including 425 Too Early where specified.

When it breaks

A client may never cache tickets, may close before processing a post-handshake ticket, or may lose cached state between requests. A server may decline an expired or unrecognized ticket after a restart or key rotation. A full handshake after an attempted resume is not automatically a TLS outage; measure the resume rate separately from connection success.

HTTP connection reuse can hide the distinction entirely. Repeating requests on one established socket performs no new handshake. To test resumption, deliberately create a new TCP connection and inspect both peers’ negotiated state. Request duration alone mixes scheduling, transport setup, server work, and cache effects.

Ticket and cache state are sensitive. Limit their scope and lifetime, coordinate server key rotation, and revisit cached authentication when policy changes. In Go, VerifyPeerCertificate is not called on resumed connections; VerifyConnection runs on all connections. Custom checks that must apply to resumptions belong on the latter path. This does not justify disabling normal certificate verification.

Check it quickly

Save this as resumption_probe.go and run go run resumption_probe.go with Go 1.23 or newer. The local HTTPS fixture and client both require TLS 1.3. Its certificate is trusted only inside the fixture. HTTP/1.1 keep-alive reuse is disabled, while two separate transports share the same four-entry TLS session cache. A third transport deliberately has no cache.

package main

import (
 "context"
 "crypto/tls"
 "fmt"
 "io"
 "net"
 "net/http"
 "net/http/httptest"
 "runtime"
 "strconv"
 "sync/atomic"
 "time"
)

type connectionKey struct{}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 var serial, verified atomic.Int64
 server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 id := r.Context().Value(connectionKey{}).(int64)
 w.Header().Set("X-Connection-ID", strconv.FormatInt(id, 10))
 w.Header().Set("X-Resumed", strconv.FormatBool(r.TLS.DidResume))
 fmt.Fprintln(w, "ok")
 }))
 server.Config.ConnContext = func(ctx context.Context, connection net.Conn) context.Context {
 return context.WithValue(ctx, connectionKey{}, serial.Add(1))
 }
 server.TLS = &tls.Config{MinVersion: tls.VersionTLS13, MaxVersion: tls.VersionTLS13}
 server.StartTLS()
 defer server.Close()

 base := server.Client().Transport.(*http.Transport).TLSClientConfig.Clone()
 base.MinVersion, base.MaxVersion = tls.VersionTLS13, tls.VersionTLS13
 check(!base.InsecureSkipVerify, "certificate verification must stay enabled")
 base.VerifyConnection = func(state tls.ConnectionState) error {
 if len(state.VerifiedChains) == 0 {
 return fmt.Errorf("verified certificate chain required")
 }
 verified.Add(1)
 return nil
 }
 request := func(cache tls.ClientSessionCache) (int64, bool) {
 config := base.Clone()
 config.ClientSessionCache = cache
 transport := &http.Transport{
 TLSClientConfig: config,
 DisableKeepAlives: true,
 }
 defer transport.CloseIdleConnections()
 client := &http.Client{Transport: transport, Timeout: 2 * time.Second}
 response, err := client.Get(server.URL)
 check(err == nil, fmt.Sprint(err))
 defer response.Body.Close()
 body, err := io.ReadAll(response.Body)
 check(err == nil, fmt.Sprint(err))
 check(response.StatusCode == 200 && string(body) == "ok\n", "unexpected HTTP reply")
 check(response.ProtoMajor == 1 && response.ProtoMinor == 1, "HTTP/1.1 required")
 check(response.TLS.HandshakeComplete && response.TLS.Version == tls.VersionTLS13, "TLS 1.3 required")
 id, err := strconv.ParseInt(response.Header.Get("X-Connection-ID"), 10, 64)
 check(err == nil, fmt.Sprint(err))
 resumed := response.TLS.DidResume
 check(response.Header.Get("X-Resumed") == strconv.FormatBool(resumed), "peers disagree")
 return id, resumed
 }

 cache := tls.NewLRUClientSessionCache(4)
 firstID, first := request(cache)
 secondID, second := request(cache)
 thirdID, third := request(nil)
 check(firstID == 1 && secondID == 2 && thirdID == 3, "three new TCP connections required")
 check(!first && second && !third, "expected full, resumed, full")
 check(verified.Load() == 3, "VerifyConnection must run for all three handshakes")
 fmt.Printf("new TCP connections: %d %d %d; DidResume: %t %t %t\n",
 firstID, secondID, thirdID, first, second, third)
 fmt.Println("both peers agree; VerifyConnection ran three times; no early data was sent")
 fmt.Println(runtime.Version())
}

Reading each response to completion lets this fixture’s post-handshake ticket be processed before the next connection. Each accepted TCP connection gets an independent server-side number. The expected sequence is connections 1, 2, 3 with DidResume false, true, false. The response also carries the server’s own resume flag, which must agree with the client’s value. VerifyConnection runs three times, including the resumed handshake, while the standard certificate checks remain enabled.

The retained article reports that all assertions passed with Go 1.27.0 on macOS; this review did not rerun the Go fixture. The resumed connection’s verified-chain state does not mean a new certificate message was transmitted; it is associated with the authenticated session being resumed. Session state stays in the in-memory cache; no ticket, private key, or traffic secret is printed or written to disk.

This experiment proves acceptance of a cached session on a new transport and full negotiation without the cache. It does not send early data, count packets, benchmark handshake CPU, or validate ticket sharing across a load-balanced fleet. Test those separately before predicting a production speedup. A faster local second request alone would prove none of them.

Sources

RFC 8446: TLS 1.3, sections 2.2, 2.3, 4.6.1, and 8: PSKs, tickets, early data, and replay, checked 2026-09-09.
RFC 8470: Using Early Data in HTTP, replay-sensitive processing and 425 responses, checked 2026-09-09.
Go crypto/tls, ClientSessionCache, DidResume, and verification callbacks, checked 2026-09-09.
Go net/http/httptest, isolated loopback HTTPS fixtures, checked 2026-09-09.

TLS handshakes add latency you can shrink

Mon, 28 Jun 2027 00:00:00 +0000

HTTPS latency combines several stages, and a warm request may avoid some without making cryptography faster. DNS, connection acquisition, TCP setup, TLS authentication, server work, and response transfer have different clocks. First determine which stages actually ran. Request duration alone cannot distinguish an existing connection from a new connection that resumed a TLS session.

Messages travel in flights

A TLS handshake contains several messages, but each message does not require its own round trip. Messages can travel together in a flight. A usual TLS 1.3 full handshake needs one TLS round trip before normal client application data; HelloRetryRequest adds another. TCP establishment and the later application request/response remain separate costs.

Ordinary TLS 1.3 resumption without early data also normally takes one TLS round trip. It can reduce certificate transmission and authentication work, but may still perform fresh ephemeral key exchange. Resumption derives new traffic keys rather than reusing old encryption keys unchanged. Optional 0-RTT is a separate facility with replay-related security limits, not a synonym for a fast repeat request.

HTTP connection reuse avoids establishing another connection entirely, so that request performs no new TLS handshake. HTTP/2 multiplexing can similarly share one established connection among streams. In contrast, closing an idle connection and opening another one still requires transport setup, even if a cached ticket lets TLS resume.

When it breaks

Creating a new transport for every normal request discards the connection pool. Leaving response bodies unread or unclosed can also prevent reuse. Idle timeouts, endpoint changes, or concurrent demand can create additional connections. Classify requests by observed reuse and handshake events before attributing a latency change to certificate algorithms.

A full handshake after attempted resumption is not necessarily an outage. Tickets can expire or be declined, and a client may lack usable cached state. Preserve normal certificate verification and measure the resulting behavior. Reducing authentication checks to win a benchmark would change the security contract, not simply improve the same operation.

Timing names need definitions. Time to first response byte includes more than TLS, while total request time also includes consuming the response. Trace hooks can run on different goroutines, so collectors need synchronization. Compare representative distributions and connection categories; a few loopback microsecond values cannot predict an Internet speedup.

Check it quickly

Save this as latency_probe.go and run go run latency_probe.go with Go 1.23 or newer. The fixture uses verified TLS 1.3 and HTTP/1.1. A server-side counter identifies accepted TCP connections. The first transport retains both an HTTP connection pool and a TLS session cache; a separate transport deliberately has no session cache.

package main

import (
 "context"
 "crypto/tls"
 "fmt"
 "io"
 "net"
 "net/http"
 "net/http/httptest"
 "net/http/httptrace"
 "runtime"
 "strconv"
 "sync"
 "sync/atomic"
 "time"
)

type connectionKey struct{}

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 var connections atomic.Int64
 server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 w.Header().Set("X-Connection-ID", fmt.Sprint(r.Context().Value(connectionKey{})))
 w.Header().Set("X-Resumed", strconv.FormatBool(r.TLS.DidResume))
 fmt.Fprint(w, "ok")
 }))
 server.Config.ConnContext = func(ctx context.Context, _ net.Conn) context.Context {
 return context.WithValue(ctx, connectionKey{}, connections.Add(1))
 }
 server.TLS = &tls.Config{MinVersion: tls.VersionTLS13, MaxVersion: tls.VersionTLS13}
 server.StartTLS()
 defer server.Close()
 base := server.Client().Transport.(*http.Transport).TLSClientConfig.Clone()
 base.MinVersion, base.MaxVersion = tls.VersionTLS13, tls.VersionTLS13
 check(!base.InsecureSkipVerify, "certificate verification must stay enabled")
 cached := base.Clone()
 cached.ClientSessionCache = tls.NewLRUClientSessionCache(4)
 transport := &http.Transport{TLSClientConfig: cached}
 defer transport.CloseIdleConnections()
 fresh := &http.Transport{TLSClientConfig: base.Clone()}
 defer fresh.CloseIdleConnections()
 probe := func(label string, transport *http.Transport, wantID int64, wantReuse, wantResume bool) {
 started := time.Now()
 var mu sync.Mutex
 var handshakeStarted time.Time
 var handshakeError error
 var observation struct {
 got, starts, done, first int
 reused bool
 tlsTime, ttfb time.Duration
 }
 trace := &httptrace.ClientTrace{
 GotConn: func(info httptrace.GotConnInfo) {
 mu.Lock()
 defer mu.Unlock()
 observation.got++
 observation.reused = info.Reused
 },
 TLSHandshakeStart: func() {
 mu.Lock()
 defer mu.Unlock()
 handshakeStarted = time.Now()
 observation.starts++
 },
 TLSHandshakeDone: func(_ tls.ConnectionState, err error) {
 mu.Lock()
 defer mu.Unlock()
 observation.done++
 observation.tlsTime = time.Since(handshakeStarted)
 handshakeError = err
 },
 GotFirstResponseByte: func() {
 mu.Lock()
 defer mu.Unlock()
 observation.first++
 observation.ttfb = time.Since(started)
 },
 }
 request, err := http.NewRequest(http.MethodGet, server.URL, nil)
 must(err)
 request = request.WithContext(httptrace.WithClientTrace(request.Context(), trace))
 client := &http.Client{Transport: transport, Timeout: 2 * time.Second}
 response, err := client.Do(request)
 must(err)
 body, err := io.ReadAll(response.Body)
 closeError := response.Body.Close()
 must(err)
 must(closeError)
 total := time.Since(started)
 check(response.StatusCode == 200 && string(body) == "ok", "wrong response")
 check(response.Proto == "HTTP/1.1", "fixture requires HTTP/1.1")
 check(response.TLS.Version == tls.VersionTLS13 && len(response.TLS.VerifiedChains) > 0, "verified TLS 1.3 required")
 id, err := strconv.ParseInt(response.Header.Get("X-Connection-ID"), 10, 64)
 must(err)
 check(id == wantID && response.TLS.DidResume == wantResume, "wrong connection or resumption")
 check(response.Header.Get("X-Resumed") == strconv.FormatBool(wantResume), "peers disagree on resumption")
 mu.Lock()
 observed, tlsError := observation, handshakeError
 mu.Unlock()
 must(tlsError)
 wantHandshakes := 1
 if wantReuse {
 wantHandshakes = 0
 }
 check(observed.got == 1 && observed.first == 1 && observed.reused == wantReuse, "wrong request trace")
 check(observed.starts == wantHandshakes && observed.done == wantHandshakes, "wrong handshake count")
 check(total >= observed.ttfb && observed.ttfb > 0, "invalid response timing")
 fmt.Printf("%s: conn=%d reused=%t handshakes=%d connection_resumed=%t tls_us=%d ttfb_us=%d total_us=%d\n",
 label, id, observed.reused, observed.done, response.TLS.DidResume,
 observed.tlsTime.Microseconds(), observed.ttfb.Microseconds(), total.Microseconds())
 }
 probe("cold", transport, 1, false, false)
 probe("reuse", transport, 1, true, false)
 transport.CloseIdleConnections()
 probe("resume", transport, 2, false, true)
 probe("no cache", fresh, 3, false, false)
 check(connections.Load() == 3, "four requests must use three TCP connections")
 fmt.Println("timings are observations, not a speedup or wire-RTT assertion")
 fmt.Println(runtime.Version())
}

The invariant results are:

Request	TCP ID	Reused	New handshakes	DidResume
cold	1	false	1	false
reuse	1	true	0	false
resume	2	false	1	true
no cache	3	false	1	false

The second request keeps connection one. Closing idle connections before the third forces another TCP connection without discarding the TLS cache, so it resumes. The fourth request uses a transport with no cached session and performs a full handshake. Both peers’ resumption flags agree, and four HTTP requests use exactly three accepted TCP connections.

The article’s four requests use TCP IDs 1, 1, 2, and 3. Reuse has no new TLS event; resume opens TCP 2 with one resumed handshake; no cache opens TCP 3 with one full handshake. DidResume is connection state. These categories do not measure an Internet speedup, packet RTT, or early data.

DidResume describes how that connection was established, not whether the current HTTP request triggered resumption. Reusing a connection originally established by resumption can still report true without another handshake. Interpret this connection-level flag alongside the request’s reuse and handshake events, rather than counting every true response as a new resumed connection.

TLS timing spans TLSHandshakeStart through TLSHandshakeDone. TTFB starts before the request and ends when the first response-header byte becomes available; total ends after reading and closing the body. The reused row’s zero TLS duration means no new handshake event was observed. It does not mean an extraordinarily fast handshake or TLS 0-RTT.

All assertions passed on macOS with Go 1.27.0. Bodies are consumed and closed, trace state is mutex-protected, and each request has a two-second timeout. Session state stays in memory; no ticket, private key, or traffic secret is printed. On resumed connections, verified-chain state belongs to the authenticated session, not evidence of a newly transmitted certificate.

The timing numbers intentionally have no speedup assertion and will vary. This local experiment does not count packets or measure wire RTT, DNS, HTTP/2 or HTTP/3, early data, fleet ticket rotation, handshake CPU in isolation, or production latency distributions. Use the trace categories to structure those later measurements without treating this fixture as their result.

Sources

RFC 8446: TLS 1.3, handshake flights, resumption, and early-data limits, checked 2026-09-09.
Go net/http/httptrace, request hooks, handshake events, timing boundaries, and concurrency, checked 2026-09-09.
Go net/http, transport reuse and response-body lifecycle, checked 2026-09-09.
Go crypto/tls, session caching and negotiated resumption state, checked 2026-09-09.
Go net/http/httptest, isolated TLS servers and trusted test clients, checked 2026-09-09.

Caddy automates HTTPS issuance and renewal

Thu, 21 Jan 2027 00:00:00 +0000

Caddy can obtain and renew managed certificates without an operator manually implementing ACME. That removes repetitive work, not the prerequisites for issuance or the need to notice failures. A valid certificate today proves neither that the next renewal can complete nor that every TLS hop uses the same certificate. Identify the names, validation route, storage, and termination boundary first.

Give automatic HTTPS a name

Automatic HTTPS activates when Caddy knows a qualifying hostname or address through its configuration, subject to documented exceptions and overrides. A hostname in a Caddyfile site address is one common trigger. The file_server directive serves files; it is not, by itself, a request for a public certificate for an unspecified domain.

The command-line distinction is concrete: bare caddy file-server defaults to port 80. Supplying --domain makes it attempt HTTPS for that hostname and changes the default listener to port 443. Neither command spelling proves that DNS, port forwarding, or certificate authorization is correct. Explicit HTTP configuration and manually loaded certificates also change automatic behavior.

Local development has a different trust boundary. Caddy can use its local certificate authority for internal names. Clients must trust that authority through an appropriate installation process; a certificate working on one machine does not make it publicly trusted. Do not distribute a private CA’s signing key to solve a client trust problem.

Match the challenge to the route

Caddy enables HTTP-01 and TLS-ALPN-01 by default. HTTP-01 validation enters through public port 80, while TLS-ALPN-01 uses port 443 and a special TLS handshake. Caddy can choose between available challenges. A failed HTTP challenge does not imply that DNS validation is the only possible alternative; inspect which methods and routes are actually available.

A proxy or CDN can interfere with either path, but its presence does not automatically make issuance impossible. HTTP challenge traffic may be forwarded correctly even when the CDN terminates ordinary HTTPS. DNS-01 proves control through a TXT record and does not require the requesting server to accept inbound validation traffic. It needs a supported provider integration and appropriately scoped DNS credentials.

When it breaks

Stale A or AAAA records, blocked ports, incorrect forwarding, or a changed CDN rule can break validation after the first issuance succeeded. Check both address families and the actual failed challenge in logs. Repeatedly deleting storage and retrying is a poor diagnostic: it removes reusable certificate state and can increase unnecessary issuance attempts.

Persist Caddy’s data storage across replacement instances and protect it because it contains sensitive key material. Multiple instances need a storage arrangement with the coordination semantics Caddy expects. A directory merely bearing the same name on several machines is not shared storage. Test recovery of that configuration without exposing keys in logs or source control.

Automation can fail while the existing certificate still works. Monitor renewal errors and the expiry of the certificate clients actually receive, leaving enough time for response. A successful origin renewal does not prove the CDN’s public certificate changed. Likewise, CDN TLS does not remove the need to secure and validate a separate HTTPS origin connection.

Use a staging issuer for issuance experiments, and keep its untrusted test certificates out of production. DNS credential rotation needs a controlled validation check. Choose alert lead time around response requirements and certificate lifetime; a fixed thirty-day arithmetic example is not a specification of Caddy’s renewal schedule.

Caddy certificate lifecycle: mechanism and evidence boundaries.

Check it quickly

Save this as expiry_alert.py and run python3 expiry_alert.py. Use assertions enabled, without -O or PYTHONOPTIMIZE. It needs only the standard library and uses a fixed UTC observation time. The synthetic thirty-day threshold belongs to this operator alert, not to Caddy. No domain, certificate authority, network listener, key, or system trust setting is touched.

from datetime import datetime, timedelta, timezone

# An operator-chosen alert threshold, not Caddy's renewal scheduler.
ALERT_BEFORE = timedelta(days=30)
NOW = datetime(2026, 10, 15, 12, tzinfo=timezone.utc)


def expiry_alert(not_after, now):
 for value in (not_after, now):
 if value.tzinfo is None or value.utcoffset() is None:
 raise ValueError("timezone-aware timestamps required")
 remaining = not_after - now
 if remaining <= timedelta(0):
 return "expired"
 if remaining <= ALERT_BEFORE:
 return "warning"
 return "ok"


for name, days, expected in [
 ("fresh", 80, "ok"), ("due", 20, "warning"),
 ("boundary", 30, "warning"), ("expired", -1, "expired"),
]:
 not_after = NOW + timedelta(days=days)
 actual = expiry_alert(not_after, NOW)
 assert actual == expected
 print(f"{name}: remaining={days}d alert={actual}")
assert expiry_alert(NOW, NOW) == "expired"
try:
 expiry_alert(NOW.replace(tzinfo=None), NOW)
except ValueError:
 print("naive timestamp rejected")
else:
 raise AssertionError("missing timezone accepted")
print("PASS: expiry alert boundaries; no certificate issuance tested")

The four printed cases are ok, warning, warning, and expired. Exactly thirty days is included in the warning interval; expiry itself is classified separately. The negative case supplies a naive expiry timestamp; the function also checks the observation time, but that separate branch is not exercised. These assertions verify the alert’s declared boundaries rather than relying on today’s date or a particular certificate lifetime.

Retained exact records cover the unchanged arithmetic fixture; this source review did not rerun it. The exercise does not run Caddy, issue a certificate, or observe renewal. For deployment evidence, verify the served certificate and configured challenge route, then observe successful renewal using the intended persistent storage. Keep that operational evidence separate from this small, repeatable date-arithmetic check.

Sources

Python assert statement, optimization omits assertions and any calls inside them, checked 2026-10-18.
Caddy automatic HTTPS, activation, local trust, challenge selection, and storage, checked 2026-10-15.
Caddy file-server command, default listener and the domain flag, checked 2026-10-15.
Let’s Encrypt challenge types, validation ports, DNS automation, and scoped credentials, checked 2026-10-15.
Let’s Encrypt rate limits, staging for experiments and issuance failures, checked 2026-10-15.

Checking HTTPS beyond the lock icon

Mon, 09 Nov 2026 00:00:00 +0000

HTTPS protects a connection and authenticates its peer according to the client’s trust policy. It does not certify the site’s intentions, correctness, or availability. A security indicator is therefore neither just an encryption label nor a complete health report. A useful check separately evaluates the TLS connection, the HTTP response, and the service’s expected behavior.

Ask several concrete questions

Start with the destination and identity. Connect to the intended endpoint while verifying the intended hostname against certificate subject alternative names and the accepted trust chain. A correct IP address or a printed certificate subject is not enough. Disabling verification to make a probe pass removes the evidence that the identity check was supposed to provide.

Then inspect time validity and the negotiated protocol. A future leaf expiry alone does not establish a usable chain, and a successful TLS negotiation shows only the selected version and suite for that client. It does not enumerate every configuration the server might accept. Test explicit acceptance and rejection policies separately after relevant configuration or library changes.

Finally, define application success. HTTP status, expected content, redirects, and relevant dependencies answer different questions. A static site can present a valid certificate while returning a missing page, stale release, or upstream error. TLS is not the whole conversation even when the application serves only files.

When it breaks

An HTTP library may return a perfectly readable response for HTTP 503 without reporting a transport error. A checker that tests only err == nil will then call an unavailable service healthy. Similarly, a generic HTTP 200 can be a different virtual host, login page, or cached error document. Validate a stable service-specific response contract.

Automatic redirects can hide which endpoint was actually checked. An initial HTTPS response may point to HTTP or an unexpected destination; a final 200 alone loses that distinction. Inspect the redirect chain under an explicit policy, and do not forward credentials to new destinations merely to complete a probe.

The termination boundary matters too. A CDN’s verified certificate authenticates the client-to-CDN hop, not every subsequent hop to the origin. Monitor the public route and the relevant upstream path independently. Record the endpoint and observation time, distinguish certificate failures from HTTP failures, and keep credentials and private request data out of diagnostic output.

Check it quickly

Save this as health_probe.go and run go run health_probe.go with Go 1.23 or newer. A local TLS 1.3 fixture provides four application responses, and a separate plaintext server stands in for a redirect destination. The client trusts only the fixture’s server certificate through httptest’s supplied configuration. No public endpoint or global trust store is changed.

package main

import (
 "crypto/tls"
 "crypto/x509"
 "errors"
 "fmt"
 "io"
 "log"
 "net/http"
 "net/http/httptest"
 "runtime"
 "sync/atomic"
 "time"
)

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 var handled, redirectHits atomic.Int64
 target := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 redirectHits.Add(1)
 fmt.Fprint(w, "not followed")
 }))
 defer target.Close()
 server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 handled.Add(1)
 switch r.URL.Path {
 case "/ready":
 fmt.Fprint(w, "ready")
 case "/wrong":
 fmt.Fprint(w, "different service")
 case "/down":
 http.Error(w, "unavailable", http.StatusServiceUnavailable)
 case "/redirect":
 http.Redirect(w, r, target.URL+"/landing", http.StatusFound)
 default:
 http.NotFound(w, r)
 }
 }))
 server.Config.ErrorLog = log.New(io.Discard, "", 0)
 server.TLS = &tls.Config{MinVersion: tls.VersionTLS13, MaxVersion: tls.VersionTLS13}
 server.StartTLS()
 defer server.Close()
 probe := func(route, name string) (int, bool, error) {
 config := server.Client().Transport.(*http.Transport).TLSClientConfig.Clone()
 config.MinVersion = tls.VersionTLS13
 config.ServerName = name
 check(!config.InsecureSkipVerify, "certificate verification must stay enabled")
 transport := &http.Transport{TLSClientConfig: config, DisableKeepAlives: true}
 defer transport.CloseIdleConnections()
 client := &http.Client{
 Transport: transport, Timeout: 2 * time.Second,
 CheckRedirect: func(*http.Request, []*http.Request) error { return http.ErrUseLastResponse },
 }
 response, err := client.Get(server.URL + route)
 if err != nil {
 return 0, false, err
 }
 defer response.Body.Close()
 body, err := io.ReadAll(response.Body)
 must(err)
 check(response.TLS.Version == tls.VersionTLS13 && len(response.TLS.VerifiedChains) > 0, "verified TLS 1.3 required")
 if response.StatusCode == http.StatusFound {
 check(response.Header.Get("Location") == target.URL+"/landing", "wrong redirect target")
 }
 return response.StatusCode, response.StatusCode == http.StatusOK && string(body) == "ready", nil
 }
 for _, test := range []struct {
 path string
 status int
 healthy bool
 }{
 {"/ready", 200, true}, {"/wrong", 200, false},
 {"/down", 503, false}, {"/redirect", 302, false},
 } {
 status, healthy, err := probe(test.path, "")
 must(err)
 check(status == test.status && healthy == test.healthy, "wrong health classification")
 fmt.Println(test.path, "verified TLS; HTTP", status, "healthy:", healthy)
 }
 _, _, err := probe("/ready", "wrong.example.test")
 var nameError x509.HostnameError
 check(errors.As(err, &nameError), "wrong TLS name must fail")
 check(handled.Load() == 4, "wrong name must not reach HTTP")
 status, healthy, err := probe("/ready", "")
 must(err)
 check(status == 200 && healthy && handled.Load() == 5, "trusted health probe must recover")
 check(redirectHits.Load() == 0, "HTTP redirect destination must remain unvisited")
 fmt.Println("wrong name rejected before HTTP; redirect not followed; healthy request succeeds again")
 fmt.Println(runtime.Version())
}

All four initial requests have verified TLS, but only /ready is healthy under this fixture’s contract: HTTP 200 with the exact body ready. /wrong also returns 200, yet contains a different service response. /down returns 503. Neither is a successful health result, even though the HTTP exchange itself succeeds.

The /redirect response returns 302 with a plaintext Location. ErrUseLastResponse exposes that response without following it, and the target’s counter stays zero. This probe deliberately declines all automatic redirects; it is not a general redirect-chain auditor. A real monitor should define approved destinations and transport requirements before following a chain.

All four initial responses in the article have verified TLS 1.3. Only HTTP 200 with exact body ready is healthy under this fixture’s contract. The 302 response is inspected without following its HTTP Location; the target receives no request. Public edges, upstream hops, and revocation are outside this local test.

An intentionally wrong TLS name produces HostnameError before another HTTP handler entry. A subsequent trusted /ready request succeeds, leaving five application requests total. Each attempt uses a separate transport, retains ordinary certificate validation, and has a two-second client timeout. That isolation makes the negative identity test independent of an already authenticated connection.

That timeout covers the entire client request, including connection setup and body reading, not just the TLS handshake. It remains active after response headers arrive. This fixture does not inject a timeout; setting a deadline alone is not a timeout-behavior test.

All assertions passed on macOS with Go 1.27.0. This distinguishes transport identity, protocol success, and application health using actual local connections. It does not enumerate public cipher suites, inspect every edge, validate revocation or browser policy, check upstream hops, or run a production workload. The exact ready token is a test contract, not a universal definition of healthy service.

Sources

RFC 9110: HTTP semantics, response status and redirection semantics, checked 2026-09-09.
Go net/http, non-2xx responses, redirect control, and client timeouts, checked 2026-09-09.
Go crypto/tls, peer validation and negotiated connection state, checked 2026-09-09.
Go crypto/x509, hostname verification and certificate-chain checks, checked 2026-09-09.

SNI selects a TLS certificate for the requested hostname

Sun, 08 Nov 2026 00:00:00 +0000

Server Name Indication gives a TLS server a hostname while it is choosing handshake parameters and a certificate. In the certificate-based, no-early-data path discussed here, this happens before ordinary HTTP bytes, not before any bytes cross the network. SNI is a selection hint; the client must still verify the selected identity.

One address, separate decisions

The client places server_name in ClientHello. A server hosting multiple names can use it to choose a certificate or security configuration. TLS 1.3 encrypts its certificate message after ServerHello, so describing the whole selection and certificate exchange as happening before encryption is inaccurate.

A DNS hostname in SNI is not the destination IP, and supplying it does not require the test name to resolve through DNS. RFC 6066 excludes literal IP addresses from its HostName field and treats DNS names case-insensitively. Clients connecting by IP may omit SNI and verify an IP identity instead.

Multiple sites do not necessarily need separate certificates. One certificate can cover multiple subject alternative names, and a server without SNI can choose a default certificate. Whether the client accepts that certificate depends on its expected name and trust policy. SNI enables selection; it does not create trust or prove ownership of the requested hostname.

When it breaks

A client can reach the correct IP yet receive a default certificate for another name. Disabling hostname verification would hide that routing error. Check the connection address, intended TLS name, selected certificate’s SANs, trust chain, and expiry independently.

HTTP Host or an HTTP/2 authority belongs to the application layer. Changing it does not redo the TLS handshake or replace its certificate. ALPN separately negotiates an application protocol such as HTTP/2; it does not verify a hostname or authorize a tenant. Certificate selection, identity verification, protocol negotiation, and application routing need separate checks.

Unknown SNI may lead to handshake rejection or a default certificate, depending on server policy; absence of SNI does not universally mean failure. Without ECH, the ordinary ClientHello exposes SNI on the network. TLS 1.3 alone does not hide it. ECH requires additional deployment support and does not conceal every traffic characteristic.

SNI certificate selection: mechanism and evidence boundaries.

Check it quickly

Save this as sni_probe.go and run go run sni_probe.go with Go 1.23 or newer. It generates a short-lived test CA and two leaf certificates entirely in memory. Only a local client trusts that CA. All requests connect to one loopback IP; ServerName supplies the intended TLS name without requiring public DNS. Sessions and HTTP connections are not reused.

The CA and leaf certificates expire after one hour. Their limited lifetime is a fixture choice, not a production renewal strategy. Creating a certificate does not make other clients trust it; the explicit root pool is what establishes trust for these requests.

package main

import (
 "crypto/ed25519"
 "crypto/rand"
 "crypto/tls"
 "crypto/x509"
 "errors"
 "fmt"
 "io"
 "log"
 "math/big"
 "net/http"
 "net/http/httptest"
 "runtime"
 "strings"
 "sync/atomic"
 "time"
)

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func leaf(name string, serial int64, ca *x509.Certificate, signer ed25519.PrivateKey) tls.Certificate {
 public, private, err := ed25519.GenerateKey(rand.Reader)
 must(err)
 now := time.Now()
 template := &x509.Certificate{
 SerialNumber: big.NewInt(serial), DNSNames: []string{name},
 NotBefore: now.Add(-time.Minute), NotAfter: now.Add(time.Hour),
 KeyUsage: x509.KeyUsageDigitalSignature,
 ExtKeyUsage: []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
 }
 der, err := x509.CreateCertificate(rand.Reader, template, ca, public, signer)
 must(err)
 certificate, err := x509.ParseCertificate(der)
 must(err)
 return tls.Certificate{Certificate: [][]byte{der}, PrivateKey: private, Leaf: certificate}
}

func main() {
 public, private, err := ed25519.GenerateKey(rand.Reader)
 must(err)
 now := time.Now()
 template := &x509.Certificate{
 SerialNumber: big.NewInt(1), IsCA: true, BasicConstraintsValid: true,
 NotBefore: now.Add(-time.Minute), NotAfter: now.Add(time.Hour),
 KeyUsage: x509.KeyUsageCertSign,
 }
 der, err := x509.CreateCertificate(rand.Reader, template, template, public, private)
 must(err)
 ca, err := x509.ParseCertificate(der)
 must(err)
 roots := x509.NewCertPool()
 roots.AddCert(ca)
 alpha := leaf("alpha.example.test", 2, ca, private)
 beta := leaf("beta.example.test", 3, ca, private)
 certificates := map[string]*tls.Certificate{
 "alpha.example.test": &alpha, "beta.example.test": &beta,
 }

 var handled, rejected atomic.Int64
 server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 handled.Add(1)
 fmt.Fprintf(w, "%s|%s", r.TLS.ServerName, r.Host)
 }))
 server.Config.ErrorLog = log.New(io.Discard, "", 0)
 server.TLS = &tls.Config{
 MinVersion: tls.VersionTLS13, MaxVersion: tls.VersionTLS13,
 Certificates: []tls.Certificate{alpha}, SessionTicketsDisabled: true,
 GetCertificate: func(hello *tls.ClientHelloInfo) (*tls.Certificate, error) {
 certificate, ok := certificates[strings.ToLower(hello.ServerName)]
 if !ok {
 rejected.Add(1)
 return nil, fmt.Errorf("unknown fixture SNI")
 }
 return certificate, nil
 },
 }
 server.StartTLS()
 defer server.Close()

 request := func(name, host string) (string, error) {
 config := &tls.Config{RootCAs: roots, ServerName: name, MinVersion: tls.VersionTLS13}
 transport := &http.Transport{TLSClientConfig: config, DisableKeepAlives: true}
 defer transport.CloseIdleConnections()
 client := &http.Client{Transport: transport, Timeout: 2 * time.Second}
 request, err := http.NewRequest(http.MethodGet, server.URL, nil)
 must(err)
 request.Host = host
 response, err := client.Do(request)
 if err != nil {
 return "", err
 }
 defer response.Body.Close()
 body, err := io.ReadAll(response.Body)
 if err != nil {
 return "", err
 }
 check(response.StatusCode == 200, "unexpected HTTP status")
 check(response.TLS.Version == tls.VersionTLS13 && len(response.TLS.VerifiedChains) > 0, "verified TLS 1.3 required")
 check(string(body) == name+"|"+host, "handler must observe separate SNI and Host")
 certificate := response.TLS.PeerCertificates[0]
 must(certificate.VerifyHostname(name))
 return certificate.DNSNames[0], nil
 }

 for _, name := range []string{"alpha.example.test", "beta.example.test"} {
 selected, err := request(name, name)
 must(err)
 check(selected == name, "SNI must select its matching certificate")
 fmt.Println("SNI", name, "selected", selected)
 }
 selected, err := request("ALPHA.EXAMPLE.TEST", "alpha.example.test")
 must(err)
 check(selected == "alpha.example.test", "DNS name selection must be case-insensitive")
 selected, err = request("alpha.example.test", "beta.example.test")
 must(err)
 check(selected == "alpha.example.test", "HTTP Host must not change the TLS certificate")
 _, err = request("missing.example.test", "missing.example.test")
 check(err != nil && rejected.Load() == 1, "unknown SNI must be rejected by fixture policy")
 _, err = request("", "alpha.example.test")
 var nameError x509.HostnameError
 check(errors.As(err, &nameError), "without DNS SNI, default certificate must fail IP identity")
 check(handled.Load() == 4, "only four verified requests may reach the handler")
 fmt.Println("uppercase name selects alpha; Host override keeps alpha; unknown SNI and IP-name mismatch rejected")
 fmt.Println(runtime.Version())
}

Alpha and beta select their respective certificates, and an uppercase alpha name still selects alpha. The client performs normal chain and hostname checks; the example additionally inspects the selected certificate. Four verified requests reach the echo handler, including the deliberate request with alpha SNI but beta Host. That request still authenticates alpha and demonstrates independent fields, not permission to serve another tenant.

An unknown SNI is rejected by this fixture’s exact-name policy. With ServerName empty, the IP URL leads to no DNS SNI; the configured default alpha certificate cannot authenticate that IP, so hostname verification fails even though Host says alpha. Neither negative case reaches HTTP. The echo handler intentionally exposes the two fields for inspection and is not a production virtual-host router.

Retained evidence establishes compilation on Go 1.24.4, with handshake execution blocked; the earlier macOS Go 1.27.0 success statement lacks a matching retained run here. No TLS exercise ran in this source review. Keys remain fixture-local by inspection. ECH, ALPN negotiation, wildcard or internationalized names, HTTP/2 coalescing, resumption and real edges need separate tests.

Sources

RFC 6066: TLS Extensions, server_name, hostname syntax, and server selection, checked 2026-09-09.
RFC 8446: TLS 1.3, encrypted handshake messages after ServerHello, checked 2026-09-09.
Go crypto/tls, ServerName, GetCertificate, and explicit ECH configuration, checked 2026-09-09.
Go crypto/x509, test certificate creation and SAN-based hostname verification, checked 2026-09-09.
Go net/http/httptest, temporary loopback TLS servers, checked 2026-09-09.
RFC 7301: ALPN, application-protocol selection distinct from server-name indication, checked 2026-10-18.

HSTS makes the browser remember HTTPS

Thu, 08 Oct 2026 00:00:00 +0000

HTTP Strict Transport Security tells a supporting client to use HTTPS for a remembered hostname. It can eliminate the insecure HTTP request before a redirect, but only when the client already knows the policy, through an earlier authenticated response or a supported preload mechanism. Merely adding a header cannot retroactively protect an unknown client’s first HTTP visit.

The client remembers a host

A valid Strict-Transport-Security header received over error-free HTTPS establishes or refreshes the policy. max-age is a duration in seconds measured from receipt. A header sent over plaintext HTTP cannot establish this trust, and omitting the header later does not erase an unexpired entry. Each client maintains its own state; browsers do not share one universal cache.

The scope is a DNS hostname, not an HTTP origin or an individual port. includeSubDomains extends coverage downward, not to a parent or sibling name. For an upgraded URL, explicit port 80 becomes 443, while other explicit ports remain unchanged. An HTTP-only service on an alternate port can therefore break after policy is learned.

The policy changes the client’s URL handling; it does not turn a plaintext listener into a TLS listener. The upgraded destination must already support HTTPS. The fixture below deliberately sends HSTS over HTTP as a negative test, not deployment advice. Neither server redirects: reaching the TLS handler from an HTTP URL demonstrates client-side upgrading, not a successful redirect chain.

This is an upgrade rule, not a certificate bypass. Supporting browsers must still validate HTTPS and do not offer their usual click-through escape for an HSTS certificate error. HSTS cannot fix an expired certificate, restore an unavailable TLS endpoint, or prove that the application behind an authenticated connection is trustworthy.

When it breaks

A long lifetime or includeSubDomains can reach forgotten services, delegated subdomains, and internal hostnames. Inventory those dependencies before expanding coverage. Begin with a deliberately short policy, validate real entry points, and ensure certificate renewal works. Scanner recommendations are not evidence that every covered host can honor the commitment.

Recovery requires precision. An authenticated max-age=0 response removes that host’s dynamic policy for clients receiving it; it does not clear independently stored child policies or immediately update offline clients. Removing the header alone is insufficient. Browser preload distribution and removal are separate processes, not instant consequences of toggling a response field.

Testing only header presence misses client behavior. Use an isolated state store and verify both the initial visit and later HTTP URLs. Keep such a test away from personal browser profiles, and never disable certificate verification just to obtain a reassuring upgrade result. Different clients and preload configurations need their own checks.

A host policy changes the next request. Static illustration of the source and its limits. Reported fixture outcomes were not rerun for this graphic.

Check it quickly

Save this as hsts_probe.go and run go run hsts_probe.go with Go 1.23 or newer and an HSTS-enabled curl supporting --hsts. The program creates two loopback servers and a temporary P-256 CA. It writes only the public CA certificate and curl’s cache to a private temporary directory, removes that directory on exit, and keeps private keys in memory.

package main

import (
 "context"
 "crypto/ecdsa"
 "crypto/elliptic"
 "crypto/rand"
 "crypto/tls"
 "crypto/x509"
 "crypto/x509/pkix"
 "encoding/pem"
 "errors"
 "fmt"
 "io"
 "log"
 "math/big"
 "net/http"
 "net/http/httptest"
 "net/url"
 "os"
 "os/exec"
 "path/filepath"
 "runtime"
 "strings"
 "sync/atomic"
 "time"
)

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func issue(template, parent *x509.Certificate, public any, signer *ecdsa.PrivateKey) *x509.Certificate {
 der, err := x509.CreateCertificate(rand.Reader, template, parent, public, signer)
 must(err)
 certificate, err := x509.ParseCertificate(der)
 must(err)
 return certificate
}

func main() {
 curl, err := exec.LookPath("curl")
 must(err)
 versionCommand := exec.Command(curl, "--disable", "--version")
 versionCommand.Env = append(os.Environ(), "SSLKEYLOGFILE=")
 version, err := versionCommand.Output()
 must(err)
 check(strings.Contains(string(version), "HSTS"), "curl must support HSTS")
 caKey, err := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)
 must(err)
 leafKey, err := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)
 must(err)
 now := time.Now()
 template := &x509.Certificate{
 SerialNumber: big.NewInt(1), Subject: pkix.Name{CommonName: "HSTS fixture CA"},
 NotBefore: now.Add(-time.Minute), NotAfter: now.Add(time.Hour),
 IsCA: true, BasicConstraintsValid: true, KeyUsage: x509.KeyUsageCertSign,
 }
 ca := issue(template, template, caKey.Public(), caKey)
 host, child := "hsts.example.test", "child.hsts.example.test"
 leaf := issue(&x509.Certificate{
 SerialNumber: big.NewInt(2), DNSNames: []string{host, child},
 NotBefore: now.Add(-time.Minute), NotAfter: now.Add(time.Hour),
 KeyUsage: x509.KeyUsageDigitalSignature, ExtKeyUsage: []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
 }, ca, leafKey.Public(), caKey)
 folder, err := os.MkdirTemp("", "hsts-probe-")
 must(err)
 defer func() { must(os.RemoveAll(folder)) }()
 caFile, cacheFile := filepath.Join(folder, "ca.pem"), filepath.Join(folder, "hsts.txt")
 must(os.WriteFile(caFile, pem.EncodeToMemory(&pem.Block{Type: "CERTIFICATE", Bytes: ca.Raw}), 0600))

 var plainCount, secureCount atomic.Int64
 plain := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 plainCount.Add(1)
 if r.URL.Path == "/learn" {
 w.Header().Set("Strict-Transport-Security", "max-age=3600; includeSubDomains")
 }
 fmt.Fprint(w, "plain")
 }))
 defer plain.Close()
 secure := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 secureCount.Add(1)
 check(r.TLS != nil, "secure handler requires TLS")
 switch r.URL.Path {
 case "/learn":
 w.Header().Set("Strict-Transport-Security", "max-age=3600; includeSubDomains")
 case "/clear":
 w.Header().Set("Strict-Transport-Security", "max-age=0")
 }
 fmt.Fprint(w, "secure")
 }))
 secure.Config.ErrorLog = log.New(io.Discard, "", 0)
 secure.TLS = &tls.Config{
 MinVersion: tls.VersionTLS12,
 Certificates: []tls.Certificate{{Certificate: [][]byte{leaf.Raw}, PrivateKey: leafKey, Leaf: leaf}},
 }
 secure.StartTLS()
 defer secure.Close()
 plainURL, err := url.Parse(plain.URL)
 must(err)
 secureURL, err := url.Parse(secure.URL)
 must(err)
 check(plainURL.Hostname() == "127.0.0.1" && secureURL.Hostname() == "127.0.0.1", "IPv4 loopback fixtures required")
 request := func(scheme, name, port, route string, trust bool) (string, error) {
 ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
 defer cancel()
 args := []string{
 "--disable", "--noproxy", "*", "--silent", "--show-error", "--fail",
 "--max-time", "3", "--hsts", cacheFile, "--resolve", name + ":" + port + ":127.0.0.1",
 }
 if trust {
 args = append(args, "--cacert", caFile)
 }
 args = append(args, scheme+"://"+name+":"+port+route)
 command := exec.CommandContext(ctx, curl, args...)
 command.Env = append(os.Environ(), "SSLKEYLOGFILE=")
 output, err := command.CombinedOutput()
 return string(output), err
 }
 _, err = request("https", host, secureURL.Port(), "/learn", false)
 var exit *exec.ExitError
 check(errors.As(err, &exit) && exit.ExitCode() == 60, "untrusted HTTPS must fail certificate verification")
 for _, test := range []struct {
 label, scheme, name, port, route, expected string
 }{
 {"HTTP cannot seed HSTS", "http", host, plainURL.Port(), "/learn", "plain"},
 {"still HTTP", "http", host, plainURL.Port(), "/probe", "plain"},
 {"trusted HTTPS seeds HSTS", "https", host, secureURL.Port(), "/learn", "secure"},
 {"HTTP URL upgrades", "http", host, secureURL.Port(), "/probe", "secure"},
 {"child inherits upgrade", "http", child, secureURL.Port(), "/probe", "secure"},
 {"authenticated removal", "https", host, secureURL.Port(), "/clear", "secure"},
 {"parent HTTP restored", "http", host, plainURL.Port(), "/probe", "plain"},
 {"child HTTP restored", "http", child, plainURL.Port(), "/probe", "plain"},
 } {
 output, err := request(test.scheme, test.name, test.port, test.route, true)
 check(err == nil, fmt.Sprintf("curl failed: %v: %s", err, output))
 check(output == test.expected, "wrong transport result")
 fmt.Println(test.label, "->", output)
 }
 check(plainCount.Load() == 4 && secureCount.Load() == 4, "expected four plaintext and four authenticated TLS requests")
 fmt.Println(strings.SplitN(string(version), "\n", 2)[0])
 fmt.Println(runtime.Version())
}

All test hostnames resolve explicitly to loopback through --resolve; no public DNS or external site is used. --disable is curl’s first argument, so personal curl configuration is not loaded. --noproxy avoids configured proxies. Every curl child clears SSLKEYLOGFILE to disable inherited TLS key logging. Each transfer has a three-second limit and an outer five-second process deadline. The test CA is supplied per request, never installed globally.

The first HTTPS attempt lacks that CA and must fail with curl certificate-verification exit code 60. Plain HTTP then remains plain even after receiving an HSTS header. A trusted HTTPS response seeds the shared test cache; subsequent HTTP URLs for both the parent and child reach the TLS handler.

A trusted max-age=0 response removes the parent entry. Parent and child HTTP requests then reach the plaintext handler because this fixture never gives the child an independent policy. Exactly four plaintext and four authenticated TLS requests reach handlers; the failed certificate attempt reaches neither application handler. The nonstandard TLS port is preserved during upgrade.

All assertions passed on macOS with Go 1.27.0 and curl 8.7.1. This is real curl HSTS behavior, not a browser-policy acceptance test. It does not exercise browser preload lists, separate child policies, expiry waiting, port-80 mapping, certificate-error UI, or production rollout. The temporary cache intentionally disappears afterward; no persistent user HSTS setting is changed.

Sources

RFC 6797: HTTP Strict Transport Security, authenticated policy processing, host scope, and port mapping, checked 2026-09-09.
MDN: Strict-Transport-Security, subdomain policy, removal, and preload boundaries, checked 2026-09-09.
curl manual, --hsts, explicit name resolution, CA selection, and configuration isolation, checked 2026-09-09.

Set a TLS version floor and test its boundary

Wed, 23 Sep 2026 00:00:00 +0000

A TLS version policy defines which handshakes an endpoint accepts. Prefer an explicit minimum over assuming that a library’s changing defaults match your requirements. A maximum is a separate constraint: freezing it unnecessarily can prevent adoption of a newer supported protocol. Neither setting replaces certificate verification, suitable algorithms, or timely security updates.

A floor is not a ceiling

RFC 8996 deprecates TLS 1.0 and 1.1. RFC 9325 also rejects SSLv2 and SSLv3, recommends supporting TLS 1.3 and preferring it when implemented, and gives security requirements for retained TLS 1.2 support. A service with a known client population may choose TLS 1.3 only after evaluating interoperability; the existence of a stricter option does not make every TLS 1.2 connection insecure.

When both endpoints support TLS 1.3, merely allowing TLS 1.2 does not mean an attacker can freely force the weakest version. TLS includes authenticated negotiation and specific downgrade protections. However, a real old-only client can legitimately select an allowed older version, and unsafe retry behavior can undermine policy. Enforce the floor on each new connection instead of accepting success at any version.

Version numbers in a capture also need context. TLS 1.3 uses a legacy hello version value of 0x0303 for compatibility and negotiates its actual version through supported_versions. That legacy value alone is not evidence that the connection used TLS 1.2. Prefer the library’s negotiated ConnectionState when available.

When it breaks

A browser succeeding proves only one accepted path. It does not prove that TLS 1.0 is rejected, that a required TLS 1.2 client still works, or that all edge listeners enforce the same floor. Test accepted and rejected boundaries independently, including the correct hostname and trust roots.

A load balancer can terminate TLS before the request reaches the configured application. Client-to-edge and edge-to-origin policies are separate, as are another port, address family, or listener. Test the endpoint customers actually reach. Reloaded configuration is evidence of intent; observed negotiation is evidence of behavior.

Go’s TLS Config must not be modified after being passed to a TLS function. This example constructs configurations before starting servers. Apply a deployment’s supported reload procedure and test new connections; do not mutate a shared configuration while handshakes are using it.

Version overlap is necessary but insufficient. Unsupported signature algorithms, key-exchange groups, certificate names, or trust chains can still cause failure. Preserve the actual error, and do not label every handshake rejection a version mismatch. Avoid silently weakening the floor after a timeout; that can convert a transient network failure into a lasting security change.

TLS version boundaries: mechanism and evidence boundaries.

Check it quickly

Save this as version_probe.go and run go run version_probe.go with Go 1.23 or newer. Two temporary loopback HTTPS servers share the same test logic but enforce different minimums. The fixture’s certificate is trusted only by its local test client. Requests use fresh transports, keep certificate verification enabled, and have two-second limits.

Server range	Client range	Expected result
1.2–1.3	1.2–1.3	TLS 1.3
1.2–1.3	1.2 only	TLS 1.2
1.2–1.3	1.1 only	Reject
1.3 only	1.2 only	Reject
1.3 only	1.2–1.3	TLS 1.3

package main

import (
 "crypto/tls"
 "fmt"
 "io"
 "log"
 "net/http"
 "net/http/httptest"
 "runtime"
 "sync/atomic"
 "time"
)

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func probe(server *httptest.Server, minimum, maximum uint16) (uint16, error) {
 config := server.Client().Transport.(*http.Transport).TLSClientConfig.Clone()
 config.MinVersion, config.MaxVersion = minimum, maximum
 check(!config.InsecureSkipVerify, "certificate verification must stay enabled")
 transport := &http.Transport{TLSClientConfig: config, DisableKeepAlives: true}
 defer transport.CloseIdleConnections()
 client := &http.Client{Transport: transport, Timeout: 2 * time.Second}
 response, err := client.Get(server.URL)
 if err != nil {
 return 0, err
 }
 defer response.Body.Close()
 body, err := io.ReadAll(response.Body)
 if err != nil {
 return 0, err
 }
 check(response.StatusCode == 200 && string(body) == "ok\n", "unexpected HTTP reply")
 check(response.TLS.HandshakeComplete && len(response.TLS.VerifiedChains) > 0, "verified handshake required")
 return response.TLS.Version, nil
}

func main() {
 var handled atomic.Int64
 start := func(minimum uint16) *httptest.Server {
 server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 handled.Add(1)
 fmt.Fprintln(w, "ok")
 }))
 server.Config.ErrorLog = log.New(io.Discard, "", 0)
 server.TLS = &tls.Config{MinVersion: minimum, MaxVersion: tls.VersionTLS13}
 server.StartTLS()
 return server
 }
 compatible := start(tls.VersionTLS12)
 defer compatible.Close()
 strict := start(tls.VersionTLS13)
 defer strict.Close()

 version, err := probe(compatible, tls.VersionTLS12, tls.VersionTLS13)
 check(err == nil && version == tls.VersionTLS13, "modern peers must select TLS 1.3")
 fmt.Println("server 1.2-1.3, client 1.2-1.3:", tls.VersionName(version))

 version, err = probe(compatible, tls.VersionTLS12, tls.VersionTLS12)
 check(err == nil && version == tls.VersionTLS12, "TLS 1.2-only client must remain compatible")
 fmt.Println("server 1.2-1.3, client 1.2 only:", tls.VersionName(version))

 _, err = probe(compatible, tls.VersionTLS11, tls.VersionTLS11)
 check(err != nil, "client below TLS 1.2 floor must fail")
 _, err = probe(strict, tls.VersionTLS12, tls.VersionTLS12)
 check(err != nil, "client below TLS 1.3 floor must fail")
 check(handled.Load() == 2, "rejected handshakes must not reach HTTP")

 version, err = probe(strict, tls.VersionTLS12, tls.VersionTLS13)
 check(err == nil && version == tls.VersionTLS13, "strict server must still accept TLS 1.3")
 check(handled.Load() == 3, "exactly three HTTP requests must succeed")
 fmt.Println("both below-floor clients rejected; strict server still accepts TLS 1.3")
 fmt.Println(runtime.Version())
}

The program asserts the matrix and handler counts: two successful requests before the negative cases, three after the final modern request. However, each negative assertion accepts any error and discards its details; it does not independently establish the rejection cause. The earlier macOS Go 1.27.0 success claim lacks a matching retained run here, and this review did not execute TLS. Fixed upper bounds make the comparison explicit, not a production ceiling recommendation.

The fixture is designed to use negotiated connections, rather than configuration-file inspection. The test does not execute SSLv2, SSLv3, TLS 1.0, active downgrade attacks, or a production proxy rollout. Before raising a live floor, inventory required clients, test the intended listener configuration in staging, and monitor handshake failures during deployment. If compatibility fails, revisit that deliberate policy decision rather than disabling identity checks.

Sources

RFC 8996: Deprecating TLS 1.0 and TLS 1.1, obsolete-version rejection, checked 2026-09-09.
RFC 9325: Secure Use of TLS and DTLS, version policy, preference, and interoperability guidance, checked 2026-09-09.
RFC 8446: TLS 1.3, supported_versions and downgrade protection, checked 2026-09-09.
Go crypto/tls, MinVersion, MaxVersion, and negotiated state, checked 2026-09-09.
Go net/http/httptest, local TLS fixtures and trusted test clients, checked 2026-09-09.

Audit the trust of a public edge

Thu, 06 Aug 2026 00:00:00 +0000

The web-security series treats settings as contracts with scope and failure modes. This walkthrough inspects a host you are authorized to query. The HTTP, TLS, and DNS requests are read-only observations, although they still generate logs and traffic. SSH checks read your own trust record; the deployment host may differ from the website hostname.

Use a disposable local working directory for captured output. No output shown here is a fresh measurement of www.xbcatm.com, and a passing command proves only the property it actually checks.

Each observation supports a bounded claim. Header presence, certificate dates and local records cannot combine into a whole-service safety badge.

1. Start with the policy the edge advertises

Fetch a GET response without silently following redirects, then inspect its status and headers:

host=www.xbcatm.com
url="https://$host/"
curl -sS --max-time 20 -D headers.txt -o body.html "$url"
cat headers.txt

The repository’s intended policy includes the following illustrative fields:

Content-Security-Policy: default-src 'self'; base-uri 'self'; form-action 'none'; frame-ancestors 'none'; object-src 'none'; script-src 'none'; style-src 'self'; img-src 'self' data:
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY

script-src 'none' is a strict choice for this script-free site, not a universal recipe for every static site. The browser enforces CSP; a report-only header does not block execution. Read the complete policy for more-specific script directives, and compare normal pages and error routes. nosniff constrains MIME handling, notably script/style destinations, but does not certify the body’s media type.

HSTS is learned from valid HTTPS responses and applies to the host that sent it. A policy received from www.example.com with includeSubDomains covers descendants of that name, not its sibling api.example.com or parent example.com. Inventory the actual scope before adopting a long duration. A proxy adding or stripping headers changes the browser contract, which is why artifact checks and edge checks are separate.

2. Verify TLS identity before reading certificate dates

SNI selects the intended virtual host; it does not verify the certificate name. Make verification failure fatal and explicitly request hostname validation. Use an up-to-date trust store appropriate to the clients under test.

openssl s_client -connect "$host:443" -servername "$host" \
 -verify_hostname "$host" -verify_return_error -showcerts \
 </dev/null > tls.txt 2> tls.log
# Continue only if the command succeeded; preserve tls.log on failure.
openssl x509 -in tls.txt -noout -subject -issuer -dates -ext subjectAltName

Run these as separate checked steps, or under a shell setup that stops on failure. Hiding stderr or piping into a successful x509 command can conceal an unsuccessful handshake. Inspect the DNS names in subjectAltName; the displayed subject CN is not sufficient for modern service-identity validation. Some library versions retain legacy CN fallback, so explicitly check that the expected SAN is present. A valid matching wildcard may be legitimate; an unrelated certificate is not.

notAfter gives the expiry time. It does not prove the chain is trusted, the hostname matches, or revocation was checked. Record the date and the measured safety window rather than relying on memory. OpenSSL’s result describes its configured trust store and checks, not every browser’s behavior.

3. Read the presented chain without inventing a fixed count

The -showcerts output contains certificates sent by the server, not a declaration that they form a verified chain. This command displays their count only:

grep -c 'BEGIN CERTIFICATE' tls.txt

There is no required count of four. The server normally supplies the leaf and necessary intermediate certificates; a root usually belongs in the client’s trust store and need not be sent. Chain length varies with the CA and chosen path. One certificate warrants investigating whether intermediates are needed, but a count alone is neither success nor failure.

Use the actual verification result from step 2, then investigate issuer/SAN changes, missing intermediates, expiry, and trust-store differences. An intermediate rotation can be normal CA maintenance. A numerically unchanged chain can still be wrong, and the count command does not automatically compare anything with an expected value.

4. Revalidate the captured representation

Caching is a separate contract, not evidence of TLS identity. Capture a current ETag and use it on a request selecting the same representation, as in the HTTP walkthrough. A matching conditional GET can return 304; a deployment between requests can legitimately produce 200. An old hardcoded validator is not a reusable test fixture for a changing site.

A no-script policy does not mean CSP never changes. Security headers can change independently of HTML, and a body ETag does not fingerprint every response header. Record the actual policy again after release.

5. Find the relevant CAA policy

CAA constrains issuance by compliant certificate authorities. It is not certificate pinning and does not retroactively invalidate an already issued certificate. Start by inspecting the queried name and its ancestors; retain response status so a DNS failure is not mistaken for an empty answer.

dig www.xbcatm.com CAA +noall +comments +answer
dig xbcatm.com CAA +noall +comments +answer

An empty answer at www does not mean issuance is unrestricted. RFC 8659 searches upward until the first relevant nonempty CAA set, following aliases during each lookup; continue through applicable ancestors if necessary. Inspect issue, and issuewild when wildcard issuance is involved. An iodef report address alone does not restrict issuance. If no restricting policy applies, CAA adds no issuer restriction, but normal domain validation and CA rules still apply.

Compare the CA’s documented CAA identifier with the relevant policy, not merely the leaf’s human-readable issuer CN. Today’s CAA result is evidence about today’s DNS policy, not proof of what existed when the certificate was issued.

6. Check the deployment host’s recorded SSH identity

Use the actual SSH destination, including the bracketed host/port form for a non-default port. ssh-keygen -F can find hashed known-host entries that a text grep of the hostname misses.

deploy_host=deploy.example.test
ssh-keygen -F "$deploy_host" -f "$HOME/.ssh/known_hosts" > host-record.txt
ssh-keygen -lf host-record.txt

Compare the fingerprint with an independently trusted record, such as the provider console or a verified administrator channel. This reads the local record; it does not prove which key the remote host presents now. A network key scan alone would not authenticate that key either. Investigate a changed key before updating trust; a rebuild is one possible explanation, not automatic permission to accept it.

Inspect all Set-Cookie fields in the captured response and any relevant redirect or application route. No cookie on one page does not establish that the entire site never sets cookies. A host-only cookie omits Domain; adding a parent Domain broadens the hosts receiving it. Path controls delivery but is not a security boundary against same-origin code.

Secure restricts transport, HttpOnly blocks script access to the cookie, and SameSite controls specified cross-site sending behavior. They address different risks and do not replace one another; SameSite=None requires Secure in modern browsers. For this site’s no-account content model, ask why a cookie is needed at all before broadening its scope. Redact cookie values from shared audit records.

Keep a bounded audit record

Record the UTC time, client versions, requested/final URL, status, enforcing headers, TLS verification result and dates, relevant CAA lookup, and SSH record source. Distinguish observed success, unexpected results, and checks not performed. These several observations take more than “two commands” and cannot prove the whole service secure.

Repeat the relevant checks after certificate, DNS, proxy, or deployment changes. Preserve prior results to identify drift, and test actual browser behavior separately when the claim depends on browser enforcement.

Sources

WHATWG Fetch Standard, nosniff processing and request destinations, checked 2026-10-15.
OpenSSL s_client, SNI, hostname verification, fatal verification errors, and presented chains, checked 2026-10-15.
RFC 9525: Service Identity in TLS, SAN-based service identity and wildcard matching, checked 2026-10-15.
RFC 8659: CAA, relevant record-set search and issuance policy, checked 2026-10-15.
RFC 6797: HSTS, host scope and policy processing, checked 2026-10-15.
OpenSSH ssh-keygen, known-host lookup and fingerprint display, checked 2026-10-15.
W3C: CSP Level 3, enforcing versus report-only policy and script directive fallback (working draft), checked 2026-10-15.
MDN: Set-Cookie, cookie attributes and their limits, checked 2026-10-15.

TLS 1.3 handshake basics

Thu, 06 Aug 2026 00:00:00 +0000

TLS 1.3 establishes traffic keys and authenticates the peer under the application’s trust policy. Ordinary HTTPS authenticates the server; client certificates are optional, not an automatic consequence of encryption. A successful TCP connection alone establishes neither identity nor a working HTTP service.

What one round trip means

In a normal certificate-based handshake, ClientHello offers versions, algorithms, and key shares. ServerHello selects parameters and contributes the server’s share. The server then sends encrypted extensions, its certificate, CertificateVerify, and Finished. The client checks the certificate and handshake proofs before sending its own Finished and ordinary application data.

Without HelloRetryRequest, the client can send that data after one TLS round trip over an established transport. This excludes DNS lookup, TCP establishment, and the HTTP response journey. A missing suitable initial key share can require HelloRetryRequest and another exchange; no mutually acceptable parameters can instead make negotiation fail. One RTT is a protocol path, not a promise about total page latency.

TLS 1.3 cipher-suite names identify record protection and a hash. They do not by themselves identify the certificate’s signature algorithm or the negotiated key-exchange group. Seeing AES in a cipher name does not establish which authentication checks ran.

Authentication and forward secrecy

Certificate-based ephemeral Diffie-Hellman protects recorded sessions against later compromise of the certificate’s private key, assuming ephemeral secrets were erased and endpoints were not compromised during the session. An RSA certificate can authenticate an ephemeral exchange; it does not imply obsolete RSA key transport.

However, TLS 1.3 also defines PSK-only and PSK-with-DHE modes. PSK-only lacks the latter’s forward-secrecy property. Optional early data has weaker security too: it is not forward secret and lacks ordinary cross-connection replay guarantees. Receiving a session ticket neither enables early data automatically nor turns every later handshake into zero RTT.

When it breaks

Separate version negotiation, trust-chain validation, hostname verification, and application behavior. Disjoint version ranges fail before HTTP. An untrusted issuer or wrong subject alternative name must also fail, even when an encrypted channel could otherwise be created. Expired certificates and an incorrect clock need their own checks; this experiment does not inject them.

SNI helps select a virtual host, while hostname verification checks the returned identity. Neither a displayed certificate nor a negotiated cipher proves that verification succeeded. Keep the original error and the intended name when diagnosing failures. Do not disable certificate verification, lower the protocol floor, or retry indefinitely merely to make a probe green.

The exact TLS 1.3 version range below makes negotiation observable; it is not an unreviewed production policy. Version bounds do not repair certificate trust. If a reverse proxy terminates TLS, inspect its client-facing connection separately from upstream TLS: those are independent handshakes and can negotiate different versions and authenticate different identities.

Check it quickly

Save the following as handshake_probe.go and run go run handshake_probe.go with Go 1.23 or newer. It uses only the standard library and a temporary loopback HTTPS server. The fixture’s certificate is trusted only by its test client; it is not installed into the machine’s trust store. Each request has a two-second limit and uses a new HTTP transport.

package main

import (
 "crypto/tls"
 "crypto/x509"
 "errors"
 "fmt"
 "io"
 "log"
 "net/http"
 "net/http/httptest"
 "runtime"
 "sync/atomic"
 "time"
)

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func fetch(server *httptest.Server, config *tls.Config) (tls.ConnectionState, error) {
 transport := &http.Transport{
 TLSClientConfig: config,
 DisableKeepAlives: true,
 }
 defer transport.CloseIdleConnections()
 client := &http.Client{Transport: transport, Timeout: 2 * time.Second}
 response, err := client.Get(server.URL)
 if err != nil {
 return tls.ConnectionState{}, err
 }
 defer response.Body.Close()
 body, err := io.ReadAll(response.Body)
 if err != nil {
 return tls.ConnectionState{}, err
 }
 check(response.StatusCode == 200 && string(body) == "ok\n", "unexpected HTTP reply")
 return *response.TLS, nil
}

func main() {
 var handled atomic.Int64
 server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 handled.Add(1)
 fmt.Fprintln(w, "ok")
 }))
 server.Config.ErrorLog = log.New(io.Discard, "", 0)
 server.TLS = &tls.Config{MinVersion: tls.VersionTLS13, MaxVersion: tls.VersionTLS13}
 server.StartTLS()
 defer server.Close()

 trusted := server.Client().Transport.(*http.Transport).TLSClientConfig.Clone()
 trusted.MinVersion, trusted.MaxVersion = tls.VersionTLS13, tls.VersionTLS13
 check(!trusted.InsecureSkipVerify, "certificate verification must stay enabled")
 state, err := fetch(server, trusted)
 check(err == nil, fmt.Sprint(err))
 check(state.HandshakeComplete && state.Version == tls.VersionTLS13, "TLS 1.3 required")
 check(!state.DidResume && len(state.VerifiedChains) > 0, "a verified full handshake is required")
 fmt.Println(tls.VersionName(state.Version), tls.CipherSuiteName(state.CipherSuite), "verified")

 wrongName := trusted.Clone()
 wrongName.ServerName = "wrong.invalid"
 _, err = fetch(server, wrongName)
 var nameError x509.HostnameError
 check(errors.As(err, &nameError), "wrong name must fail hostname verification")

 untrusted := trusted.Clone()
 untrusted.RootCAs = x509.NewCertPool()
 _, err = fetch(server, untrusted)
 var trustError x509.UnknownAuthorityError
 check(errors.As(err, &trustError), "empty roots must reject the test certificate")

 oldVersion := trusted.Clone()
 oldVersion.MinVersion, oldVersion.MaxVersion = tls.VersionTLS12, tls.VersionTLS12
 _, err = fetch(server, oldVersion)
 check(err != nil, "disjoint protocol versions must fail")
 check(handled.Load() == 1, "failed TLS attempts must not reach the HTTP handler")

 _, err = fetch(server, trusted)
 check(err == nil && handled.Load() == 2, "trusted TLS 1.3 must still work")
 fmt.Println("wrong name, untrusted certificate, and TLS 1.2-only client rejected before HTTP")
 fmt.Println(runtime.Version())
}

The verified request prints TLS 1.3 and a cipher name; the exact cipher can vary. The hostname and empty-root cases assert specific X.509 error types. The TLS-1.2-only client then fails against the TLS-1.3-only server. The handler count stays at one across all three rejected attempts, and a final correctly configured request raises it to two. Thus failure does not depend on an HTTP error response.

The normal certificate-based TLS 1.3 flight is shown over an already established transport, without HelloRetryRequest. In the article’s separate loopback tests, wrong.invalid, empty roots, and disjoint protocol versions all fail before HTTP. The fixture does not measure wire RTT or validate early data or mutual TLS.

The retained article reports that all assertions passed with Go 1.27.0 on macOS; this review did not rerun the Go fixture. Certificate verification remains enabled in the source. This demonstrates real TLS handshakes and failure boundaries, not packet-level RTT measurement, mutual TLS, early data, public DNS, or a production certificate rollout. Before changing a live endpoint, test the supported client population and its actual trust roots separately.

Sources

RFC 8446: TLS 1.3, sections 1.2 and 2–2.3: full handshakes, PSK modes, retry flights, and early-data limits, checked 2026-09-09.
Go crypto/tls, version bounds, certificate verification, and ConnectionState, checked 2026-09-09.
Go net/http/httptest, loopback TLS fixtures and the test client’s trust configuration, checked 2026-09-09.

HSTS should be rolled out with a recovery plan

Tue, 23 Jun 2026 00:00:00 +0000

HTTP Strict Transport Security tells a supporting browser to use HTTPS for a host during a cached period. That persistence is the feature and the risk: removing the header does not immediately erase policy already stored by clients.

Extend HSTS only after observation. Decide descendant scope and preload separately. Recovery needs valid HTTPS and cannot instantly erase every stored or preloaded policy.

Verify the HTTPS path first

Before sending HSTS, confirm that the canonical hostname serves a valid certificate and that HTTP redirects to the intended HTTPS URL without depending on user input:

curl -sS -D - -o /dev/null --max-redirs 0 http://www.example.test/
curl -sS -D - -o /dev/null https://www.example.test/

Check representative deep routes and error pages. HSTS cannot repair a certificate error because the browser requires a valid HTTPS connection before accepting the policy.

Start with a short max-age

A staged rollout limits the recovery window while configuration is new:

Strict-Transport-Security: max-age=300

After observing the site and renewal path, increase the duration deliberately. Record the date, chosen value, and rollback conditions. A final policy might use a year, but the number is a commitment rather than a scanner score.

Treat includeSubDomains as a separate decision

includeSubDomains extends policy to every subdomain. Inventory names first, including old services, delegated zones, and hostnames used only on internal networks. One HTTP-only descendant is enough to make the option disruptive for clients that received the parent policy.

Preload is not ordinary header configuration

Browser preload programs can distribute policy outside the normal response cycle. Their requirements and removal delays are stricter than setting a header. Do not request preload merely because a scanner recommends it; confirm long-term ownership of the domain and all covered names.

Verify the public response

curl -sS -D - -o /dev/null https://www.example.test/ \
 | awk 'tolower($1) == "strict-transport-security:" { print }'

Test the canonical public edge, not only an origin port. Proxies may add, remove, or duplicate the header.

Know what rollback can clear

A valid HTTPS response with max-age=0 clears that host’s learned policy only for clients that receive it. Removing the header or sending it over HTTP does not clear a cached policy. A child cannot opt out of a parent’s still-active includeSubDomains, and clearing a parent does not delete policies independently learned for children.

Scope follows the host that sends the header: policy from www.example.test covers that host and, with includeSubDomains, its descendants, not the sibling api.example.test or the parent example.test. Keep HTTPS working during recovery. Preload removal is a separate browser-update process, not an immediate response-header rollback.

Sources

RFC 6797 — HTTP Strict Transport Security, policy processing and scope, checked 2026-10-15.
MDN: Strict-Transport-Security, directives and deployment cautions, checked 2026-10-15.
HSTS preload program, submission requirements and removal constraints, checked 2026-10-15.

A TLS certificate expiry is a date you can read

Mon, 22 Jun 2026 00:00:00 +0000

A certificate’s expiry is a deadline for certificate validation, not a timer that necessarily closes every existing connection. Read the certificate actually served to the intended hostname, then distinguish its validity window from the rest of the trust decision. A future notAfter date alone does not establish that HTTPS is healthy.

Compare instants, not calendar labels

RFC 5280 defines validity from notBefore through notAfter, inclusive. A verifier must reject a certificate outside that interval; the exact notAfter instant remains inside it. Waiting for the final second is nevertheless an operational mistake. Clock uncertainty, retries, and rollout time require a margin comfortably before the boundary.

The fields describe absolute times. UTC makes logs easier to compare, but two correctly parsed timestamps can use different timezone representations and still identify the same instant. Subtract instants using a time library. Comparing local date strings or rounded remaining days can hide a not-yet-valid certificate or postpone an urgent warning.

Inspect the public edge with the correct SNI and expected hostname, not only a certificate file on the origin. Different listeners, regions, or load-balancer nodes can serve different certificates. Public certificate inspection needs no private key, but merely retrieving dates is not equivalent to validating the chain, hostname, usage, and applicable client policies.

When it breaks

Renewal can succeed while deployment fails: the new certificate exists on disk, but a process still serves the previous one. Compare the served fingerprint and validity dates after reload, including all relevant edges. Also inspect the chosen chain: a valid leaf can sit below an expired intermediate and fail verification.

Clock skew may make a fresh certificate appear not yet valid. A monitor that turns a network timeout or parsing failure into an empty expiry value must not report healthy. Distinguish unavailable evidence from a successfully verified, sufficiently long validity window, and keep an owner and escalation path for each monitored endpoint.

Choose renewal and warning schedules from the actual certificate lifetime and recovery needs, not a universal thirty-day constant. Let’s Encrypt recommends using ACME Renewal Information when available and spreading renewal work. Monitor issuance failures separately from served-certificate expiry. Renewal does not automatically rotate every private key, and expiry monitoring is not revocation checking.

Check it quickly

Save this as expiry_probe.go and run go run expiry_probe.go with Go 1.23 or newer. The program generates an isolated root, intermediate, and leaf in memory. Verification uses an explicit test trust store, hostname, server-authentication usage, and injected time. The synthetic clock starts at 2026-09-09 00:00:00 UTC; it never changes the machine’s clock.

package main

import (
 "crypto/ed25519"
 "crypto/rand"
 "crypto/x509"
 "crypto/x509/pkix"
 "errors"
 "fmt"
 "math/big"
 "runtime"
 "time"
)

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func key() (ed25519.PublicKey, ed25519.PrivateKey) {
 public, private, err := ed25519.GenerateKey(rand.Reader)
 must(err)
 return public, private
}

func issue(serial int64, parent *x509.Certificate, public ed25519.PublicKey, signer ed25519.PrivateKey, start, end time.Time, ca bool) *x509.Certificate {
 template := &x509.Certificate{
 SerialNumber: big.NewInt(serial), Subject: pkix.Name{CommonName: fmt.Sprint("fixture-", serial)},
 NotBefore: start, NotAfter: end, IsCA: ca, BasicConstraintsValid: true,
 }
 if ca {
 template.KeyUsage = x509.KeyUsageCertSign
 } else {
 template.KeyUsage = x509.KeyUsageDigitalSignature
 template.ExtKeyUsage = []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth}
 template.DNSNames = []string{"expiry.example.test"}
 }
 if parent == nil {
 parent = template
 }
 der, err := x509.CreateCertificate(rand.Reader, template, parent, public, signer)
 must(err)
 certificate, err := x509.ParseCertificate(der)
 must(err)
 return certificate
}

func main() {
 base := time.Date(2026, 9, 9, 0, 0, 0, 0, time.UTC)
 rootPublic, rootPrivate := key()
 issuerPublic, issuerPrivate := key()
 leafPublic, _ := key()
 root := issue(1, nil, rootPublic, rootPrivate, base.Add(-24*time.Hour), base.Add(24*time.Hour), true)
 issuer := issue(2, root, issuerPublic, rootPrivate, base.Add(-time.Hour), base.Add(3*time.Hour), true)
 leaf := issue(3, issuer, leafPublic, issuerPrivate, base, base.Add(2*time.Hour), false)
 roots, intermediates := x509.NewCertPool(), x509.NewCertPool()
 roots.AddCert(root)
 intermediates.AddCert(issuer)
 verify := func(certificate *x509.Certificate, instant time.Time, name string) error {
 _, err := certificate.Verify(x509.VerifyOptions{
 Roots: roots, Intermediates: intermediates, CurrentTime: instant, DNSName: name,
 KeyUsages: []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
 })
 return err
 }
 expired := func(err error, certificate *x509.Certificate) {
 var invalid x509.CertificateInvalidError
 check(errors.As(err, &invalid) && invalid.Reason == x509.Expired &&
 invalid.Cert.SerialNumber.Cmp(certificate.SerialNumber) == 0, "wrong validity failure")
 }
 for _, test := range []struct {
 label string
 instant time.Time
 valid bool
 }{
 {"before", base.Add(-time.Second), false},
 {"notBefore", base, true},
 {"middle", base.Add(time.Hour), true},
 {"notAfter", base.Add(2 * time.Hour), true},
 {"after", base.Add(2*time.Hour + time.Second), false},
 } {
 err := verify(leaf, test.instant, "expiry.example.test")
 if test.valid {
 must(err)
 } else {
 expired(err, leaf)
 }
 fmt.Println(test.label, "valid:", err == nil)
 }
 longLeaf := issue(4, issuer, leafPublic, issuerPrivate, base, base.Add(6*time.Hour), false)
 expired(verify(longLeaf, base.Add(4*time.Hour), "expiry.example.test"), issuer)
 var hostname x509.HostnameError
 check(errors.As(verify(leaf, base.Add(time.Hour), "wrong.example.test"), &hostname), "wrong name must fail")
 sameInstant := base.In(time.FixedZone("fixture+08", 8*60*60))
 must(verify(leaf, sameInstant, "expiry.example.test"))
 check(leaf.NotAfter.Sub(sameInstant) == 2*time.Hour, "timezone must not change the instant")
 remaining := leaf.NotAfter.Sub(base.Add(90 * time.Minute))
 check(remaining == 30*time.Minute && remaining <= 45*time.Minute, "fixture alert must fire")
 fmt.Println("issuer expiry and wrong name rejected; timezone preserves instant; remaining=30m triggers 45m warning")
 fmt.Println(runtime.Version())
}

The five validity results must be false, true, true, true, false. The ordinary leaf ends at hour two, its intermediate at hour three, and its root at hour twenty-four after the base. Consequently, both leaf endpoints can be checked without an unrelated issuer expiry masking the expected result. Negative assertions check the error reason and the affected certificate’s serial number.

A second leaf lasts six hours. At hour four, that leaf is still within its window but its intermediate is expired, so the chain fails on the issuer. A separate request to verify the ordinary leaf for the wrong DNS name fails with HostnameError while time validity remains satisfied.

The synthetic base is 2026-09-09 00:00:00 UTC. The ordinary leaf includes both 0h and 2h endpoints. At 4h a second leaf valid through 6h fails because the issuer ended at 3h. The 30-minute remainder and 45-minute warning are test parameters, not renewal advice. This is in-memory X.509 verification, not a network handshake.

Representing the base instant in a fixed UTC+08 timezone does not change verification or remaining duration. At ninety minutes, the ordinary leaf has thirty minutes left, which triggers this fixture’s forty-five-minute warning. Those tiny intervals are test parameters, not recommended production schedules. Successful execution prints labels and the Go version, never private keys.

All assertions passed with Go 1.27.0 on macOS. This is X.509 verification, not a network TLS handshake or an automated renewal deployment. Go’s Verify does not perform revocation checking. The exercise tests selected chain and clock boundaries; it does not inspect public edges, browser-specific policies, OCSP, CRLs, or session-resumption behavior. Existing connections need their own lifecycle policy.

Sources

RFC 5280: X.509 certificates, inclusive validity intervals and certification paths, checked 2026-09-09.
Go crypto/x509, VerifyOptions, error reasons, and revocation limitations, checked 2026-09-09.
Let’s Encrypt: integration guide, renewal information, scheduling, and failure reporting, checked 2026-09-09.

CAA records should authorize the issuer you actually use

Wed, 17 Jun 2026 00:00:00 +0000

Certification Authority Authorization records let a domain holder state which certificate authorities may issue certificates for the domain. They are useful only when the record matches the real renewal path and the operator understands how policy can be inherited from parent names.

CAA authorizes issuers at issuance time. Lookup stops at the first relevant nonempty record set; wildcard tags refine the rule. Existing certificates and HTTPS trust are separate boundaries. The displayed issuer is an example.

Inspect the current policy

Query the exact hostname and its parent names:

for name in www.example.test example.test test; do
 printf '== %s\n' "$name"
 dig +noall +answer CAA "$name"
done

These are placeholder names, queried through the configured resolver. An empty answer at the leaf does not necessarily mean there is no applicable policy: lookup follows aliases and stops at the first nonempty relevant CAA RRset while walking upward. It does not merge every parent’s restrictions. Inspect DNS status and authority information too; an empty answer-only display can hide NXDOMAIN or SERVFAIL. Compare authoritative answers with recursive results when diagnosing changes.

Match the CA’s issuer identifier

A record uses tags such as issue or issuewild and an issuer-domain value:

example.test. 3600 IN CAA 0 issue "letsencrypt.org"

The value is an authorization identifier, not the display name from a certificate. Confirm it in the certificate authority’s current documentation. Without issuewild, issue also governs wildcard issuance. When issuewild is present, it takes precedence for wildcard requests; multiple records of the same tag grant alternatives rather than requiring every CA. CAA does not select a particular intermediate certificate.

Stage the DNS change before renewal

Add or tighten CAA while the current certificate is healthy. Wait through the previous TTL, query authoritative and recursive answers, and run a staging or renewal test supported by the ACME client. Keep a rollback record ready.

Do not add a restrictive record during an expiry incident unless the issuer path has already been verified. A syntactically correct but wrong policy can turn automatic renewal into a hard failure.

Observe issuance failures

CAA checks happen at issuance time, not on every HTTPS request. Changing CAA neither revokes existing certificates nor proves that a historical issuance complied with the policy at that time. Certificate monitoring must therefore cover both current expiry and renewal attempts. Log the effective DNS answer with the ACME failure instead of recording only a generic authorization error.

Sources

RFC 8659 — DNS Certification Authority Authorization, CAA lookup and property semantics, checked 2026-10-15.
Let’s Encrypt: CAA, issuer identifiers and operational guidance, checked 2026-10-15.

Certificate expiry is a date, not a dashboard color

Wed, 10 Jun 2026 00:00:00 +0000

An HTTPS process can be healthy while the public certificate is close to expiry, issued for the wrong name, or served differently on another edge. A useful check asks the public endpoint for the certificate it would give to a real client.

Inspect the certificate a real client sees, then verify separately. Expiry alerts need a service-specific response threshold, handshake checks, renewal-failure alerts, and sampling of relevant edges and address families.

Include the hostname

TLS virtual hosting depends on the server name. Pass the hostname as SNI and inspect the peer certificate:

host=www.example.test
openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null \
 | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256

The command is read-only. It does not renew anything and it does not prove that every intermediate certificate is accepted by every client. It does give you the not-before, not-after, subject, issuer, and fingerprint of the certificate presented for that hostname.

Alert on a threshold

Choose a threshold that leaves time for a failed renewal, a DNS problem, and a human response. The exact number belongs to the service’s recovery target; a universal “30 days” rule is not a substitute for that decision. The companion TLS expiry check prints the expiry and exits non-zero when the remaining interval is below the threshold you pass.

Run the check from outside the host when possible. A local process may see a different listener, certificate file, or proxy path than a visitor on the public network.

Separate observation from verification

SNI selects a virtual host; it does not verify that the certificate matches that name. This pipeline prints a certificate even when s_client reports verification problems, and stderr is suppressed. Use a separate hostname-and-chain verification check with visible diagnostics and a known trust store. Do not turn this inspection pipeline’s final exit code into a TLS-health verdict.

The companion helper tests notAfter with OpenSSL -checkend; it does not establish hostname validity, trust, revocation status, or that notBefore has arrived. Pair expiry alerts with handshake checks and renewal-failure alerts. Choose a threshold smaller than the certificate’s normal lifetime, especially for short-lived certificates, and sample each relevant edge/address family.

Sources

Caddy Automatic HTTPS, automatic TLS certificate management, checked 2026-10-15.
OpenSSL s_client documentation, SNI and certificate inspection options, checked 2026-10-15.
OpenSSL x509 documentation, certificate parsing, dates, and fingerprints, checked 2026-10-15.

A certificate chain is a path you should be able to print

Mon, 08 Jun 2026 00:00:00 +0000

A TLS client must build a valid certificate path to an anchor it already trusts, and verify the requested hostname. Printing certificates is a useful diagnostic, but does not establish either result by itself.

The server supplies certificates; trust comes from the client’s anchor. Validate the path, requested hostname and validity period. Printed certificate counts cannot establish those results.

The leaf is not the whole story

The endpoint presents the leaf first. It contains the public key, validity period, and subject alternative names used for hostname checks. A public-CA deployment normally also sends the intermediates needed to build a path. Missing intermediates can break clients that do not already have them cached or cannot retrieve them.

The self-signed root normally need not be sent: trust comes from the client’s configured anchors, not from a server including a certificate. A cross-signed certificate whose subject says “Root” can instead be an intermediate in the selected path. Certificate count alone is therefore not a completeness or trust test.

Read the chain the edge actually sends

OpenSSL documents s_client -showcerts as the server’s certificate list, not a verified chain. The earlier version of this note recorded this site snapshot:

certificate 0: CN=www.xbcatm.com
 issuer : C=US, O=Let's Encrypt, CN=YE1
 notAfter : Nov 19 08:37:12 2026 GMT

certificate 1: CN=YE1 (intermediate)
 issuer : C=US, O=ISRG, CN=Root YE

certificate 2/3: Root YE / ISRG Root … (CA certificates)

The original report counted four blocks. Its raw handshake log is not retained here, and this review did not reproduce the live handshake; treat the values as a historical report, not current edge evidence. Let’s Encrypt’s chain documentation does describe YE1 and a cross-signed Root YE path, so those names alone are not evidence of an invalid chain. Which certificate terminates trust depends on the client’s trust store and path building.

Keep issuance authorization separate

Intermediates let a CA keep its root key offline and separate issuance operations. Revoking an intermediate can invalidate dependent leaf paths and may require replacement certificates; it does not preserve every leaf automatically.

CAA authorizes a CA’s documented issuer-domain identifier at issuance time. It does not pin an intermediate, change browser trust, or prove that an existing certificate complied with historical CAA. The dns-caa-records note covers that separate policy check.

Count for inventory, validate for trust

The earlier inventory command was:

$ echo | openssl s_client -connect www.xbcatm.com:443 -servername www.xbcatm.com -showcerts 2>/dev/null | grep 'BEGIN CERT' | wc -l
4

This is read-only network traffic, but it suppresses diagnostics and the final count can succeed even when an earlier command failed. Do not use 4, or any other fixed count, as a health threshold. A leaf-only result warrants checking the expected issuer path rather than declaring every one-certificate chain invalid.

For actual validation, configure hostname checking and failure on verification errors with OpenSSL’s -verify_hostname and -verify_return_error options, retain diagnostics, and record the trust store and client version. Also test the clients you support; one OpenSSL trust store cannot establish compatibility with all browsers.

Sources

RFC 8446 — TLS 1.3, section 4.4.2 certificate-list order and optional trust-anchor omission, checked 2026-10-15.
RFC 5280 — X.509 PKI, section 6 trust-anchor input and path validation, checked 2026-10-15.
Let’s Encrypt FAQ, certificate compatibility overview, checked 2026-10-15.
Let’s Encrypt: Chains of Trust, YE1 and cross-signed Root YE paths, checked 2026-10-15.
OpenSSL s_client, presented-list and verification options, checked 2026-10-15.
RFC 8659 — CAA, issuance authorization rather than client trust, checked 2026-10-15.

TLS · XB Field Notes

SNI lets one IP host many TLS sites

The name goes first

Match by server_name block

Control the default fallback

When it breaks

Check it quickly

Sources

OCSP stapling delivers status evidence under a client policy

Deliver evidence without transferring trust

Check support before enabling anything

When it breaks

Check it quickly

Sources

Certificate transparency makes issuance observable

A promise is not an inclusion proof

When it breaks

Check it quickly

Further reading

Sources

The forward-secrecy boundary of TLS ECDHE

Two kinds of keys do different jobs

When it breaks

Check it quickly

Further reading

Sources

DoT and DoH protect the connection to the resolver you authenticate

When it breaks

Check it quickly

Keep the resolver and bootstrap configuration visible

Sources

Client certificates authenticate control of a private key

Authentication still needs authorization

When it breaks

Check it quickly

Further reading

Sources

TLS 1.3 resumption reuses authentication state

New connection, fresh traffic keys

When it breaks

Check it quickly

Further reading

Sources

TLS handshakes add latency you can shrink

Messages travel in flights

When it breaks

Check it quickly

Further reading

Sources

Caddy automates HTTPS issuance and renewal

Give automatic HTTPS a name

Match the challenge to the route

When it breaks

Check it quickly

Further reading

Sources

Checking HTTPS beyond the lock icon

Ask several concrete questions

When it breaks

Check it quickly

Further reading

Sources

SNI selects a TLS certificate for the requested hostname

One address, separate decisions

When it breaks

Check it quickly

Further reading

Sources

HSTS makes the browser remember HTTPS

The client remembers a host

When it breaks

Check it quickly

Further reading

Sources

Set a TLS version floor and test its boundary

A floor is not a ceiling

When it breaks

Check it quickly

Further reading

Sources