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

We run a Node.js HTTPS server (current LTS line, using the built-in tls/https modules) with mutual TLS enabled and rejectUnauthorized: true. Client and server certificates are issued by an internal CA with short validity windows, so renewal happens on a schedule without restarting the process.

After a renewal, the new certificate and key files are written to disk, but existing and new connections still appear to be negotiated against the original SecureContext created at startup. Eventually peers begin failing TLS verification with certificate-validity errors such as certificate has expired, even though the renewed files on disk are valid. The only reliable workaround we have found is recreating the server or rebuilding the context with tls.createSecureContext().

The documentation describes server.setSecureContext() and the SNICallback option, but it is not clear to us what the intended lifecycle is for short-lived credentials in a long-running process, or which validation failures are surfaced to user-land versus handled internally.

Specifically:

• Is a SecureContext ever re-read from disk automatically, or must it always be replaced explicitly via setSecureContext()?
• Does replacing the context affect already-established TLS sessions or only new handshakes?
• For mutual TLS, is rejection of an expired client certificate guaranteed by the tls layer, or is part of that validation left to application code?