Finally got the solution to my problem, so I'll post the results here if anyone else gets stuck.
Thanks to Michael Martin of Michael's Software Thoughts & Ramblings I discovered that:
keytool by default uses the DSA
algorithm when generating the
self-signed cert. Earlier versions of
Firefox accepted these keys without
problem. With Firefox 3 beta 5, using
DSA doesn't work, but using RSA does.
Passing "-keyalg RSA" when generating
the self-signed certificate creates a
cert the Firefox 3 beta 5 fully
accepts.
I simply set that flag, cleared all caches in FireFox and it worked like a charm! I am using this as a test-setup for my project and I need to share this with other people, so I wrote a little batch script that creates two SSL certificates. One can be dropped into the Tomcat setup and the other is a .p12 file that can be imported into FireFox/IE. Thanks!
Usage: first command-line argument is the username of the client. All passwords are "password" (with no quotations). Change any of the hard-coded bits to meet your needs.
@echo off
if "%1" == "" goto usage
keytool -genkeypair -alias servercert -keyalg RSA -dname "CN=Web Server,OU=Unit,O=Organization,L=City,S=State,C=US" -keypass password -keystore server.jks -storepass password
keytool -genkeypair -alias %1 -keystore %1.p12 -storetype pkcs12 -keyalg RSA -dname "CN=%1,OU=Unit,O=Organization,L=City,S=State,C=US" -keypass password -storepass password
keytool -exportcert -alias %1 -file %1.cer -keystore %1.p12 -storetype pkcs12 -storepass password
keytool -importcert -keystore server.jks -alias %1 -file %1.cer -v -trustcacerts -noprompt -storepass password
keytool -list -v -keystore server.jks -storepass password
del %1.cer
goto end
:usage
echo Need user id as first argument: generate_keystore [username]
goto end
:end
pause
The results are two files. One called server.jks that you drop into Tomcat and another file called {username}.p12 that you import into your browser. The server.jks file has the client certificate added as a trusted cert.
I hope someone else finds this useful.
And here is the the XML that needs to be added to your Tomcat conf/sever.xml file (only tested on on Tomcat 6.x)
<Connector
clientAuth="true" port="8443" minSpareThreads="5" maxSpareThreads="75"
enableLookups="true" disableUploadTimeout="true"
acceptCount="100" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true"
keystoreFile="${catalina.home}/conf/server.jks"
keystoreType="JKS" keystorePass="password"
truststoreFile="${catalina.home}/conf/server.jks"
truststoreType="JKS" truststorePass="password"
SSLVerifyClient="require" SSLEngine="on" SSLVerifyDepth="2" sslProtocol="TLS"
/>
For Tomcat 7:
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
port="8443" SSLEnabled="true"
maxThreads="200" scheme="https" secure="true"
keystoreFile="${catalina.base}/conf/server.jks" keystorePass="password"
clientAuth="false" sslProtocol="TLS" />
The first SSL trace appears to be part of the second one, displayed at the server. Please confirm.
The second trace shows that the server asked for an RSA or DSS certificate signed by 'CN=xxxxxx Client, OU=communication, O=xxxxxx, L=Zuerich, ST=ZH, C=CH', and the client replied by sending an empty certificate chain. That can only mean either that the client's keystore doesn't have such a cert in it or that the client wasn't using the correct keystore.
Best Answer
Root certificates issued by CAs are just self-signed certificates (which may in turn be used to issue intermediate CA certificates). They have not much special about them, except that they've managed to be imported by default in many browsers or OS trust anchors.
While browsers and some tools are configured to look for the trusted CA certificates (some of which may be self-signed) in location by default, as far as I'm aware the
openssl
command isn't.As such, any server that presents the full chain of certificate, from its end-entity certificate (the server's certificate) to the root CA certificate (possibly with intermediate CA certificates) will have a self-signed certificate in the chain: the root CA.
openssl s_client -connect myweb.com:443 -showcerts
doesn't have any particular reason to trust Verisign's root CA certificate, and because it's self-signed you'll get "self signed certificate in certificate chain".If your system has a location with a bundle of certificates trusted by default (I think
/etc/pki/tls/certs
on RedHat/Fedora and/etc/ssl/certs
on Ubuntu/Debian), you can configure OpenSSL to use them as trust anchors, for example like this: