You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Estanislao Gonzalez <es...@zmaw.de> on 2010/08/12 09:47:32 UTC
truststoreFile vs javax.net.ssl.trustStore
Hi,
I try to simplify my question in the hopes that someone can answer it.
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 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.
Thanks,
Estani
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: truststoreFile vs javax.net.ssl.trustStore
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Estanislao,
On 8/16/2010 4:34 AM, Estanislao Gonzalez wrote:
> thanks a lot for your help! I've solved the matter but I have still some
> questions and some interesting findings I would like to share, so please
> continue reading this email :-)
Glad you found the problem and that things are working and/or making
sense, now.
> My proposal to this people was to read the connector configuration and
> set up httpclient in a proper way. To my knowledge this could be done
> this way:
> ---
> Connector[] connectors =
> org.apache.catalina.ServerFactory.getServer().findService("Catalina").findConnectors();
>
> for (Connector connector : connectors) {
> if (connector.getSecure()) {
> String tsFile =
> (String)connector.getAttribute("truststoreFile");
> String tsPass =
> (String)connector.getAttribute("truststorePass");
> if (tsFile != null) {
> //this is the connector we are looking for
> if (tsPass == null) tsPass = "changeit"; //tomcat
> default
> //file and pass are known, set up
> httpclient properly
> break;
> }
> }
> }
This procedure has several problems:
1. You never know which connector you're going to get. If multiple
connectors are configured, you might guess the wrong one.
2. This library might not have access to Tomcat code when used, so this
procedure wouldn't be at all valid in those environments.
3. Even when used within Tomcat, it may not be appropriate to configure
the library to share Tomcat's trustStore.
What would be better is having the library allow you to configure the
trust store to be used, and then you duplicate the configuration you
already have for Tomcat.
> You mentioned that setting the JVM variable with the truststoreFile and
> pass will do. But this will show the password to anyone making a ps...
> or am I missing something?
That is correct. There are other ways of setting system properties,
though. You can call System.setProperty before the library is
initialized and you should be okay. You can read the system properties
from a file and they won't show up in a process listing.
> Do you see any problem or better solution? I think the best way is
> letting tomcat handle the whole configuration from servlet.xml file,
> and, if required, accessing the configuration from those servlet that
> requires to.
No, Tomcat should use its own configuration and the httpclient should
use it's own separate configuration. If they allow you to configure the
trustStore via some mechanism, then use it. If they don't allow you to
do that, you should file an enhancement request since this really is a
requirement for a useful library of this kind.
Good luck,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxtaeQACgkQ9CaO5/Lv0PCI+ACcCJZ3L4h3pE2+hvhLd3KgbA9+
oJQAn3flSOKsHF9G/SMjqINc//Ioh1JA
=gOxo
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: truststoreFile vs javax.net.ssl.trustStore
Posted by Estanislao Gonzalez <es...@zmaw.de>.
Hi Chris,
thanks a lot for your help! I've solved the matter but I have still some
questions and some interesting findings I would like to share, so please
continue reading this email :-)
It turned out, that the problem was caused by a library within a servlet
(which is not open sourced, so I could not see it :-/) which was using
the httpclient library for connecting to (in this case) the same server
through ssl.
The procedure was: an openidprovider (openid4j) was inquired from this
server. The mentioned library opened an SSL channel without knowing the
tomcat configuration... so it was accessing the default java one (that's
why the variable setup was indeed working).
My proposal to this people was to read the connector configuration and
set up httpclient in a proper way. To my knowledge this could be done
this way:
---
Connector[] connectors =
org.apache.catalina.ServerFactory.getServer().findService("Catalina").findConnectors();
for (Connector connector : connectors) {
if (connector.getSecure()) {
String tsFile =
(String)connector.getAttribute("truststoreFile");
String tsPass =
(String)connector.getAttribute("truststorePass");
if (tsFile != null) {
//this is the connector we are looking for
if (tsPass == null) tsPass = "changeit"; //tomcat
default
//file and pass are known, set up
httpclient properly
break;
}
}
}
This can also be extended to the keystore and then setting up httpclient
will be as easy as:
Protocol authhttps = new Protocol("https", new
AuthSSLProtocolSocketFactory(
new URL("file:my.keystore"), "mypassword",
new URL("file:my.truststore"), "mypassword"), 443);
Protocol.registerProtocol("https", authhttps);
(I haven't checked it though)
http://www.jdocs.com/httpclient/3.0.1/api-index.html?m=class&p=org.apache.commons.httpclient.contrib.ssl&c=AuthSSLProtocolSocketFactory&render=classic
---
You mentioned that setting the JVM variable with the truststoreFile and
pass will do. But this will show the password to anyone making a ps...
or am I missing something?
Do you see any problem or better solution? I think the best way is
letting tomcat handle the whole configuration from servlet.xml file,
and, if required, accessing the configuration from those servlet that
requires to.
Thanks again,
Estani
Christopher Schultz wrote:
> Estani,
>
> On 8/13/2010 5:31 AM, Estanislao Gonzalez wrote:
> > 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)
>
>
> What value are you using for javax.net.ssl.trustStore?
>
> > 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.
>
> That looks like a problem. Is that an error message that isn't really
> telling the truth? Perhaps it means "No file available, defaulting to
> javax.net.ssl.trustStore".
>
> > 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]
>
> > ]
>
> That's certainly /not/ an empty keystore, so I'm confused by the above
> error message.
>
> > 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()
>
> When does this occur? During SSL negotiation for a request?
>
> > 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.
>
> That's probably not a good idea: you generally want the system-trusted
> certificates to be available at some level.
>
> > 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
>
> Looks good.
>
> > 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)
>
> Okay, that looks good, too.
>
> > So I'm pretty sure that the file is valid and can be found. Any Idea?
>
> Maybe it's a more subtle error: can Tomcat read the file even though
> it's there? Maybe it's missing the read bit for the Tomcat user?
> Probably not, but it's a simple check and might explain what's going on.
>
> > 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
>
> Any possibility of upgrading to 6.0.29? I don't see anything in the
> ChangeLog that suggests a fix for something like this, but it's possible
> that something has changed.
>
> -chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@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.gonzalez@zmaw.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: truststoreFile vs javax.net.ssl.trustStore
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Estani,
On 8/13/2010 5:31 AM, Estanislao Gonzalez wrote:
> 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)
What value are you using for javax.net.ssl.trustStore?
> 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.
That looks like a problem. Is that an error message that isn't really
telling the truth? Perhaps it means "No file available, defaulting to
javax.net.ssl.trustStore".
> 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]
>
> ]
That's certainly /not/ an empty keystore, so I'm confused by the above
error message.
> 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()
When does this occur? During SSL negotiation for a request?
> 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.
That's probably not a good idea: you generally want the system-trusted
certificates to be available at some level.
> 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
Looks good.
> 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)
Okay, that looks good, too.
> So I'm pretty sure that the file is valid and can be found. Any Idea?
Maybe it's a more subtle error: can Tomcat read the file even though
it's there? Maybe it's missing the read bit for the Tomcat user?
Probably not, but it's a simple check and might explain what's going on.
> 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
Any possibility of upgrading to 6.0.29? I don't see anything in the
ChangeLog that suggests a fix for something like this, but it's possible
that something has changed.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxlp3IACgkQ9CaO5/Lv0PCd8wCfcdpxPOO6kA1TO/QsBJgUkmIZ
W6UAoIIz/f+aPdXR30P6cWTxa3ERJIAJ
=+rH2
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: truststoreFile vs javax.net.ssl.trustStore
Posted by Estanislao Gonzalez <es...@zmaw.de>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@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.gonzalez@zmaw.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: truststoreFile vs javax.net.ssl.trustStore
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxkOu8ACgkQ9CaO5/Lv0PBMSQCdGk4NYk2tVD8S28DDT4T6RLXe
ChoAmQHy9ZDi5gA9CBAX3ng5r/+D2RU1
=N1Y0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org