Why do requests with no client certificate succeed on a Go TLS server that checks r.TLS.PeerCertificates?

## The shape of the bug The code looks defensive. Somebody wrote: ```go if len(r.TLS.PeerCertificates) > 0 { if !allowed[r.TLS.PeerCertificates[0].DNSNames[0]] { http.Error(w, "forbidden", http.StatusForbidden) return } } ``` Every caller that presents a certificate is checked against the allow-list. Every caller that presents nothing walks straight past. The guard is not wrong about the callers it examines; it is that the decision to examine is taken from the caller. This is the vacuous pass, and it is the characteristic failure of client-certificate authentication written as an optional enrichment of the request rather than as a gate. ## Why the certificate is missing **The ClientAuth mode.** `tls.NoClientCert` is the zero value of `ClientAuthType`, so a config that sets `ClientCAs` and forgets `ClientAuth` never requests a certificate at all — and the handler's guard then skips for everyone, forever, silently. `tls.RequestClientCert` asks but accepts nothing in reply and verifies nothing it does get. `tls.VerifyClientCertIfGiven` verifies what arrives but still lets an empty-handed client complete the handshake. All three produce exactly the symptom described. Only `tls.RequireAndVerifyClientCert` makes an absent certificate a handshake failure. There is also `tls.RequireAnyClientCert`, which fails a different way: it demands a certificate but does not verify it, so `PeerCertificates` is non-empty with something the caller minted, `VerifiedChains` is empty, and a guard reading `PeerCertificates` authorises on an attacker-chosen name. **The config is not the serving one.** The `tls.Config` gets built, and then the process starts the listener some other way — a second `http.Server` in a test helper, a listener wrapped before the config was attached, a config value copied after `ListenAndServeTLS` already began. The struct in the code review is not the struct in the handshake. **TLS terminated upstream.** If a proxy or load balancer terminates TLS and forwards plaintext, `r.TLS` is nil in the handler. The same conditional guard skips, and whatever identity the proxy extracted is now a header — trustworthy only if nothing but that proxy can reach the listener. ## Diagnosing it The honest test is an integration test that makes the *same request twice*: once with a client certificate and once without, asserting that the second attempt fails. A test that only exercises the happy path passes identically whether the server requires certificates or ignores them, which is why the bug survives review — every existing test still goes green. Running it against a real `httptest` server with the production `tls.Config` also catches the wrong-config variant, because the assertion is about behaviour, not about a field's value. By hand the equivalent is dialling with `tls.Dial` or an `http.Client` carrying no `Certificates` and confirming the connection is refused. When it is refused, the server side records a `http: TLS handshake error from ...` line on `http.Server.ErrorLog`, and that absence-of-log is itself diagnostic: if unauthenticated attempts produce no handshake errors at all, nothing is being rejected. ## Fixing it in both layers 1. **Transport.** `ClientAuth: tls.RequireAndVerifyClientCert` with a `ClientCAs` pool containing only your internal issuer. Unauthenticated connections now die before a request exists. 2. **Handler.** Invert the guard so absence of an identity is a rejection. Extract the caller — nil `r.TLS`, empty `VerifiedChains` and a leaf with no usable name all return 'not identified' — and reject when extraction fails. The transport should already have made that branch unreachable, and the point is that it stays a rejection if someone later relaxes the mode or puts a proxy in front. That second layer is not redundancy theatre. Transport configuration is the thing most likely to be changed by a different team for an unrelated reason: a health check that could not present a certificate, a migration window that softened the mode 'temporarily'. A handler that fails closed turns that change into a visible outage instead of an invisible opening. ## The migration trap Teams moving an internal service off shared secrets usually run both credentials for a while, and the natural interim setting is `VerifyClientCertIfGiven` so old callers keep working. That is a defensible waypoint, but only if the handler treats a missing certificate as 'fall back to the shared secret and record it', never as 'skip the check'. The dangerous version of this migration is the one where the certificate path is added, everyone celebrates, and nobody ever tightens `ClientAuth` — because at that point the mutual TLS is decorative and every dashboard says it is on.