> From: owner-openssl-us...@openssl.org On Behalf Of Michael S. Zick > Sent: Thursday, 12 January, 2012 13:24
> On Thu January 12 2012, Johannes Bauer wrote: > > Hello group, > > > > I have a question regarding the verify method of OpenSSL: If I have a > > certificate chain: Root -> A -> B -> Leaf [...] > > is it valid for the webserver to provide only A/B/Leaf > > and omit "Root" during the SSL handshake? [...] > > It is a "third party" verification system that is used. > How could you trust the server to tell you itself who it is? > > Thus, the need for obtaining the root certificate some way > other than having it sent by the server in question. > Exactly. Which in OpenSSL is usually 'CAfile' or 'CApath'. > And yes, 'root' certificates are self-signed, > signed by an 'independent' third party in the business > of being trusted for that purpose. > Nit: not necessarily in the 'business' of being trusted. Just some party which IS trusted. For example some part(s?) of the US DoD issue certs for employees and contractors. The DoD's 'business' is preparing to do and doing military actions directed by the elected government (which should do so in the interests of the country, but that's a different issue and offtopic here). Issuing certs is a minor sideline. Most(?) of the well-known public CAs were created solely to be CAs, but many(?) of them have been acquired by businesses which have other functions as well. > Which in this post, the 'trusted third party' seems to be > your own network admin (which may be yourself ;-) ) > Exactly. This is similarly a sideline. > Mike > > Also, when I have certificates A + B and do: > > > > $ openssl verify -CApath /sys -CAfile certA.crt certB.crt > > certB.crt: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 > > VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public > > Primary Certification Authority - G5 > > error 2 at 1 depth lookup:unable to get issuer certificate > > > > (I'm only using /sys to make openssl not pull in /etc/ssl/certs) > > > > The verify fails. Why is that? The immediate signature is valid, does > > the "verify" command expect to always terminate at a self-signed > > certificate? > > Yes. Or rather the libcrypto routine X509_verify_cert, used by the 'verify' utility and also the SSL handshake logic and also other applications if they wish, insists on reaching a root. > > Or, in other words: Let's assume I have a ultimate root > (self-signed) > > "Root" and a branched CA "X". I would like to trust "X" and all it's > > children, but not "Root". Is this not possible? > > Not in OpenSSL, unless you change the verify logic, or replace or override it with your own (which AFAICS could be done, with some effort, using the optional verify callback). It's not clear to me this is the best policy choice; IE (or I believe actually some Windows feature IE uses) and Firefox and Java (JSSE) all allow you to establish a non-root as a trust anchor. But it's what OpenSSL does, and has for a long time. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
