Dave -

Thanks much!

> If the filename can't be opened SSL_CTX_load_verify_locations returns
false. Your code does check for that, I hope.

Good to know. Thanks. (Sometime APIs just "stash" a name somewhere for use
later.) Yes, I check every return code and put out a good error message if
the call fails.

> the Windows *API* has no problem with space in filename (unlike some
Windows *UIs*).

Like, say, VBA, or at least the MS-Word fields.

> And it actually accepts either slash or backslash separator

Right, I knew that, but I should remember it with MS-Word (which I use a lot
for documentation). Not having to escape \ would be a small step forward.
Thanks.

> Make sure ... the Subject and Issuer names are *exactly* the same

> if your self-signed cert has a KeyUsage extension that does not include
certSign, 
> OpenSSL skips it for chain-building, resulting in verify 20.

Looks like the latter to me. Please look below and tell me if you don't
agree. If so, I fear it is unsolvable, but it does not really matter as the
Kiwi is just for testing and if I know why it is failing that is almost as
good as it succeeding. I can bypass the verify failure and use it to test
everything else. My own client and server with a more conventional cert and
CA setup is verifying.

Here is a little of the s_client output:

depth=0 /CN=KiwiServer
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /CN=KiwiServer
verify error:num=21:unable to verify the first certificate
verify return:1

And here is the certificate -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            62:72:81:ef:1c:37:e2:9b:4f:ce:08:bb:a6:bf:82:03
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=KiwiServer
        Validity
            Not Before: Jul 27 21:05:20 2012 GMT
            Not After : Jul 27 00:00:00 2013 GMT
        Subject: CN=KiwiServer
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    <snip>
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage:
                Key Encipherment, Data Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
    Signature Algorithm: sha1WithRSAEncryption
        <snip>
-----END CERTIFICATE-----

Charles

-----Original Message-----
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson
Sent: Monday, August 13, 2012 7:09 PM
To: openssl-users@openssl.org
Subject: RE: CA for IIS-issued self-signed certificate?

> From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills
> Sent: Saturday, 11 August, 2012 08:57

> I wondered if perhaps there were path or filename specification 
> problems (need to escape backslashes? a problem with embedded spaces?) 
> but I eliminated all of those variables -- put the certificate with a 
> "simple"
> name in the current path.
> 
If the filename can't be opened SSL_CTX_load_verify_locations returns false.
Your code does check for that, I hope.

FWIW, the Windows *API* has no problem with space in filename (unlike some
Windows *UIs*). And it actually accepts either slash or backslash separator
(and sometimes slash is more convenient). 

> What do I look for? How do I get more granularity than "unable to get 
> local issuer certificate"?
> 
Top-level cut: do you get the same error (verify 20) with s_client?
If so, the problem is either the cert or the truststore, and you're
confident of the truststore. Make sure the description as self-signed (or at
least self-issued) is correct, i.e. the Subject and Issuer names are
*exactly* the same. If s_client works, the problem is almost certainly (say
99.9%) in your code.

This reminds me of one possibility that came up with someone else a few
weeks ago: if your self-signed cert has a KeyUsage extension that does not
include certSign, OpenSSL skips it for chain-building, resulting in verify
20. If you look at the cert with the usual Windows tools (inetcpl,
CryptExtOpenCER, mmc) you should be able to see if KeyUsage is present and
if so what is in it, or you can use commandline openssl x509 -text.

If neither of the above, you probably do need to debug, but:

> I'm using a pre-built Windows distribution of OpenSSL 1.0.1c. 
> It will take
> some re-arrangement to be able to trace into OpenSSL.
> 
That's unfortunate.

> 64-bit Windows, if that matters.
> 
It shouldn't, but if there's a bug somewhere, it might.

<snip previous>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to