tls_check: an opt-in TLS hardening check, with a badge on the H1 composite

[MDA2AV]

A new tls test: validation-only, opt-in, HTTP/1.1 only. Nothing is measured and no score moves — it is a hardening bar an entry chooses to be held to, and passing it earns a second badge on the H1 composite.

Built on top of #1292, which it reuses.

Why opt-in

Almost every check needs the entry to have done something deliberate. Binding a certificate once at startup — what nearly every entry does today — fails the first one. Measured before building any of this:

caddy:     did not rotate (still serving the old cert)
bun:       did not rotate
h2o-mruby: did not rotate

The checks

check	what it requires
certificate rotation	the pair at /certs is replaced under a running server; the new cert must be served without a restart and still answer
rotation keeps serving	30 requests across the swap, all must succeed
SNI	handshakes both with a server name and without one
session resumption	reported, not required
close_notify	closed at the TLS layer, not just the socket
vulnerability suite	testssl.sh -U — Heartbleed, ROBOT, POODLE, SWEET32, LUCKY13 and 14 more, ~30s. Any HIGH/CRITICAL fails
the shared TLS checks	cert identity, TLS 1.3, AEAD, ALPN, obsolete protocols, weak ciphers (from #1292)

Rotation is the centrepiece: a certificate is renewed roughly every 60 days in production, and a server needing a restart to pick one up is a weaker server. The usual way to pass is a per-handshake callback — Kestrel's ServerCertificateSelector, Go's GetCertificate, rustls' ResolvesServerCert.

Registration

A new VALIDATION_ONLY table in profiles.sh, not PROFILES. validate.sh accepts it in tests; the benchmark harness and leaderboard catalog ignore it, since there is no load generator behind it.

aspnet-minimal opts in and implements it

RotatingCertificate re-reads the PEM pair when its mtime moves, behind ServerCertificateSelector, which Kestrel calls per handshake. The mtime check is throttled to 1s — a stat is cheap next to a handshake but not next to a resumed one, and a second of staleness is nothing against a 60-day renewal.

PASS [tls certificate rotation] (new certificate served in 1s, original back in 1s, still answering)
PASS [tls rotation keeps serving] (30/30 requests answered across the swap)
PASS [tls SNI] · PASS [tls close_notify] · PASS [tls vulnerability suite]
NOTE [tls session resumption]: no session ticket issued

113 passed, section clean.

The badge

badge	meaning
green shield	TLS basics, on any entry with a TLS profile
gold shield	opted into this section and passed it

Shown only on the H1 composite (view === 'composite' && scope === 'h1') — the section covers :8081, so a badge earned there must not follow the entry into h2/h3 views it says nothing about. Verified across all four view combinations.

Two details worth stating

Each verdict answers only for its own checks. aspnet-minimal fails an unrelated intermittent /fortunes assertion in the same run, and neither badge depends on it — a flaky check elsewhere says nothing about whether an entry rotates a certificate.

Certificates are restored on the way out, including when a check fails midway, and the replacement carries the mode of the pair it replaces. A 0600 file a non-root container cannot read looks exactly like a server that ignored the rotation — the same trap that produced false failures in #1272.