* Bruce Momjian (bruce@momjian.us) wrote:
> Yes, this was my understanding. Let me ask a simple question --- can
> you put only the client cert on the client (postgresql.crt) and only the
> root cert on the server (root.crt), and will it work?
Only if the client cert is signed directly by the root cert, which is
generally discouraged.. The intermediate cert needs to be *somewhere*.
As for Tom's question about the client presenting an intermediate cert-
I don't know offhand if that works with our code, but as far as SSL
goes, last I checked it's *intended* to work.
> I think Tom's question is whether OpenSSL will read through all the
> entries in root.crt and find the one that signed the remote cert, and
> has it always done that, i.e. does the remote side have to provide the
> upper-level cert to match against.
Either side should be able to present certificates that build the chain
of trust. Practically speaking, that may not work due to sheer number
of combinations which you might end up with- I don't recall specifically
if that ends up being an issue or not (it's been a while).
> One big thing I learned from this is that the local root.crt is only
> used to verify remote certificates; it isn't related to how the remote
> end verifies your certificate. Now, in most cases, the root.crt is
> identical for clients and servers, but it doesn't have to be.
That's correct, yes.
> Put another way, I thought you put the root cert in your local root.crt
> and the local cert in postgresql.crt or server.crt, but in fact the
> requirement is that the local certificate chain to root must be in the
> remote root.crt.
Right.. You use your cert to prove to the *other* guy that you are who
you claim to be. Does that help in the understanding..? You don't need
to prove to yourself who you are..
> Of course, I might be wrong, but I am trying to clarify this for our
> users.
Thanks for working on this. I do wish we could improve how we handle
certificates in general- and that definitely goes for the documentation
as much as the various options we provide.
Thanks,
Stephen