> From: [email protected] On Behalf Of Harald Latzko > Sent: Friday, 03 August, 2012 03:02
> Am 03.08.2012 um 03:55 schrieb Dave Thompson: > Yes, the hash link (<hash>.0) exists and after the first > connect failed, I double-checked the linked openSSL version > against the commandline tool version. <snip> Good. (original problem in app was) > >> certificate verify error 20: unable to get local issuer > certificate: <snip> > >> A connect via "openssl s_client" also fails with <snip: > verify error 21> > > > > You show only the last part (resulting SSL-Session). > > I got as the first thing (except DN trimmed for posting): > > CONNECTED(00000003) > > depth=0 emailAddress = [email protected], ... > > verify error:num=20:unable to get local issuer certificate > > verify return:1 > > depth=0 emailAddress = [email protected], ... > > verify error:num=21:unable to verify the first certificate > > verify return:1 > > > > Note that you get error=20 first, and only after s_client overrides > > (which your app presumably doesn't) then you get error=21. > You're right, my apps doesn't override error 20 > (X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY) because it's > seen critically as a security hole if it would allow the > client connect to an unknown communication partner. It this > is not an usual security practice, please let me know (my app > is designed to be "as-secure-as-possible"). > Yes, to be safe your app should treat this as an error. I was pointing out s_client first gets the *same* error (20), and later gets a different error (21) only because it overrides, because s_client was designed mostly as a manual test&debug tool. I.e. the error is 20 not 21. I put the cert in a file and did commandline verify, and that also says error 20. So I debugged that, and it sort of isn't 20; see below. > > Error=20 means it didn't find the cert in the truststore. > > As above, check it is in the directory with the correct hash. > See above: it's the case actually. > > > > Errors in cert attributes (like BC) give other error codes. > Are there any more errors? I can't see any. Another point to There are lots of other errors possible from X509_verify_cert. See X509_V_ERR_* in x509_vfy.h. > be examined could be if the self-signed certificate isn't > really self-signed, but signd with a key whose certificate's > subject is just equally the same value, but whose private key > is a different that the one used for generating the > self-signed certificate itself (say: if there's a mistake in > self-signing, and something evil happened during the creation > of the self-signed certificate, another instance signed the > certificate which uses the same subject). Possible? > If a supposedly selfsigned cert wasn't actually signed by its own key, yes that would be bad. But this specific cert is okay: sha1 of the TBS portion (SEQUENCE starting at 4) is fa1e7834c1abf2d21cd453810ca0af941e861595 and rsautl -verify of the signature starting at 776 using the pubkey in the body is 0000 - 30 21 30 09 06 05 2b 0e-03 02 1a 05 00 04 14 fa 0!0...+......... 0010 - 1e 78 34 c1 ab f2 d2 1c-d4 53 81 0c a0 af 94 1e .x4......S...... 0020 - 86 15 95 ... which matches. (It's SEQUENCE of AlgId plus OCTETSTRING hash.) > >> Is my assumption correct that the "CA"-flag must be set to "true" > >> in order to work as a self-signed server certificate? I don't want > >> to change my verify_callback function just in order to get it work > >> (which could be easy). Conformity should be the first goal. > > No. CA:true, and (usually) KeyUsage:certSign, are required > > IF a cert (often, but not necessarily, selfsigned) is used > > to issue *other* (child) certs. I was only half-right. OpenSSL X509_check_issued is called to check *both* self-issued and parent-issued, and (always) requires that KeyUsage contain certSign or be absent. But this cert has KeyUsage without certSign. _check_issued actually returns a specific error code 32 _NO_CERTSIGN, but that gets swallowed by the chain-build logic and returns as 20 UNABLE*GET*LOCAL > My assumption of a chain of trust is that the end of a trust > chain is reached (=a server or client certificate is seen as > valid and secure) if the whole chain of certificates ends in > an entifiy where subject=issuer and CA:true (and > mathematically verification of the signed certificate is > true). In the past, this was a perfectly explainable > environment for all issues about certificate chains and > trust. How is then trust handled (if the above mentioned > method for linking trust via subject hash is used) for > self-signed certificate in general? > As Jacob says, many now agree that the chain can stop at any "anchor" which is manually approved, whether that is a root (selfsigned) or not, but OpenSSL (at least through 1.0.0i) still implements going to a root. The trust linking is done by matching child.issuer to parent.subject, and if present also child.AKI to parent.SKI or parent.(issuer&serial). The subject-hash links (or names) are only used in CApath mode to find the file(s) that should contain the parent cert. For a self-signed entity cert, that cert is its own chain. It is either in the truststore or not, but it can't link trust to a parent because it has no parent. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
