https server should allow changing credentials dynamically

[petkaantonov]

We need to change the certificate info (credentials/secureContext) dynamically while the server is online without having to shut down and start a new server. We have patched node with code that enables this, but it would be nice to have it on upstream as well.

The API we have is:

---

server.setSharedCredentials(secureContext)

Used to change the server's TLS options such as the server certificate on the fly. secureContext must be an instance of SecureContext as is created with tls.createSecureContext().

---

After the call, if there were active sockets using old context, those sockets will be disconnected next time data is sent over them.

[bnoordhuis]

An API like server.setSharedCredentials(secureContext) seems like a reasonable if somewhat esoteric addition to me. This however:

After the call, if there were active sockets using old context, those sockets will be disconnected next time data is sent over them.

Doesn't seem so reasonable if the implication is that the server needs to track active sockets. If the logic is something like if (this._secureContext !== server._secureContext) this.destroy(); in socket.write() it might be more palatable.

/cc @nodejs/crypto

[indutny]

Perhaps it should be called secureContext and not sharedCredentials?

[indutny]

I don't really like disconnecting sockets either, IMO this is not reasonable and has way too much implicit behavior for suggested method name.

[rvagg]

@petkaantonov could you explain some use-cases for this? I can't imagine one so perhaps it'd be helpful for others as well to hear why this might be needed.

[tallskog]

The use case is an embedded system where https server is handling mission critical information. If administrator wants/needs to change the certificates, it will happen on the fly. Without this modification https server needs to be restarted leading to possible loss of data.

[petkaantonov]

If the logic is something like if (this._secureContext !== server._secureContext) this.destroy(); in socket.write() it might be more palatable.

Iirc this check was in the "data" event. It doesn't make sense to allow invalid certificate to be used.

[jasnell]

@petkaantonov ... still interested in this? I share some of the same concerns voiced already but would definitely welcome a PR to review.

[petkaantonov]

I could work on a PR this weekend

[voxsoftware]

This it's really necessary

[sam-github]

Without this modification https server needs to be restarted leading to possible loss of data.

By terminating existing connections when they try to write something, aren't you losing data?