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

Reply via email to