On Thu, Mar 21, 2013 at 01:42:55PM +0800, Craig Ringer wrote:
> On 03/19/2013 09:46 PM, Stephen Frost wrote:
> > * Craig Ringer (craig@2ndquadrant.com) wrote:
> >> As far as I'm concerned that's the immediate problem fixed. It may be
> >> worth adding a warning on startup if we find non-self-signed certs in
> >> root.crt too, something like 'WARNING: Intermediate certificate found in
> >> root.crt. This does not do what you expect and your configuration may be
> >> insecure; see the Client Certificates chapter in the documentation.'
> >
> > I'm not sure that I follow this logic, unless you're proposing that
> > intermediate CAs only be allowed to be picked up from system-wide
> > configuration? That strikes me as overly constrained as I imagine there
> > are valid configurations today which have intermediate CAs listed, with
> > the intention that they be available for PG to build the chain from a
> > client cert that is presented back up to the root. Now, the client
> > might be able to provide such an intermediate CA cert too (one of the
> > fun things about SSL is that the client can send any 'missing' certs to
> > the server, if it has them available..), but it also might not.
> >
>
> Drat, you're quite right. I've always included the full certificate
> chain in client certs but it's in no way required.
>
> I guess that pretty much means mainaining the status quo and documenting
> it better.
I have developed the attached patch to document this behavior. My goals
were:
* clarify that a cert can match a remote intermediate or root certificate
* clarify that the client cert must match a server root.crt
* clarify that the server cert much match a client root.crt
* clarify that the root certificate does not have to be specified
in the client or server cert as long as the remote end has the chain
to the root
Does it meet these goals? Is it correct?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
