Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 1/2/17 10:02 PM, Tom Lane wrote:
>> Before we leave this area, though, there is a loose end that requires
>> more thought. That is, what about passphrase-protected server keys?
> I don't have experience with this in practice, but my hunch would be
> that you can continue to use passphrases as before, but the new reload
> functionality is effectively not supported. That is, if you use
> passphrases and make a key change, you need to do a full restart.
Um, no, that's not the situation. Since we reload the SSL_CTX each
time we get SIGHUP, and no information is carried forward from the
old SSL_CTX, a passphrase-protected server key causes the postmaster
to freeze at SIGHUP until somebody types a new passphrase on its
/dev/tty. (I've just verified this: it stops accepting connections
or indeed doing anything at all.) In the likely event that /dev/tty
no longer opens successfully, it would report failure of the SSL
reload and stop accepting new SSL connections. Even if you thought
the previous behavior was useful, this completely isn't.
If there were a way to carry forward the decrypted key from the old
SSL_CTX to the new one, we could perhaps preserve the old behavior.
But I don't know of one, and even if there is one, it's likely very
OpenSSL-specific --- do we want to assume that every TLS implementation
will support that?
regards, tom lane