* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > At least I think that was the issue, rather than requiring the client to
> > supply a "root" certificate, meaning the client can supply an
> > intermediate or root certificicate, as long as it appears in the
> > root.crt file on the remote end.
>
> As far as the server is concerned, anything listed in its root.crt *is* a
> trusted root CA. Doesn't matter if it's a child of some other CA.
I was afraid that was the case.. Are we sure that's *still* being done?
I recall there being discussion around this previously because it's
surely wrong from a certificate trust perspective. At the same time,
I'm not sure what options we have because of the existing GUCs and the
APIs we use to talk with OpenSSL- that might just be how it works
because we don't allow the user to provide a seperate file of
intermediate CAs. This is one reason why I've generally encouraged use
of the system-wide OpenSSL configuration directories and minimizing the
configuration done in the PG files for certificate-based connections.
> The issue is that the client's cert has to be linked to some element of
> root.crt somehow. In principle you'd think that if the client provides
> an intermediate CA cert, the server should be able to match that to
> whichever root.crt member signed it, but that wasn't what I saw
> happening. It'd be good for someone who uses SSL more than I do to
> replicate the experiment, though. It's not impossible that I screwed up.
Right, we have to be able to go from the client's cert up through to the
root certificate. That 'root' certificate might possibly be anything
we've told OpenSSL is a 'root' even when it's actually an intermediate
CA, but in the 'outside' certificate world, the root CAs and the
intermediate CAs are configured independently.
Thanks,
Stephen