Hello Dave, Am 03.08.2012 um 03:55 schrieb Dave Thompson:
> Aside: it's a good thing you gave the server, because Outlook > (which we use) blocks *.cer. I wish it didn't, but it does. I've reached this "great" functionality last week, too. There's a possibility to allow filename extensions ins outlook, so you might add "cer" (or was it ".cer"?) as allowed extension by adding a registry key named "Level1Remove" (type string) to HKEY_CURRENT_USER/Software/Microsoft/Office <your version here>/Outlook/Security (Outlook 2002) It's a comma-seperated list of allowed attachements which will be allowed to be displayed and downloaded in Outlook. >> The server certificate is trusted in a directory where trusted > certificates >> reside. In my application, a connect try ends with the following error: > Is the server cert in the directory named by tls_root_certpath > *with a hashlink (or hashname)*? For the correct major version > of OpenSSL? (hashes for 1.0.0+ are different from 0.9.8) 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. I also added an unneeded link named the old hashing method (parameter "-subject_hash_old" for openssl commandline tool). Since I've got a bunch of working connection via various CAs, I assume this mechanism works normally. >> certificate verify error 20: unable to get local issuer certificate: <snip> >> My opinion is that the self-signed certificate has the X509v3 basic >> constraint >> CA flag set to "false": <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 = deiningermichae...@johndeere.com, ... > verify error:num=20:unable to get local issuer certificate > verify return:1 > depth=0 emailAddress = deiningermichae...@johndeere.com, ... > 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"). > 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 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? >> 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. 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? Greetings, Harald______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
