Reload certificate files of https.createServer() without restarting node server

[nolimitdev]

Hi, letsencrypt certificate files expires each 3 months. Is there any way to refresh certificate files without restarting node server? Because using stale/expired certificate causes error ERR_INSECURE_RESPONSE in browser.

var fs = require('fs');
var https = require('https');
var ws = require('ws').Server;
var config = require('config.js');
var certificate = {
    key: fs.readFileSync(config.sslKeyPath),
    cert: fs.readFileSync(config.sslCrtPath),
}
var httpsServer = https.createServer(certificate).listen(config.port),
var wssServer = new ws({ server : httpsServer });

// I would like to reload certificate monthly...

// solution A): just update certificate.cer since variable certificate is passed to createServer() as reference because it is Object (not primitive value)
setInterval(function() { certificate.cert = fs.readFileSync(config.sslCrtPath); console.log("reload cerfificate A"); }, 1000 * 60 * 60 * 24 * 30);
// ... no success

// solution B): update directly httpsServer.cert (yes, this property exists when you console.log(httpsServer))
setInterval(function() { httpsServer.cert = fs.readFileSync(config.sslCrtPath); console.log("reload cerfificate B"); }, 1000 * 60 * 60 * 24 * 30);
// ... property is updated but no success

No solution works and node always use stale certificate for new incoming https requests and websocket connections too . It would be great to have a new method in returned Object from https.createServer() to reload certificate files e.g.:
httpsServer.reloadCertificate({key: fs.readFileSync(config.sslKeyPath), cert: fs.readFileSync(config.sslCrtPath)})
... now, new incoming https requests or websocket connections should be handled with new certificate files

[benjamingr]

That's interesting.

In practice, people solve this by running Node.js servers in a cluster of several instances, and then do a one-by-one update where severs individually go down and up with the new certificate so there is no runtime.

WebSocket requests require "draining", so you stop routing connections to the server and then restart it once all the existing requests are done.

I can see the use case here.

[mscdex]

FWIW you can already do this with SNICallback():

const https = require('https');
const tls = require('tls');
const fs = require('fs');
var ctx = tls.createSecureContext({
  key: fs.readFileSync(config.sslKeyPath),
  cert: fs.readFileSync(config.sslCrtPath)
});
https.createServer({
  SNICallback: (servername, cb) => {
    // here you can even change up the `SecureContext`
    // based on `servername` if you want
    cb(null, ctx);
  }
});

With that, all you have to do is re-assign ctx and then it will get used for any future requests.

[nolimitdev]

@mscdex thank you for great working fallback (already implemented) :)
So clients without SNI support will not connect now, yes? I know, it must be very old device which do not support SNI. Also option SNICallback seems to mean a little overhead or?

[mscdex]

@nolimitdev You should be able to still supply key and cert in the createServer() options in addition to SNICallback(). That pair should be used for non-SNI clients IIRC (this should be rare in this day and age though).

As far as overhead goes, it's just a couple of extra function calls really, I wouldn't be so worried about it.

[silverwind]

I wouldn't rule out non-SNI completely. There are still clients that don't support it or handle it inproperly, like the OpenSSL version included on the latest macOS ref.

I think adding a method to update server options at runtime would be nice to have. Similar to what is possible for ticket keys using setTicketKeys.

[bnoordhuis]

Duplicate of #4464?

[silverwind]

Yes, seems like a dupe.