Just wanted to provide an update as I was able to identify the root cause for this error. The issue was related to the users/groups on the new Solaris server not being set up correctly. Basically the user running apache didn't have permission to where the ca was stored. Once we added the apache user to the group securing the directory with the ca it was able to find the ca and the error was resolved. I appreciate the assistance as it has added to my understanding and given me ideas for improvements (and documented a lesson learned for sure).
Audrey Michel +1 972.605.8085 / Tel +1 214.770.1896 / Mobile -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dave Thompson Sent: Friday, July 19, 2013 4:32 PM To: [email protected] Subject: RE: SSL_connect:error in SSLv3 flush data - Certificate Verification: Error (20) when setting up replacement server > From: [email protected] On Behalf Of Michel, Audrey > Sent: Friday, 19 July, 2013 11:41 > Thanks for the reply and good information as it helped clear > up some misunderstanding I had. Here is some additional > information based on your responses. > > -The two servers have different DNS names and have two > different servernames in their apache config files. Each > server is stand alone and has its own copy of everything - > just trying to set up mirror images for now. > -I am using an exact copy of the ca cert (verified the second > part of the chain using -showcerts and they match). > -I have created a new server cert for the new server using > the existing server key but changed the CN to match the ip of > the new server. And each -showcerts shows the right server > cert in the chain. Ah, I didn't realize you were using cert for IP-address not cert for DNS-name like most people do. That means my questions (and your answers) about DNS are irrelevant. > -the path used on s_client for the ca is the same one in the > ssl.conf file. > -when accessing both servers via s_client I am using the same > client cert which is present on each server. Works for the > old but not for the new so I agree that the issue is locating > the ca cert. > The client cert doesn't need to be present on the server and is ignored if it is. (If you are as I have assumed using at least one of the servers as your private CA, keeping any issued cert in the CA is sensible though not required.) What matters is that the client cert is issued by (aka under) a CA cert that is on (and in the truststore of) the servers. > What confuses me is if -showcerts shows the ca in the chain > on both servers why is there a problem locating it when I use > the same client cert/arguments only on the old server? I even > removed the -CApath from both s_client commands and the old > server connects but get the same error with the new server. > One thing occurs to me: are you using SSLCertificateChainFile to specify the CA cert file? That's not normally needed but if you're doing so it might be a factor (because then we don't know if server libssl is filling from truststore, see below). s_client -CApath only affects s_client verifying the server, and s_client continues after a verify error anyway. You should have *verify return* 0 on s_client going to the usable=old server with correct -CApath, and 19 (or maybe 20 I forget) without, but still have a successful connection. To the unusable=new server you don't get nice session display with verify return, but you can extract it from the callback info in the output. > You mentioned a truststore.. I did a list on the java > keystore cacerts on both machines and neither hold my ca. > Does apache have its own store? I've never set up apache ssl > from scratch and haven't run across anything specific in my > searches on that subject. > I'm not talking about java. To be sure we're clear, 'apache' without qualification usually means httpd, a web server in C. httpd can (or at least could) use either openssl or gnutls for SSL but mod_ssl means openssl. Apache the organization also has tomcat, a web server in Java, which can use Java's own SSL implementation JSSE, or openssl via APR (Apache Portable Runtime) not mod_ssl. Truststore is a general concept for the set of CA certs something or somebody trusts. In openssl normally, it is a single PEM file containing one or more certs (SSLCACertficateFile in mod_ssl, -CAfile on some commandline utilities) or a directory of one or more PEM files each containing one cert with hash names or links (SSLCACertificatePath or -CApath). Or an application can directly load one or more certs from some other source (a database, an LDAP server, whatever) but that's more work so people rarely do. In addition to using the truststore to validate a peer cert/chain, libssl will also use it to complete its own chain if needed, which is less obvious and can be a little confusing. In Java, a standard keystore file (JKS) can contain private keys (really keypairs) with certs, and/or trusted certs by themselves. A JKS that contains trusted certs functions as a truststore, and the cacerts file distributed in each JRE is an important example; it includes CA certs for the established public CAs like Verisign and GoDaddy etc. that are widely trusted, so it is usually suitable as a truststore for applications that want to access the public Internet and Web, and is the default for JSSE. You can add to cacerts the cert for any CA you want to generally trust, including your private one or maybe one for a social group. There are other kinds of truststores Java can use, somewhat more easily than openssl because in Java you only have to write (sub)classes to a fairly simple (checked) interface. But openssl and mod_ssl can't use a Java JKS. (tomcat can and usually does.) <snip earlier> At this point, unless it's chain file confusing us, I'm baffled. Assuming you have openssl commandline on both servers, I suggest using s_server as a (much) simpler alternative to httpd and see if that gives any better info. Run s_server on each server with -accept available nonprivileged port i.e. >=1024. -cert mod_ssl's SSLCertificateFile -key SSLCertificateKeyFile if used -CApath SSLCACertificatePath if used -CAfile SSLCACertificateFile if used -Verify 1 (note uppercase V) Run s_client with -cert/key (and preferably -CApath or -CAfile) and -showcerts and maybe -state to each of those addr:port . HTH, good luck. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
