> From: owner-openssl-us...@openssl.org On Behalf Of Michel, Audrey > Sent: Thursday, 18 July, 2013 15:24 > Subject: SSL_connect:error in SSLv3 flush data - Certificate > Verification: Error (20) when setting up replacement server
Aside: the error isn't really in flush-data; it is the server rejecting the received cert and closing, which occurs immediately after and as a result of the flush-data. > We currently have a Solaris server running apache that serves > as a proxy in front of our glassfish server which we use for > web services. We are replacing both the proxy and glassfish > servers so are setting the new servers up in parallel. The > new proxy server already had apache and openssl installed > before I started moving files from the old to the new. The > issue I am running into is when I run apache with > SSLVerifyClient required on the new server I am receiving > 'unknown ca' error. If I run with SSLVerifyClient none the > xml content for our web service is displayed (confirming that > glassfish is ok). The only configuration difference between > the proxy server was I moved the location of the certificate > directories on the new server, but adjusted all apache config > files to reflect the new structure. > > My question is does openssl or mod_ssl look anywhere other > than the apache ssl configuration to locate the ca? > mod_ssl doesn't as far as I know and openssl called from mod_ssl certainly shouldn't. (openssl in some other situations, especially but not only commandline, does.) > Thanks in advance for any assistance, server info and log > details are below: > > -We have a single self signed CA which is used to sign the > server and client certs. > -The old and new server are running apache 2.0.63, Openssl 0.9.7d > <snip> but [openssl] includes additional security patches. <snip> > -I rebuilt all hash files and the filenames generated match > those on the old server so the CN's are the same. Did you generate new certs&keys or copy existing ones? If you copied then of course everything is the same. If you did new, then the hash-name for a cert actually proves the subject *DN* (which can include more than the CN) is the same in a specific way (equal after canonicalization, not necessarily identical), and says nothing about the issuer (which also can have CN). If you did a new CA key&cert (with or without new client and server certs under it) with the exact same name, that can cause problems, depending on whether you (consistently) used SKI/AKI for chaining, and it will certainly cause confusion to people such as you trying to look at it. Don't do that. If you want the same CA use the same one or an exact copy, if want a different CA use a different name. The only certs you need hashes for are CA certs, and you say you have only one CA and thus one CA cert. There is no need for entity certs (server or client) to be in the truststore (SSLCACertPath or File, -CApath or file) or hashed -- although they do no harm since openssl won't ever find them. Either way, are you using the same DNS name for the new server (proxy) as the old, and using resolution trickery to reach the one you want? If not, if you have the same specific CN in both server certs it can't match both DNS names; you need a wildcard in subject CN, or SAN (SubjectAlternativeNames). (Note that s_client doesn't check "URL" against CN/SAN, but real clients especially browsers will -- unless they're configured to be insecure, and then they may be 'owned'). > -I compared permissions and file contents for the apache > related directories. > > Using s_client with just -connect and -showcerts parameters > returns the CA cert, server cert and my client cert. So I can > see they are present on the new server. > It shouldn't. It should show the (server) chain which here is the server cert and the CA cert (specifically the server's CA's cert if that made a difference, which for you it doesn't), server cert names again, then the requested client-CA *names*. It doesn't show the client cert even if it sends one, which it won't if you don't specify -cert and possibly -key. And s_client will send the specified cert even if it doesn't match the requested client-CA names (if any), although you say you have only one CA so they should match. > Below is an abbreviated version of the output when I use the > -connect, -cert, -CApath, -showcerts, -state, and -debug > parameters. This works without error on the old server > (changing only the IP:port). > So apparently you have the client key and cert in one file, as is a convenient and fairly common choice but not required. <snip except at read server cert> > depth=1 CN = ALERTIIS Cert Auth, .. details omitted here by me.... > verify error:num=19:self signed certificate in certificate chain > verify return:0 That means s_client couldn't find the CA cert the server is using. Is its -CApath the same directory apache is using (if on same machine), or a copy with (at least) same CA cert and hashname? Compare the server CA cert (the second block from -showcerts) received from old server and from new server to each other and to the (supposed) CA cert file(s?) in client's -CApath. > At the end of the appache log I see the following error (all > other tags are [debug]: > [Thu Jul 18 08:07:07 2013] [error] Certificate Verification: > Error (20): unable to get local issuer certificate <snip> Assuming this log is for the s_client attempt above, it suggests that s_client is not sending any CA cert; that means the -cert you specified for s_client was not issued under the (or any) CAcert in -CApath. It also doesn't appear to be issued under a CAcert in the server's truststore. (For other clients, not sending the CA cert may be normal, but having it not in the truststore is still a problem.) ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
