On 8/3/2012 9:02 AM, Harald Latzko wrote:
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?
This rule is no longer entirely true.
The new rule is to stop when reaching a cert in your local trusted
or banned list, self-signed or otherwise, and to not check if the
self-signature (if any) is valid.
This is because of the following real world issues:
1. Some CAs are available both as self-signed and as cross-signed
by another CA (which you may or may not trust). Both variants of
such a CA have the same public key, algorithm, subject etc. but
have different issuer, signature, dates etc. Your trust list
may contain either variant, or only the other CA (in which case
you would see the CA as just another intermediary cert). For
example, at least one major CA has its root certs cross-signed by
the old "Equifax" root CA, to support clients with an old CA list.
As another example, signatures for Windows drivers are issued by
well-known CAs (Symantec, GlobalTrust), but are trusted via
a cross-cert issued by a dedicated Microsoft CA whose cert is
hard coded in the Windows boot loader (this is before "secure
boot" is added to the mix).
2. Some major valid CA roots were self-signed using algorithms
that are no longer secure (such as MD2), but currently issued
certificates from those roots are not. If you trust the CA
because its complete cert and public key are in your trust
list, it doesn't matter how it was self-signed.
3. Some Intermediary CAs (such as some from the Netherlands)
have been so thoroughly compromised they have been revoked
not only via CRLs, but also via hard coded untrust-lists in
various software (including OpenSSL). Thus if you hit one
of those in a certificate chain, you must stop the search
and declare the result (failure), and not continue to the
next higher cert, which is still trusted.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
