Hi Chris,
privatekey (I'm connecting two servlet running at the moment in the same
machine and requiring server and client ssl authentication)
# keytool -list -keystore /usr/local/tomcat/conf/ssl_tomcat_cert
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
tomcat, Aug 11, 2010, PrivateKeyEntry,
Certificate fingerprint (MD5):
35:8F:8D:37:76:E5:E4:A8:B6:75:CD:E7:50:B7:9A:5C
I'll just copy my previous mail as I think it contains a more detailed
information on what's happening.
But to sum things up: if I use the javax.net.ssl.trustStore things work.
If I use the trustoreFile in the connector it doesn't (as a different
trustore is loaded)
Here's the email (I've updated some logs to extend the provided
information) :
------------------------------------------------------------------------
Hi *,
I'm having a problem with the connector parameter truststoreFile as it
is being read but not used when accessing through SSL.
While running normally I get:
FINE: Creating name for connector Catalina:type=Connector,port=443
Aug 11, 2010 1:20:48 PM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-443
...
found key for : tomcat
chain [0] = [
...
]
***
...
adding as trusted cert:
Subject: CN=albedo2.dkrz.de, OU=WDCC, O=DKRZ, L=Hamburg, C=DE
Issuer: CN=albedo2.dkrz.de, OU=WDCC, O=DKRZ, L=Hamburg, C=DE
Algorithm: RSA; Serial number: 0x4c627346
Valid from Wed Aug 11 11:54:14 CEST 2010 until Tue Nov 09 10:54:14 CET
2010
...
Ok, everything's fine (that's my cert). But while trying to access to a
SSL:
...
init keystore
init keymanager of type SunX509
trustStore is: No File Available, using empty keystore.
trustStore type is : jks
trustStore provider is :
...
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=albedo2.dkrz.de, OU=WDCC, O=DKRZ, L=Hamburg, C=DE
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
....
Validity: [From: Wed Aug 11 11:54:14 CEST 2010,
To: Tue Nov 09 10:54:14 CET 2010]
Issuer: CN=albedo2.dkrz.de, OU=WDCC, O=DKRZ, L=Hamburg, C=DE
SerialNumber: [ 4c627346]
]
...
***
*** CertificateRequest
Cert Types: RSA, DSS
Cert Authorities:
...
<CN=albedo2.dkrz.de, OU=WDCC, O=DKRZ, L=Hamburg, C=DE>
...
*** ServerHelloDone
http-443-2, WRITE: TLSv1 Handshake, length = 1915
http-443-1, READ: TLSv1 Handshake, length = 1915
*** ServerHello, TLSv1
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=albedo2.dkrz.de, OU=WDCC, O=DKRZ, L=Hamburg, C=DE
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
...
Validity: [From: Wed Aug 11 11:54:14 CEST 2010,
To: Tue Nov 09 10:54:14 CET 2010]
Issuer: CN=albedo2.dkrz.de, OU=WDCC, O=DKRZ, L=Hamburg, C=DE
SerialNumber: [ 4c627346]
]
...
***
http-443-1, handling exception: java.lang.RuntimeException: Unexpected
error: java.security.InvalidAlgorithmParameterException: the
trustAnchors parameter must be non-empty
http-443-1, SEND TLSv1 ALERT: fatal, description = internal_error
http-443-1, WRITE: TLSv1 Alert, length = 2
http-443-1, called closeSocket()
http-443-2, READ: TLSv1 Alert, length = 2
http-443-1, called close()
Note: I've moved the default java jssecacaertas and cacerts files to be
sure they are not loaded. If not this step was previously accessing
those certs.
Launching tomcat with
-Djavax.net.ssl.trustStore=/usr/local/tomcat/conf/jssecacerts I have no
problem:
...
init keystore
init keymanager of type SunX509
trustStore is: /usr/local/tomcat/conf/jssecacerts
trustStore type is : jks
trustStore provider is :
init truststore
...
If I use a non existing file for the truststoreFile parameter I get:
FINE: Creating name for connector Catalina:type=Connector,port=443
Aug 11, 2010 2:45:53 PM
org.apache.tomcat.util.net.jsse.JSSESocketFactory getStore
SEVERE: Failed to load keystore type JKS with path
/usr/local/tomcat/conf/jssecacerts2 due to
/usr/local/tomcat/conf/jssecacerts2 (No such file or directory)
java.io.FileNotFoundException: /usr/local/tomcat/conf/jssecacerts2 (No
such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:347)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getTrustStore(JSSESocketFactory.java:320)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getTrustManagers(JSSESocketFactory.java:513)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:419)
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:130)
at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:538)
at
org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:176)
at
org.apache.catalina.connector.Connector.initialize(Connector.java:1014)
at
org.apache.catalina.core.StandardService.initialize(StandardService.java:680)
at
org.apache.catalina.core.StandardServer.initialize(StandardServer.java:795)
at org.apache.catalina.startup.Catalina.load(Catalina.java:524)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:261)
at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:276)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:160)
Aug 11, 2010 2:45:53 PM org.apache.coyote.http11.Http11Protocol init
So I'm pretty sure that the file is valid and can be found. Any Idea?
I know you might need a lot more information (if this is indeed a bug).
Just tell me and I'll provide :-)
Some info though:
apache-tomcat-6.0.26
jdk1.6.0_20
LSB Version:
:core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: RedHatEnterpriseServer
Description: Red Hat Enterprise Linux Server release 5.5 (Tikanga)
Release: 5.5
Codename: Tikanga
Thanks,
Estani
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Thanks,
Estani
Christopher Schultz wrote:
Estani,
On 8/12/2010 3:47 AM, Estanislao Gonzalez wrote:
> If I set both trustoreFile and javax.net.ssl.trustStore which one is
> being honored? The documentation is not clear to me:
> "The trust store file to use to validate client certificates. The
> default is the value of the |javax.net.ssl.trustStore| system property.
> If neither this attribute nor the default system property is set, no
> trust store will be configured."
> "The default" as in "if nothing else is found" or "if set"?
I think this might be a language problem. I believe the code would look
something like this, which might be easier to understand:
String trustStoreFile = connector.getTrustStoreFile();
if(null == trustStoreFile)
trustStoreFile = System.getProperty("javax.net.ssl.trustStore");
if(null != trustStoreFile)
{
// Use the trustStoreFile
}
else
{
// No trustStoreFile
}
> I have a truststoreFile set (which is read), but the validation is made
> against java own jssecacerts or cacerts files, the one from the
> truststoreFile is only used if explicitly mentioned in
> javax.net.ssl.trustStore, no matter what.
Please post your configuration, and a "keystore -list" for the
truststore you are trying to use.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
Estanislao Gonzalez
Max-Planck-Institut für Meteorologie (MPI-M)
Deutsches Klimarechenzentrum (DKRZ) - German Climate Computing Centre
Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany
Phone: +49 (40) 46 00 94-126
E-Mail: estanislao.gonza...@zmaw.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
