MongoDB TLS certificate expired

Applications log SSL handshake failed: certificate expired while the health endpoint on HTTP still returns OK—mongodb tls certificate expired hits the net.tls listener on mongod, not your app’s public REST certificate.

MongoDB enables TLS on mongod and mongos with PEM paths in configuration file or Kubernetes operator CRD. Drivers verify server cert unless tlsInsecure was enabled in panic. x.509 user authentication adds client cert expiry that rejects auth before SCRAM.

Atlas hides PEM management; self-managed and DocumentDB-compatible clusters require operators to track notAfter on every replica set member and on load balancer VIP if TLS terminates in front of the database.

First response

Capture driver error, connection string host list, whether mongodb+srv or direct, and MongoDB version. On a server:

grep -E 'tls|certificateKeyFile|CAFile' /etc/mongod.conf
openssl x509 -in /etc/ssl/mongodb.pem -noout -dates -subject
echo | openssl s_client -connect mongocfg.example.com:27017 -servername mongocfg.example.com 2>/dev/null | openssl x509 -noout -dates

For replica sets, openssl each member FQDN clients use—not only the primary—because drivers may connect to secondaries during failover.

What this error means

TLS handshake completes only if server leaf and issuing chain are within validity. Expired notAfter on mongod certificate fails all encrypted connections including inter-node replication when clusterFile expired.

x.509 client auth compares user cert dates at authentication layer—user sees auth failure distinct from server cert expiry but logs look similar. tlsAllowConnectionsWithoutCertificates does not bypass server cert expiry.

mongosh with --tls uses the same PKIX rules as language drivers (pymongo, mongo-java-driver).

Application health checks that hit HTTP admin APIs on sidecars can stay green while every database connection string with TLS enabled fails—on-call dashboards look contradictory until you separate app HTTP probes from mongodb+srv dial errors.

Sharded clusters route through mongos; expired cert on one shard primary does not always fail reads routed elsewhere until scatter-gather queries hit the sick shard, producing flaky 500s mistaken for application bugs.

Change streams and transactions hold connections longer; pools negotiated before server cert expiry may appear fine until recycle triggers mass handshake failure seconds after notAfter midnight.

Common causes

Rolling PEM update on primary only; secondaries still serve old cert when application fails over. Cert-manager issued new secret in Kubernetes; StatefulSet volume mount updated but mongod not SIGUSR1/restart to reload (version-dependent).

Corporate CA renewed internal CA; operators updated server cert but left old CAFile, causing trust failures misread as server expiry. DBA renewed server cert; application-side tlsCAFile still points to retired intermediate with past notAfter.

Load balancer SSL cert renewed while backend mongod uses separate expired PEM for 27017—openssl the port clients open, not the LB admin UI cert.

MongoDB Kubernetes operator rolling cert rotation without sequential member restart leaves replica set members on three different notAfter dates during the window—drivers using SRV round robin see probabilistic success.

Percona or Enterprise patches that relocate default PEM paths in documentation without updating live config leave operators editing the right dates on wrong files.

Backup agents using TLS to mongod for logical dump share driver stacks with production microservices but use different connection strings—backup failure alerts may be the first signal while OLTP appears fine on pooled connections.

Confirm from the outside

OpenSSL to MongoDB port

openssl s_client -connect mongo1.example.com:27017 -servername mongo1.example.com </dev/null 2>&1 | grep -Ei 'notAfter|expire|Verify'

mongosh

mongosh "mongodb://user:pass@mongo1.example.com:27017/?tls=true" --tlsCAFile /path/ca.pem 2>&1 | head -20

All members

for h in mongo1 mongo2 mongo3; do
  echo "== $h =="
  echo | openssl s_client -connect "${h}.example.com:27017" -servername "${h}.example.com" 2>/dev/null | openssl x509 -noout -dates
done

How to read the output

Uniform future notAfter across members after rotation. If LB terminates TLS, openssl the LB VIP; if clients use TLS to mongod directly, test each hostname in SRV records.

When x.509 user auth is enabled, capture whether failure is server or client layer—mongosh with client cert and verbose TLS logging separates auth rejection from server expiry.

Compare notAfter on clusterFile used for inter-member TLS with certificateKeyFile presented to applications; dual PEM setups often renew only one file during rushed incidents.

Fix checklist

1. Inventory PEM locations: certificateKeyFile, CAFile, clusterFile for internal auth.
2. Issue renewed certs with SANs matching replica set hostnames in connection strings.
3. Replace PEM on disk or K8s secret; ensure combined PEM includes key + cert + chain as your version docs require.
4. Rolling restart: secondaries first, step down primary last, or use ops manager rolling procedure.
5. Update application trust stores if CA rotated—not only server leaf extension.
6. Re-enable any temporarily enabled tlsInsecure flags in apps.
7. Validate replication lag and auth for x.509 users after rotation.
8. Store redacted openssl transcripts in ticket.

Maintain replication during rotation: monitor replSetGetStatus lag after each secondary restart before touching primary.

For sharded topologies, rotate config server and shard certs in documented order; test mongosh through mongos after each shard reaches uniform dates.

If CA rotated, schedule coordinated application deployments with new ca.pem bundles—rolling only servers strands half the fleet in trust errors.

Remove emergency tlsInsecure flags under change control with ticket linking to renewed serial numbers so security audits see intentional temporary relief ended.

Post-fix load test with connection pool churn to force fresh handshakes—soak tests catch lingering members still on expired material.

When to use automation

Database cert monitoring via disk mtime is insufficient—probe live 27017 TLS (or your net.tls.port) with openssl or mongosh from the application network zone.

/check applies when MongoDB is reached through a TLS-terminating proxy with a public hostname; self-managed east-west checks need internal synthetics. Pair with Elasticsearch X-Pack SSL expired for observability stack parity.