mirror of
https://github.com/postgres/postgres.git
synced 2025-07-28 23:42:10 +03:00
Re-allow SSL passphrase prompt at server start, but not thereafter.
Leave OpenSSL's default passphrase collection callback in place during
the first call of secure_initialize() in server startup. Although that
doesn't work terribly well in daemon contexts, some people feel we should
not break it for anyone who was successfully using it before. We still
block passphrase demands during SIGHUP, meaning that you can't adjust SSL
configuration on-the-fly if you used a passphrase, but this is no worse
than what it was before commit de41869b6
. And we block passphrase demands
during EXEC_BACKEND reloads; that behavior wasn't useful either, but at
least now it's documented.
Tweak some related log messages for more readability, and avoid issuing
essentially duplicate messages about reload failure caused by a passphrase.
Discussion: https://postgr.es/m/29982.1483412575@sss.pgh.pa.us
This commit is contained in:
@ -2159,8 +2159,13 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The private key cannot be protected with a passphrase, as there is no
|
||||
way to supply the passphrase to the server.
|
||||
If the private key is protected with a passphrase, the
|
||||
server will prompt for the passphrase and will not start until it has
|
||||
been entered.
|
||||
Using a passphrase also disables the ability to change the server's SSL
|
||||
configuration without a server restart.
|
||||
Furthermore, passphrase-protected private keys cannot be used at all
|
||||
on Windows.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -2293,9 +2298,9 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
|
||||
<para>
|
||||
If an error in these files is detected at server start, the server will
|
||||
refuse to start. But if an error is detected during a configuration
|
||||
reload, the files are ignored and the old values continue to be used.
|
||||
On <systemitem class="osname">Windows</> systems, if an error in these
|
||||
files is detected at backend start, that backend will be unable to
|
||||
reload, the files are ignored and the old SSL configuration continues to
|
||||
be used. On <systemitem class="osname">Windows</> systems, if an error in
|
||||
these files is detected at backend start, that backend will be unable to
|
||||
establish an SSL connection. In all these cases, the error condition is
|
||||
reported in the server log.
|
||||
</para>
|
||||
@ -2314,8 +2319,8 @@ openssl req -new -text -out server.req
|
||||
you enter the local host name as <quote>Common Name</>; the challenge
|
||||
password can be left blank. The program will generate a key that is
|
||||
passphrase protected; it will not accept a passphrase that is less
|
||||
than four characters long. To remove the passphrase again (as you must),
|
||||
next run the commands:
|
||||
than four characters long. To remove the passphrase again (as you must
|
||||
if you want automatic start-up of the server), next run the commands:
|
||||
<programlisting>
|
||||
openssl rsa -in privkey.pem -out server.key
|
||||
rm privkey.pem
|
||||
|
Reference in New Issue
Block a user