I have application consuming a SOAP service that uses transport-level authentication. We are trying to move the application from Tomcat to Glassfish 3.1. Unfortunately, Glassfish seems reticent to perform the client authentication needed by the SOAP service. The SSL stacktrace results in the message "uknown_ca".
I have my Glassfish server configured to use a keystore that contains each of the three entrust certificates in the auth chain (stored as -trustcacerts) as well as having imported the SOAP destination server's certificate too.
I have tried several from-scratch rebuilds of my Glassfish server and开发者_开发问答 even resorted to trying the tomcat server's keystore file with no luck.
Does anyone know what is going on, or else how do I get Glassfish to provide me more useful information regarding the handshake and keystores involved (beyond the -Djava.net.ssl.debug flag).
A co-worker of mine came up with the solution. Points to Andrew.
The destination turned out to be sending us the unknown_ca
message, as it did not understand the CA of the key that Glassfish was sending during the authentication process.
Removing the JVM argument -Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as
resolves the issue. One may also change the argument to specify the alias of the preferred key instead of letting the JVM determine the key to use.
The SOAP server certificate should be imported into Glassfish's truststore, not keystore.
精彩评论