SkillAudit
TLS Security·Certificate Transparency·MITM Prevention

MCP server certificate transparency security: CT log monitoring and rogue certificate detection

Certificate Transparency (CT) is a public, append-only log of every TLS certificate issued by participating Certificate Authorities. Every browser-trusted certificate must be logged in a CT log before it will be accepted. This creates a searchable public record you can monitor: if a rogue CA or a compromised CA account issues a certificate for your MCP server's domain, you can detect it within minutes of issuance — before it's deployed in a man-in-the-middle attack.

Why CT monitoring matters for MCP servers

MCP servers transport sensitive tool call arguments and results over TLS. A man-in-the-middle attacker who holds a valid certificate for your MCP server's domain can intercept and modify these calls — injecting prompt injection payloads into tool results, exfiltrating tool call arguments, or replaying calls. Standard TLS validation won't catch this because the attacker's certificate is technically valid (issued by a real CA).

CT monitoring is your early warning system: you're alerted when any new certificate is issued for your domain, whether by your authorized CA or an attacker who compromised a CA or social-engineered a domain validation. If you see a certificate you didn't request, you can revoke it (or at least alert on its use) before it's deployed.

How CT logs work

When a CA issues a certificate, it submits the certificate to one or more CT logs. The log returns a Signed Certificate Timestamp (SCT) — a cryptographic promise that the certificate has been logged. Modern browsers require valid SCTs embedded in or delivered alongside certificates. The CA includes the SCTs in the certificate or delivers them via TLS extension or OCSP stapling.

CT logs are publicly queryable. The most comprehensive public search interface is crt.sh (operated by Sectigo). You can query it via API: https://crt.sh/?q=%.yourdomain.com&output=json returns all certificates matching the wildcard pattern, with issuance time, expiry, CA, and SAN list. Use this to build your monitoring baseline: query crt.sh on a schedule and alert on any new certificate that wasn't pre-authorized.

Real-time monitoring with Certstream

crt.sh polling is adequate for daily monitoring, but CT logs have near-real-time data. Certstream (open source, runs a WebSocket stream of all new CT log entries) lets you subscribe to certificate issuances as they happen. Set up a Certstream consumer that filters for your domain patterns and sends an alert (PagerDuty, Slack, email) within seconds of a new cert appearing.

For MCP servers with high security requirements, Certstream monitoring should be part of your incident response runbook: a new unexpected cert for your domain triggers an investigation, not just a notification. Most legitimate cert issuances come from Let's Encrypt auto-renewal or your CDN provider — anything else warrants investigation.

CAA records: restricting which CAs can issue for your domain

Certification Authority Authorization (CAA) DNS records tell CAs which other CAs are allowed to issue certificates for your domain. If your domain has a CAA record specifying only Let's Encrypt, any other CA that receives a certificate request for your domain must refuse it (or face CA/Browser Forum sanctions).

CAA records are your defense against unauthorized issuance: even if an attacker steals a user's account at DigiCert, they can't issue a certificate for your domain if your CAA record only authorizes Let's Encrypt. Add a CAA record to every domain your MCP server uses. Check your current CAA records with: dig CAA yourdomain.com.

SCT validation at the MCP client

TLS validation in MCP clients should include SCT validation: verify that the server's certificate has valid SCTs from known CT logs before trusting the connection. Most TLS libraries handle this automatically for certificates with embedded SCTs. For extra assurance, maintain a local list of trusted CT log public keys and validate SCT signatures before trusting new connections to high-value MCP servers.

What SkillAudit checks for TLS and CT

SkillAudit's Maintenance axis includes TLS hygiene checks:

These checks complement the active security analysis — even a perfectly written MCP server is vulnerable if its TLS posture is weak enough for an attacker to intercept connections.

Audit your MCP server's TLS and certificate posture → SkillAudit checks CT coverage, CAA records, and certificate hygiene alongside code security