Re: BUG #5468: Pg doesn't send accepted root CA list to client during SSL client cert request

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Tue, May 25, 2010 at 17:48, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> writes:
>>> Bug 5245 is not the same issue. They're talking about the server not
>>> sending the full certificate chain for the cert that identifies the
>>> server (server.crt). It's nothing to do with client certificates.
>>> Without the full chain, the client can't verify the server unless it
>>> happens to already have the intermediate certs between the server's cert
>>> and the trusted root that signed it installed locally. I haven't
>>> encountered #5245 myself, but will test it shortly to verify. It'd
>>> certainly count as a significant bug, as it would make it impossible to
>>> use indirect trust to verify a server (as is the case when a corporate
>>> CA signed by a "big name" CA is in use).
>>
>> BTW, does anyone know exactly how to fix that? I'm looking at a related
>> request internal to Red Hat right now.

> I have it on my TODO to figure it out, but from what I can tell it's
> very close to being undocumented, like most of OpenSSL.

I spent some time experimenting with this. I set up a self-signed root
CA, then an intermediate CA signed by the root, and then created server
and client certs signed by the intermediate CA. I find that everything
appears to work just fine if (1) the server's root.crt contains both the
intermediate and root certs, and (2) the client's root.crt contains the
root cert. (Most other combinations don't work, in particular if I give
the client only the intermediate CA's cert, it rejects connections.)

This leaves me a bit mystified as to what all the squawking is about.
IIUC, putting the full chain of CA certs into server.crt is the standard
way to set up a server that is signed by a non-root CA. Maybe we just
need to document that? It certainly appears to me that the server sends
all those certs to the client, because the client wouldn't be able to
verify the server's cert without the intermediate CA cert, which it
hasn't got on its end.

(Either that, or there's something seriously broken in libpq's checking
of server certs :-()

I notice that the complaint in bug #5245, like the one in #5468,
refers specifically to Java client behavior. I'm suspicious that
what we're dealing with is a Java requirement that openssl itself
does not have.

regards, tom lane