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-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
