TLS 'certificate has expired' after credential renewal: does Node.js reload the secureContext automatically?

Answer to the three questions

1. SecureContext is never re‑read from disk automatically. The key, cert, and CA chain are loaded into memory when tls.createSecureContext() (or the HTTPS server constructor) runs. To use new files you must explicitly call server.setSecureContext() or rebuild the server.
2. Replacing the context only influences handshakes that start after the call. Existing TLS sessions keep using the old context until they close naturally.
3. With rejectUnauthorized: true the TLS layer itself rejects an expired client certificate during the handshake. The application does not need to perform this check; it will be surfaced as a clientError event on the server and as an error on the client socket.

Why the old context stays in use

When a server starts, Node.js creates a SecureContext that holds the PEM material in memory. Subsequent reads of the certificate files do not affect that in‑memory object. That is why you saw "certificate has expired" errors after the renewal files appeared on disk – the server was still presenting the old cert.

Practical rotation steps

1. Watch the certificate files (e.g., fs.watch or a cron‑job). When a new cert/key pair is written, read the new PEMs into a buffer.
2. Build a fresh context: const ctx = tls.createSecureContext({ cert, key, ca });
3. Replace the server’s context atomically: httpsServer.setSecureContext(ctx);
4. Verify that new connections succeed and that old connections continue to use the previous cert until they finish.

Mutual TLS and client certificate expiry

The TLS handshake validates the client’s certificate chain before the connection is established. If the client cert is expired, the handshake fails and the server emits a clientError event with an error code such as ERR_TLS_CERT_ALTNAME_INVALID or ERR_TLS_CERT_HAS_EXPIRED. Your application can listen for this event to log or take action, but the rejection itself is guaranteed by the TLS layer.

Things to double‑check

• Confirm which certificate is actually expiring – server or client – by inspecting the error’s certificate property or the handshake logs.
• Make sure the CA chain is also refreshed if the internal CA’s validity period is short; a new server cert signed by an old CA will still fail.
• Verify the Node.js LTS version in production. The behaviour of setSecureContext and the clientError event is consistent across 18+, 20+, and 22+, but checking the exact docs for your version is safest.

In short, Node.js does not reload a SecureContext automatically. Explicitly replace it with setSecureContext() for short‑lived credentials, and trust the TLS layer to reject expired client certificates.