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

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> What I meant to question is *which* file the intermediate CA certs
>> go into. It doesn't seem tremendously sensible to me to put them into
>> the server.crt file, since that's intended to define exactly one cert,

> root CA's are self-signed. intermediate CAs are not. They typically
> both go into directories/files like 'cacerts' (eg: Strongswan expects
> them in the cacerts directory). Most systems (uh, all?) will validate
> all the way up to a self-signed cert- intermediate CAs are only used as
> a mechanism to get to the root CA. I don't believe there's any
> confusion about intermediate CAs being accepted as root CAs just because
> they're in the same file or directory.

> All that being said- I don't think anyone would really complain if
> intermediate CAs and root CAs were stored in different
> directories/files. That's how Windows has certificates separated out.

After some more testing I think I've wrapped my head around how this
really ought to be documented, and it goes like this:

* server.crt is about proving the server's identity to the clients.
It must contain a cert or cert chain that leads to a CA that is trusted
by the clients (ie, is listed in the client-side root.crt files).

* root.crt is about proving the clients' identities to the server.
It lists the root CAs that the server trusts for that purpose.

* Similarly, the client-side postgresql.crt contains a cert (or,
if we fix libpq's bugs, a cert chain) that leads to a CA trusted
by the server, while the client-side root.crt lists the root CAs
that the client trusts for verifying the server.

In principle, you could have the server and clients using totally
nonoverlapping sets of trusted CAs (nonoverlapping root.crt lists),
as long as each can chain its identity up to a CA the other trusts.
So it's all nice and symmetrical.

The experimentation I did earlier indicates that there's some leakage
whereby openssl will pick up intermediate certs that are listed in
root.crt and use them to form a chain supporting the server.crt
certificate, but that doesn't fit nicely into the mental model.
I'm now of the opinion that we shouldn't recommend or even document
that way of doing things.

regards, tom lane