Re: re-reading SSL certificates during server reload - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: re-reading SSL certificates during server reload
Date
Msg-id CABUevEwN6FujCXc7YDLax2UFLrddYUHg=MEeTX_dbEYUqUQR6g@mail.gmail.com
Whole thread Raw
In response to re-reading SSL certificates during server reload  (Alexey Klyukin <alexk@hintbits.com>)
Responses Re: re-reading SSL certificates during server reload
Re: re-reading SSL certificates during server reload
List pgsql-hackers
On Wed, Aug 27, 2014 at 11:56 AM, Alexey Klyukin <alexk@hintbits.com> wrote:
> Greetings,
>
> Is there a strong reason to disallow reloading server key and cert files
> during the PostgreSQL reload?

Key and cert files are loaded in the postmaster. We'd need to change
that. I'm not saying that's not a good idea, but it's not as easy as
just allowing it :)


> Basically, once you run multiple databases in a cluster and use different
> DNS names to connect to different databases (in order for those databases to
> be moved somewhere without changing the client code), and enable SSL
> certificate checking, the problem becomes evident: in order to add a new
> database to the existing cluster you have to add its name to the SSL
> certificate for the server, and in order for this changes to come into
> effect you have to restart the server.

That's certainly an issue. Potentially bigger ones are that you cannot
replace an expired certificate or CRL without a restart.


> In the documentation for server cert and key file there is a notice that
> this parameter can only be reloaded during the server start. It seems that
> the only place the backend certificates are loaded is inside the
> secure_initialize, which, in order, calls initialize_SSL().
>
> From my point of view, I see nothing preventing separation of the
> certificate reload code and SSL library initialization and calling the
> former during the server reload.  It might happen that with the new
> certificate file that some of the existing connections will be unable to
> reconnect, or, if the certificate is invalid, the server will be unable to
> restart, but this are the sort of problems that also happen with reload of
> pg_hba.conf as well, so these alone does not sound like a significant
> showstopper.

I agree that separating this out would probably be a useful idea. We
should probably treat a failed load of cerrtificates the same way we
do with pg_hba if we can - which is log an error and revert back to
the currently loaded one.

Some of this is going to have to be at least partially reworked anyway
in the work that Heikki has been diong to support non-openssl
libraries. Making a change like this at the same time is probably a
good idea.


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: postgresql latency & bgwriter not doing its job
Next
From: Magnus Hagander
Date:
Subject: Re: Sample LDIF for pg_service.conf no longer works