Bottom line: scrub your certificates through Mozilla/Firefox. Keep reading if you want more background.
So I recently experienced an unreasonable amount of pain trying to import a Verisign certificate that was locked into an Oracle Wallet for use in the Tomcat SSL connector. So of course the decent thing to do seems to be to put some notes out here so Google can hopefully spare some others similar pain.
Oracle Wallet uses a variant of PKCS12 as it’s native format, but it doesn’t appear to be quite compatible with Tomcat (tested with 5.5.23). When I tried to point the tomcat SSL connector directly at an Oracle Wallet via editing conf/server.xml, even though the certificate was present in the wallet/keystore I got a somewhat misleading:
SEVERE: Endpoint [SSL: ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8443]] ignored exception: java.net.SocketException: SSL handshake errorjavax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
java.net.SocketException: SSL handshake errorjavax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
at org.apache.tomcat.util.net.jsse.JSSESocketFactory.acceptSocket(JSSESocketFactory.java:114)
at org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java:408)
Note: even if your wallet has “autologin” checked — Tomcat still needs to provide the password. I’m not sure if the wallet and private key both need the same password, but it’s likely a good idea to sync them.
After trying various permutations of trying to convert the wallet, import following Verisign’s instructions, and some other combinations which might not even have included the private key (resulting in an identical to the previous attempt, but tremendous quantity of our friend):
java.net.SocketException: SSL handshake errorjavax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
After much wrangling, I discovered a thread on Sun’s forums which enlightened me to try the path of scrubbing the keystore through Mozilla via an import and then backup. Apparently Mozilla does some magic which reformats the file in such a way that Tomcat/JSSE’s PKCS12 support is happy — and we were able to chug along on our merry way.
Note: Once again, it’s probably a good idea to keep your passwords in sync. Not sure if it’s required, but didn’t test other scenarios. YMMV.
mkorcuska:
Yes, you're right Jason.
The fact that Microsoft is providing email services to the University has nothing to do with Sakai usage. This wi
Recent Links Tagged With "sakai" - JabberTags:
[...] public links >> sakai FCKEditor config.js pain Saved by jgdesigns on Tue 23-9-2008 Comment on The Ricecooker Shop 2.0! by sick of i
jayshao:
I tend to agree, but given that portlets are inherently container local, whereas the new ones are network protocal-ish, I wonder if portlets are be
Certificates: Oracle Wallet -> Tomcat
Posted by: jayshao on: October 11, 2007
Bottom line: scrub your certificates through Mozilla/Firefox. Keep reading if you want more background.
So I recently experienced an unreasonable amount of pain trying to import a Verisign certificate that was locked into an Oracle Wallet for use in the Tomcat SSL connector. So of course the decent thing to do seems to be to put some notes out here so Google can hopefully spare some others similar pain.
Oracle Wallet uses a variant of PKCS12 as it’s native format, but it doesn’t appear to be quite compatible with Tomcat (tested with 5.5.23). When I tried to point the tomcat SSL connector directly at an Oracle Wallet via editing conf/server.xml, even though the certificate was present in the wallet/keystore I got a somewhat misleading:
SEVERE: Endpoint [SSL: ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8443]] ignored exception: java.net.SocketException: SSL handshake errorjavax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
java.net.SocketException: SSL handshake errorjavax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
at org.apache.tomcat.util.net.jsse.JSSESocketFactory.acceptSocket(JSSESocketFactory.java:114)
at org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java:408)
Note: even if your wallet has “autologin” checked — Tomcat still needs to provide the password. I’m not sure if the wallet and private key both need the same password, but it’s likely a good idea to sync them.
After trying various permutations of trying to convert the wallet, import following Verisign’s instructions, and some other combinations which might not even have included the private key (resulting in an identical to the previous attempt, but tremendous quantity of our friend):
java.net.SocketException: SSL handshake errorjavax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
After much wrangling, I discovered a thread on Sun’s forums which enlightened me to try the path of scrubbing the keystore through Mozilla via an import and then backup. Apparently Mozilla does some magic which reformats the file in such a way that Tomcat/JSSE’s PKCS12 support is happy — and we were able to chug along on our merry way.
Note: Once again, it’s probably a good idea to keep your passwords in sync. Not sure if it’s required, but didn’t test other scenarios. YMMV.
Technorati Tags:
sakai, tomcat, ssl, oracle wallet, pkcs12