All,
Sorry, I havn't really been following this thread.
* Craig Ringer (craig@postnewspapers.com.au) wrote:
> #5245 is about *CLIENT* *VALIDATION* *OF* *THE* *SERVER*, where the
> *CLIENT* VALIDATES THE *SERVER* after the server sends a
> CertificateRequest.
>=20
> For #5468 to be addressed, the server must send the CA certificates (not
> necessarily the full chain) of any CAs it trusts to identify clients to
> the client during the optional CertificateRequest phase of SSL
> negotiaton. This is only important if clientcert=3D1 is specified in
> pg_hba.conf .
Yeah, this is right. I've had similar issues in the past, and what's
better, some systems are too stupid to realize that they need to ignore
CAs which aren't ones that they trust (hello Winbloze IPSEC). Being
able to specificially say what CA cert should be sent to a given client
in pg_hba.conf would certainly be nice. I don't know if any of the
systems which talk to PG will have this problem (hopefully they'll all
use libpq...), but it's definitely something I've run into in the past.
> Java, exactly like OpenSSL, needs *SOME* way to obtain any certificates
> between the a CA the client trusts and the server's certificate. If the
> client has the required intermidiate certs pre-installed, the server
> doesn't have to send them. If the client doesn't have them
> pre-installed, the server must send them or the server has no way to
> verify the chain of trust.
>=20
> This is bog-standard SSL stuff.
Right, this should be supported and handled correctly (though, to be
fair, alot of times people just configure the clients with the
intermediate certs needed.. I realize that's not ideal though, since
they can change over time and make things more difficult.).
> > In any case I'm thinking that we need to document how to set up
> > configurations with chains of CA certs.
>=20
> Yes, and patch the server to send the list of trusted CAs to the client
> during client certificate negotiaton to fix #5468 .
Agreed.
Thanks,
Stephen
