> From: owner-openssl-us...@openssl.org On Behalf Of Tammany, Curtis
> Sent: Friday, 27 April, 2012 09:45
> To: st...@openssl.org; openssl-users@openssl.org
> Subject: FAILED:unable to get local issuer certificate
>
> We have an Apache 2.2.22/OpenSSL 1.0.1 CAC-enabled website
> running on Windows (XP for development and 2003 for
> production). We have been experiencing issues with users with
> Windows 7 being able to connect lately. In an effort to
> understand what is going on, we added %{SSL_PROTOCOL}x
> %{SSL_CIPHER}x %{SSL_CLIENT_S_DN_CN}x %{SSL_CLIENT_VERIFY}x
> to the CustomLog command.
> When a Windows 7 user tried to access the site, we saw the
> following entry:
>
> [25/Apr/2012:12:24:12 -0400] 172.16.10.94 TLSv1 - -
> FAILED:unable to get local issuer certificate GET / HTTP/1.1 -
>
> I have one certs file that contains these certificates
> DOD Root CA
> DOD Root CA 2
> DOD EMAIL CA 15
> .
> .
> DOD EMAIL CA 30
>
> Furthermore running "openssl verify DOD_EMAILCerts.crt" returns:
> DOD_EMAILCerts.crt: C = US, O = U.S. Government, OU = DoD, OU
> = PKI, CN = DoD Root CA 2
> error 18 at 0 depth lookup:self signed certificate
> OK
>
That tries to verify the first cert in the file (DOD Root 2)
against the default truststore which almost certainly contains
nothing relevant if it even exists (see below) thus is useless.
> Apache is configured this way:
> SSLCACertificatePath conf/certs/
> SSLCACertificateFile conf/certs/DOD_EMAILCerts.crt
> (which translates to c:\apache\conf\certs\DOD_EMAILCerts.crt)
>
Assuming that file is the one you describe above, Apache
will verify client certs against a truststore containing
the (CA) certs in that file (per above) plus any hashnamed
(CA) cert files in conf/certs (are there? That's usually
less convenient to do on Windows, so maybe not).
If you want to manually repeat/check this verification,
get the client cert (in PEM format) in a file and do
openssl verify -CAfile thatdir/DOD_EMAILCerts.crt clientcert.pem
If there are hashnamed cert files, insert -CApath thatdir .
If you like, insert -purpose sslclient , but any problem
relating to purpose would be a different error.
If the client is actually sending chain cert(s) as well, see below.
If commandline verify gives "error 20 at 0 depth", do
openssl x509 -in clientcert.pem -noout -text (or -issuer)
and check the issuer matches the subject of one of your CA certs.
If not, either you don't have (all) the correct CA certs (maybe
your file is out of date, or slightly damaged) or the client is using
a bad cert. Also look if AuthorityKeyID (AKId or AKI) is present
in the client cert, and if so whether it correctly matches the parent.
If the error is at >0 depth, it's actually the chaining within
your truststore; see below.
If the client can't give you their cert(s) directly, you can capture
with Wireshark with some effort or maybe openssl s_server .
> Running openssl version -d returns:
> OPENSSLDIR: "c:/openssl-1.0.1/ssl"
>
OPENSSLDIR/certs is the default for openssl *commandline*
if you don't override, and for an application if it uses
SSL_CTX_default_verify_paths . I don't know if Apache does,
but http://httpd.apache.org/docs/2.0/mod/mod_ssl.html
doesn't show any default which suggests not.
> OpenSSL FAQs states this error occurs if OpenSSL cannot
> verify the root CA and that the CA certificate must be placed
> in a directory or file and the relevant program configured to read it.
>
If you mean http://www.openssl.org/support/faq.html#USER5
you're misquoting it and also it's somewhat incomplete.
"When a certificate is verified its root CA must be 'trusted'..."
It is the *entity* (client) cert that is verified *using*
the root, which must be in the CAfile and/or CApath. A root
is either trusted ab initio or not, and needn't be verified.
In addition there may be an intermediate-CA aka chain cert,
or even several, also needed in verification; chain cert(s)
can be sent in protocol (unlike root) but it's usually better
they be in the truststore (your file). The names you give above
(2 DOD Root CA, then several DOD EMAIL CA) strongly suggest
use of at least one intermediate cert.
If the client certs require chain certs additional to (below
or beside) those in your file, and some clients are sending
those chain certs but other clients (e.g. Windows 7) are not,
that would cause the symptom without any cert(s) being actually
invalid. To test this, get the chain cert(s) sent by the client
in a file and insert -untrusted chainfile.pem on commandline
verify. (Note this option is not in the -? usage summary.)
SSLCACertificate{File,Path} are the way to configure modssl --
unless there's a permission problem or somesuch, but that
would affect all your clients, and you said others work,
(all?) with client-auth if I understood you correctly.
> Does the certs file need to be in both the conf/certs/ folder
> and the c:/openssl-1.0.1/ssl folder?
> What directory should it be in and how do I configure it to read it?
>
It should be where SSLCACertificateFile says, and apparently is
if any clients successfully authenticate with certs under those CAs.
If only some client certs (or chains) are rejected, check them.
Apps other than Apache may require or prefer the default
truststore. If you want to use both types of apps against the
same authenticated peers (clients and/or servers) then it may
be easier to use the default truststore for both. In that case,
put the file in OPENSSLDIR/certs and configure Apache for that.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
