That doesn't seem to work though. It still uses the JRE cacerts store. Our Java code makes web requests to HTTPS endpoints and I would like to keep the certificates in a key store other than the JRE one because it gets removed when java is uninstalled/updated.
OK, since the basics are so basic, my first reply was just a general advisory. Usually when I do that it's kind of worthless, but it does kind of point out stuff that everyone needs to know.
I'm still not 100% clear I know what you're after, but the 2 most likely interpretations are:
1. You want Tomcat to communicate with some other server. Actually, that would be an application deployed inside Tomcat, since Tomcat doesn't do that. Or alternatively, an appendage to Tomcat such a a Realm using Web Services. In either case, I think that you'd have to provide the alternate keystore as an option to the code. Meaning Apache HttpClient OR java.net, which presumably is the underpinning to Apache HttpClient. Probably java.net, since I know that it does cookie-related stuff automatically and figure certs are in the same general ballpark.
2. You want an external HttpClient to use certificate-based authentication. Actually, Apache HttpClient doesn't matter here, since the protocols are what's critical and what works for HttpClient should work just as well for a web browser.
For case #2, the critical cert needs to be installed in the client. If you're going the full-paranoia both-sides-certified route, as I recall, you also need a server-side cert, but I would be greatly surprised if Tomcat didn't use the same keystore as it does for server-only cert SSL, and that's the keystore you set up in the Connector. However, you MIGHT need to supply an alias for matching to the client-side cert in your request OR in your security realm definition OR (AND/OR?) in the client request itself. At this point, I'd have to RTFM.
Your diagram is incorrect. Tomcat isn't going to be making any such requests. I think probably you have this:
You can use JNDI to supply the keystore location to the webapp and that will eliminate the need to make application mods, but the application code is going to have to use the JNDI-supplied data to make its own cert location override for the connections it opens.
Joined: Mar 02, 2011
Ah, yea I was trying to show that Tomcat cast hosted MyApp and MyApp makes the httpclient request. Sorry for the confusion there. So it sounds like there's no way to make the httpclient request use something other than cacerts by putting something in server.xml or web.xml or the registry... Darn :-(
"registry"? What is this "registry" thing of which you speak? My servers don't have anything called a "registry' in them.
Technically, you can define your application cert store location in server.xml ([b]please don't!!!]/b]) and/or in web.xml. That would be the jndi resource definition. The default value would be set in web.xml and you could then override it as needed in the webapp Context definition. Which could be placed in server.xml, but it strongly discouraged these days in favor of an independent context XML file.
However, Tomcat itself neither knows nor cares what sort of silly outbound server requests any of its webapps makes, whether HTTP, FTP, LDAP, JMS, RMI or whatever. So it's up to the webapp itself to set up the environment for its own specialized configuration. JNDI can help, but it will require application logic to take the information from the JNDI directory service and set the appropriate interface property.
Joined: Mar 02, 2011
Ah thanks Tim, I'll need to research JNDI a bit more, I'm not too familiar with it.
OK. Normally, rather than using the Windows Registry, it's preferable to put those items in a TOMCAT_HOME\bin\setenv.bat file. Java apps in general should have nothing to do with the Registry, since it's not "write once/run anywhere" (to say nothing of being a major pain in the fundament). However, when launching as a Windows Service, the registry might be the only option.
Andy, this did more than help me - it saved me from the asylum ;)
It seems that the Tomcat documenters and many others (even on this site) have not considered the possibility that a client application on Tomcat, when run as a windows service, would need to trust a certificate when Tomcat is not configured for SSL.
Thanks to you i was able to have a relaxing weekend without thinking that i had lost my marbles
I wanted to mention - You dont have to update the Registry directly. Just open the Configure Tomcat exe (tomcat6w.exe) under Tomcat/bin (only if you have installed Tomcat as a Service). Use the Java tab (Java options box) to set the truststore & truststorepassword properties - They will directly get saved into the Registry.
The following working server.xml element disproves every contention made here by the OP. It has a Connector element with a truststoreFile= attribute and a clientAuth="false" attribute ; it has no reliance on the Registry or the default JDK truststore; and it works. The Registry entries described by the OP are not required; they are another mechanism to the same end.
I suspect the real problem here was the backslash in the filename.
Esmond, your connector is for an SSL connection between the browser and Tomcat. This wasn't what I was looking for. The problem I was trying to solve was a connection between the webapp and a remote (https) website.
My blog post about this documents what I was trying to achieve in great detail. If you noticed in my blog post i'm using a regular HTTP connector to demonstrate the problem.
I have the same problem...
but I have no ca.keystore file on my windows (2008 server R2) machine .. (or, at least, I can't find it )
I've googled, looked in the mmc->certificates snap in but haven't found a specific file location
seems a registry thing .....
thanks for any tip :-)
Andy Arismendi wrote:Tim, it looks like this does the trick: