TLS cert validity is not checked on doctor run

[bam80]

For now only basic port reachability is checked:

$ mtg doctor config.toml
...
Validate fronting domain connectivity
  ✅ web:8443 is reachable

This alone is misleading if the cert is invalid or absent, so it's validity should be checked, too.

@dolonet

[dolonet]

Confirmed. checkFrontingDomain in internal/cli/doctor.go does a plain TCP dial:

conn, err := dialer.DialContext(ctx, "tcp", address)
...
conn.Close()

No TLS, no cert validation. Good catch.

Shape of the right check, for whoever picks this up:

1. TLS handshake against domain-fronting.host:port with ServerName = secret.host (that's what fronting actually does on the wire).
2. Validate the chain against the system roots.
3. Verify the leaf's SAN covers secret.host, not domain-fronting.host — in the contrib/sni-router setup the latter is web (a compose-internal DNS name), while the real cert is issued for the secret domain.
4. Honor GetDomainFrontingProxyProtocol() — when it's true (the recommended sni-router setup), send a PROXY v2 header before the handshake. Otherwise the probe hangs against Caddy's proxy_protocol listener wrapper and reports a false negative for the documented happy path.

Surfacing expiry is borderline: Caddy/certbot auto-renew well in advance and mtg can't act on it anyway. I'd skip it for v1 and only add if real reports come in.

[dolonet]

@9seconds — verified the design against current master, and it's simpler than my sketch above.

Refinement: points 2 and 3 (validate the chain, verify the SAN covers secret.host) don't need manual cert parsing — a standard crypto/tls client handshake does both for free. tls.Client(conn, &tls.Config{ServerName: d.conf.Secret.Host}) with verification on (the default) validates the chain against the system roots and checks the leaf SAN against ServerName as part of HandshakeContext. An expired / untrusted / wrong-host cert all surface as descriptive handshake errors (x509: certificate has expired, x509: certificate signed by unknown authority, x509: certificate is valid for …, not …).

So the actual change to checkFrontingDomain (internal/cli/doctor.go) is:

1. After the TCP dial, if GetDomainFrontingProxyProtocol(...) is true, write a PROXY v2 header to the conn before anything else — go-proxyproto is already a dependency (v0.11.0). Without this the handshake hangs against the sni-router happy path (Caddy's proxy_protocol listener wrapper).
2. tls.Client handshake with ServerName = d.conf.Secret.Host (the real fronting target — note checkFrontingDomain dials GetDomainFrontingHost() when set, but SNI must be the secret host).
3. Handshake OK → ✅; handshake error → ❌ with the error text.

~40-60 lines, doctor.go only, no new config, no new deps.

Two things for your call:

• This is internal/cli/ + feature-shaped, so same as non recognized options are silently ignored #517 — I'd like an explicit green light before cutting the PR.
• An expired cert fails the handshake hard (red ❌) rather than a soft ⚠️ warning. I think hard-fail is correct here — it matches the issue's intent ("misleading if the cert is invalid") and Caddy/certbot auto-renew well in advance, so a live expired cert is already a real problem. Flag if you'd rather have a separate warning tier.

Green light, or adjust?