I am trying to call a webservices, which is hosted on a remote server and is exposed through an https endpoint.
My client is an application hosted on my local tomcat, and in my tomcat's setenv.bat, I have set the following properties:
echo setting JAVA OPTS for certificates
set "JAVA_OPTS= -Dhttps.proxyHost=10.64.X.XXX -Dhttps.proxyPort=8080 -Djavax.net.ssl.trustStore=%CATALINA_HOME%/certificateStore/XXXProdTrustStore.jks -Djavax.net.ssl.trustStorePassword=XXX -Djavax.net.ssl.trustStoreType=JKS -Djavax.net.ssl.keyStore=%CATALINA_HOME%/certificateStore/XXXProdKeyStore.pfx -Djavax.net.ssl.keyStorePassword=XXX -Djavax.net.ssl.keyStoreType=pkcs12 -Djava.security.debug=all -Dorg.apache.ws.security.crypto.merlin.file=%CATALINA_HOME%/certificateStore/XXXProdKeyStore.jks %JAVA_OPTS%"
NOTE: I have generated the XXXProdTrustStore.jks, XXXProdKeyStore.pfx and XXXProdKeyStore.jks through supplier's provided certificate. From supplier, i mean the company hosting the webservice.
On my calling the service, I get the following error:
Could someone give me some pointers as to where the problem lies?
Another important observation is that if is implement a standalone client (standard java) and execute it "not" as a JEE/Tomcat component then the I get no issues. There I set everything as system properties, part of java code and not as batch file JAVA OPTS properties.
It's only when i run the application in Tomcat, I get the above error message.
If you are making an HTTPS request to an external server from within a webapp, usually you don't need all this environmental information.
Actually, the JVM environment is generally discouraged for that kind of stuff, since it affects the entire JVM, not just a single webapp within the JVM. Webapps are primarily expected to get their external information from their deployment Context definition.
As to why all the security info, I'm even more confused. If you're planning to do standard SSL, everything you need is pre-configured and pre-installed for all JVM instances, both stand-alone java Applications and Java-based webapp servers (which actually are just a specialized class of Java Application). If you need to add a special encryption scheme, that would be more likely to require mods in the JDK directory than at runtime. If you have a client-side security cert, I'm pretty sure that there's a Tomcat config option for that. But I don't believe it requires a keystore. The keystore is normally used for SSL coming in to your webapp, and it's definitely a Tomcat configuration matter, not a JVM one.
Finally, I'm missing the point on setting proxy parameters. The webapp should be capable of targeting the destination (webservices) server directly. That destination might itself be a proxy, but a good proxy is transparent, so no client-side config options should apply.
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.
Pay attention! Tiny ad!
SKIP - a book about connecting industrious people with elderly land owners