On 26/05/10 09:35, Tom Lane wrote:
> I am now of the opinion that bug #5245 is in fact an exact dup of
> bug #5468. The previous reporter was jumping to conclusions about what
> his problem was: it was not that the server didn't send the full cert
> chain, but that Java couldn't do the right thing without having the list
> of cert names.
No, they ARE NOT the same thing.
#5468 is about *CLIENT* *CERTIFICATE* *AUTHENTICATION* where the
*SERVER* VALIDATES THE *CLIENT* after the server sends a
#5245 is about *CLIENT* *VALIDATION* *OF* *THE* *SERVER*, where the
*CLIENT* VALIDATES THE *SERVER* after the server sends a
You are confusing these two unrelated phases of SSL negotiation.
For the complaint in #5245 to be addressed, the server must send the
full certificate chain for the certificate the server is using to
identify its self as pgserver.domain.com to the client during the
ServerHello phase of SSL negotiation. If correctly configured, the
server already does this, and #5245 really just needs some documentation
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=1 is specified in
Sorry to continue "squarking" about this, but I just don't know how to
explain it any better without stepping through the full SSL negotiation.
It's frustrating that you're focusing on #5245 (which I didn't bring up
and isn't the same thing at all) and disregarding the issue I'm trying
to get fixed because #5245 is related to server misconfiguration.
Hang on, I'll send side-by-side comparisons of patched and unnpatched
server chat along with why they differ and why it's important in a min.
> It's possible, depending on exactly what Java does in these cases, that
> it has to have cert names given to it for the intermediate certs as well
> as the root.
(this relates to #5245 **NOT** #5468)
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.
This is bog-standard SSL stuff.
> In any case I'm thinking that we need to document how to set up
> configurations with chains of CA certs.
Yes, and patch the server to send the list of trusted CAs to the client
during client certificate negotiaton to fix #5468 .
Tech-related writing: http://soapyfrogs.blogspot.com/
In response to
pgsql-bugs by date
|Next:||From: Craig Ringer||Date: 2010-05-26 02:10:25|
|Subject: Re: BUG #5468: Pg doesn't send accepted root CA list to client
during SSL client cert request|
|Previous:||From: Tom Lane||Date: 2010-05-26 01:35:46|
|Subject: Re: BUG #5468: Pg doesn't send accepted root CA list to client during SSL client cert request |