TLS handshake completes with a trusted certificate
Authored by Stanley Hong · AgentReserve (founder).
The MCP endpoint completes a TLS handshake whose certificate validates against Node's CA store and matches the requested hostname. Untrusted, expired, or hostname-mismatched certificates are observable here even when the JSON-RPC handshake fails.
When this rule runs
Evaluated on every scan — observable from the URL, TLS handshake, or HTTP response headers, even when the MCP layer is auth-walled or unresponsive.
Why it matters
An HTTPS URL whose certificate doesn't validate is functionally indistinguishable from a man-in-the-middle: clients can't tell the server they reached from one impersonating it. This is a precondition for trusting anything else over the wire.
Pass condition
TLS connection completed and the peer certificate was authorized by Node's default CA store (chain valid, hostname matches, not expired).
Fail condition
TLS connection failed, or the peer certificate was rejected (untrusted CA, expired, hostname mismatch, self-signed).
Evidence examples
When the rule fails, the report records evidence in roughly this shape:
{"authorized": false, "authorizationError": "CERT_HAS_EXPIRED"}{"ok": false, "error": "Hostname/IP does not match certificate's altnames"}
Remediation
Serve the endpoint with a certificate from a publicly trusted CA, covering the exact hostname (SAN entry), and renew it before expiry. Use a managed cert (Let's Encrypt, ACM, etc.) where possible.
Methodology
This rule belongs to the Transport security dimension. How the server is reached on the wire. Covers TLS and protocol-level confidentiality of probe traffic.
Read the full methodology for how rules are aggregated into a score, how verdicts are decided, and how hard-fail rules override the aggregate.