AliveMCP

Reference · Security

MCP server SSL certificate

When an SSL certificate expires on a web application, browsers show a warning and users click through. When a certificate expires on an MCP server, agent frameworks throw an SSLError and stop. There is no override, no "proceed anyway" button, and no notification to anyone unless you've set up external monitoring. An expired certificate is a complete, silent outage.

TL;DR

MCP servers run over HTTPS, so TLS certificate health is an availability concern, not just a security concern. AliveMCP verifies TLS handshake success, certificate validity, and chain completeness on every probe. Author tier adds expiry alerting at 30, 14, and 7 days before expiry so you're never caught by an unexpected cert rotation. Join the waitlist to monitor your server's TLS health alongside its protocol availability.

Why certificate problems are worse for MCP than for web apps

A browser presents an interstitial when it encounters a certificate error: expired cert, hostname mismatch, or untrusted chain. The user can click through (for most non-HSTS errors), and the session continues with a warning. Agent frameworks have no equivalent mechanism. Python's httpx, Node's native https module, and the TypeScript MCP SDK all raise exceptions on certificate errors and halt execution. The agent turn fails. The user sees a generic error or nothing at all.

This difference matters for incident classification. A cert error on a web application is degraded (some users will click through). A cert error on an MCP server is a P1 outage. It affects every agent that tries to connect, from every location, until the certificate is renewed. The MTTR for a cert-expiry outage is bounded by how quickly your team can detect it and rotate the cert — often 30 minutes to several hours if no one is watching.

Modern certificate authorities issue 90-day certificates. Let's Encrypt, the most common CA for public MCP servers, operates on the 90-day cycle by design. On a 90-day cert, the renewal window is narrow. An unmonitored server whose auto-renewal silently fails will expire without warning.

What a TLS health check for an MCP server covers

Certificate validity and expiry

The most obvious check: is the certificate currently valid, and when does it expire? The expiry date is in the certificate's notAfter field. Checking this requires completing the TLS handshake, not just fetching the HTTP response. An expired certificate aborts the handshake before any HTTP bytes are exchanged.

Expiry countdown alerts should fire well before the problem, not at expiry. Reasonable alert thresholds for a 90-day certificate:

Certificate chain completeness

A TLS certificate is signed by an intermediate CA, which is itself signed by a root CA. Clients validate the entire chain. If your server serves only the leaf certificate and omits the intermediate, some clients will fail even though the leaf certificate is valid and not expired. This is an extremely common misconfiguration on new deployments.

Browsers handle incomplete chains by downloading missing intermediates (AIA fetching). Agent frameworks and server-side TLS clients generally do not. A server that passes browser testing with an incomplete chain will fail when called from a Python or Node.js agent.

The fix is simple: include the full certificate chain in your server's TLS configuration. In nginx, use the ssl_certificate directive pointing to a file that contains both your leaf cert and the intermediate. In Caddy, the chain is assembled automatically.

Subject Alternative Name matching

The Common Name (CN) field in a certificate has been deprecated for hostname verification since RFC 2818 was clarified in practice. All modern TLS clients verify the Subject Alternative Name (SAN) extension. A certificate with only a CN field, no SANs, will fail in modern agent frameworks even if the CN matches the hostname. If you generated your certificate without specifying SANs, regenerate it.

Wildcard certificates are valid as SANs. A certificate for *.example.com covers mcp.example.com but not api.mcp.example.com (wildcards don't span subdomains). If your MCP server is at a multi-level subdomain, you need either a specific SAN for that subdomain or a multi-level wildcard (which most CAs don't issue for standard pricing).

TLS version compatibility

TLS 1.0 and 1.1 are deprecated. TLS 1.2 is the current minimum for all agent frameworks. TLS 1.3 is supported by modern runtimes and offers slightly better performance (one fewer round trip on the handshake). If your MCP server is behind a reverse proxy or load balancer, the TLS version is controlled by the proxy, not your application code.

Most default configurations on modern systems (Caddy, nginx on Ubuntu 22.04+, AWS ALB) already enforce TLS 1.2 minimum. Legacy systems running on older Ubuntu versions or with hardened configurations that haven't been updated may still allow 1.0 or 1.1. Check with openssl s_client -connect your-server:443 -tls1 — if it connects, 1.0 is allowed; if the handshake fails, you're safe.

Certificate management for MCP servers in practice

Let's Encrypt auto-renewal with Caddy

Caddy (a popular reverse proxy for self-hosted MCP servers) manages TLS certificates automatically. It obtains certificates from Let's Encrypt, renews them 30 days before expiry, and reloads them without dropping connections. For most self-hosted MCP deployments, Caddy's auto-renewal is reliable — but it requires port 80 (for HTTP-01 challenge) or a DNS API key (for DNS-01 challenge) to be accessible at renewal time. If your firewall closes port 80 between deployment and renewal, or your DNS API key rotates, the renewal fails silently and the cert expires.

Cloud-managed certificates

AWS Certificate Manager, GCP Managed SSL, and Azure App Service Managed Certificates all handle rotation automatically and are tightly coupled to the load balancer or ingress. The renewal is handled by the cloud provider with no expiry risk for standard deployments. The gap is elsewhere: these certificates are attached to the load balancer, and the TLS termination happens there. Your MCP server itself receives plain HTTP from the load balancer. This means certificate monitoring at the load balancer layer (cloud console) and certificate monitoring from the external client's perspective (AliveMCP) may diverge if a misconfiguration routes traffic to the wrong backend.

Mutual TLS (mTLS)

Some private or enterprise MCP deployments use mutual TLS to authenticate both the server and the calling client. In mTLS, the MCP server presents a server certificate (same as standard TLS) and also requires a client certificate from the agent. Client certificates have expiry dates too, and they are often managed manually — making them a higher expiry risk than server certificates managed by automated CA pipelines. If you use mTLS, your certificate monitoring needs to cover client certs issued to your agent deployment in addition to the server cert.

How AliveMCP monitors TLS health

Every probe AliveMCP runs against a public MCP endpoint includes a TLS handshake check. The probe reports:

A certificate error at the handshake layer is classified as a hard-down event — equivalent to the server refusing connections. The same three-consecutive-probe threshold that governs protocol-level downtime applies: three failed TLS handshakes in a row before marking the server down, to avoid false positives from transient network path issues.

On Author tier, you can configure expiry alerts for any server you own. AliveMCP fires a webhook alert (Slack, email, or PagerDuty) at configurable lead times — 30, 14, and 7 days by default — so you have ample time to rotate the certificate before any agent experiences an outage.

Get early access

Related questions

Do I need a separate certificate for each MCP endpoint?

No. A wildcard certificate covers all subdomains at one level (e.g., *.example.com covers mcp.example.com, api.example.com, etc.). If all your MCP servers are under one domain, a single wildcard cert covers them. You can also use a multi-SAN certificate that explicitly names multiple hostnames. The number of certificates you manage is a question of your PKI architecture, not a per-endpoint requirement.

Why does my MCP server pass browser testing but fail from an agent?

Two common causes: (1) incomplete certificate chain — browsers download missing intermediates automatically; agents don't. (2) The browser's certificate store includes root CAs that your agent runtime's trust store doesn't. Check the chain with openssl s_client -connect your-server:443 -showcerts and verify that the intermediate is included in the output.

How do I monitor a private MCP server with no public internet access?

External monitoring services (including AliveMCP) can only reach publicly accessible endpoints. For private MCP servers behind a VPN or in an internal network, you need an internal monitoring agent that has the same network access as your agent runtimes. AliveMCP's architecture notes for private fleets are covered in the Team tier documentation.

What happens to active MCP sessions when a certificate is rotated?

TLS sessions are negotiated per-connection. Rotating a certificate while connections are in flight doesn't immediately break those connections — the existing sessions continue with the old certificate until they're torn down. New connections after the rotation use the new certificate. In practice, because MCP clients typically open new connections for each agent turn, rotation is low-risk even during active use.

Further reading