On 12.01.2012 19:05, Kenneth Goldman wrote: >> I have a question regarding the verify method of OpenSSL: If I have a >> certificate chain >> >> Root -> A -> B -> Leaf >> >> where "Leaf" is the certificate of a webserver (https) and Root is a >> self-signed certificate. >> >> In this scenario, is it valid for the webserver to provide only A/B/Leaf >> and omit "Root" during the SSL handshake? I'm seeing strange errors and >> noticed that a webserver of ours is configured in that manner (and it >> seems odd to me). > > It's more than valid. I think it's essential that the server omit the > root. > > If the server supplied the entire chain, they could create the entire > chain, and thus could claim to be anyone.
Hmm - I disagree with that assessment. The client has to check that the root (that the server may provide or may omit) is inside the trusted certificate store of the client -- regardless of the client provides it or not. And clients (and probably therefore OpenSSL) do that, too: When I for testing purposes create and send a complete certificate path for a SSL webserver, Firefox still rejects it as it should, because no certificate is in the truststore. > The root must be delivered out of band, trusted by other means. Correct. The question is just: can this root of trust be an intermediate certificate or must it be a self-signed certificate? Is this one of the checks that occurs within the OpenSSL client? To clarify what I mean, please consider the tiny picture at http://pastebin.ca/2102780 Let's say I have some "ultimate" root A which has issued a sub-CA "B" for me. I use "B" to create, for example, a certificate for my webserver "D". Now I have clients which should only connect to webservers that have been issued by "D". I configure the webserver to only send "D" certificate and have in my clients only one certificate in the certificate store: B. The clients cannot connect (cannot verify peer), because in the client's certificate store, A is missing (deliberately!). The reason why it is missing is the following: If I put A into the store of the clients, A might have issued a sub-CA certificate to my opponent C (which I do not have control over). C would sign a certificate for Eve which contains my server's DNS name as CN. Then when Eve would make a man-in-the-middle attack with it's fake webserver, my clients would still connect, since they can construct a path to the root A (E -> C -> A). I really hope I explained this well enough, it's kind of hard via mail, I'm afraid. Best regards, Joe ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
