On 13.01.2012 01:02, Dave Thompson wrote: >>> 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.
Ah, I figured I'd have to go there. The reason why I was hoping to get around this is that the OpenSSL code is properly reviewed and auditted -- I would rather not write code which could have serious sercurity implications if it's broken (especially since it's not properly reviewed). >>> 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. Thank you for your clarification. I also do not really see the point why the anchor of trust has to be self-signed. In my scenario this restriction actually makes the whole system less secure (since it allows a superset of certificates to be valid instead of just a tiny subset). I'll have a look into the custom verify-peer-callback and see how difficult it is and how easily it can be used. Best regards, Joe ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
