I used this guide to create certificates for Metro: http://www.jroller.com/gmazza/entry/using_openssl_to_create_certificates
So I now have servicestore.jks and clientstore.jks.
When I check the keystores I see that the PrivateKeyEntry in servicestore.jks is myservicekey and the trustedCertEntry is myclientkey. Vice versa in clientstore.jks.
I use these in the client xml and service wsit xml. I followed the official WSIT tutorial to do this in Netbeans. Everything deploys fine.
So when testing a method call from the client I get the following exception:
[#|2011-10-19T08:59:38.465+0200|INFO|glassfish3.1.1|com.sun.metro.policy|_ThreadID=81;_ThreadName=http-thread-pool-8080(1);|WSP5018: Loaded WSIT configuration from file: file:/opt/glassfish3/glassfish/domains/domain1/applications/testwebapp/WEB-INF/classes/META-INF/wsit-client.xml.|#]
[#|2011-10-19T08:59:41.167+0200|SEVERE|glassfish3.1.1|javax.enterprise.resource.xml.webservices.security|_ThreadID=84;_ThreadName=http-thread-pool-8080(4);|WSS1533: Validation of self signed certificate failed.|#]
[#|2011-10-19T08:59:41.171+0200|SEVERE|glassfish3.1.1|com.sun.xml.wss.provider.wsit|_ThreadID=84;_ThreadName=http-thread-pool-8080(4);|WSITPVD0035: Error in Verifying Security in Inbound Message. com.sun.xml.wss.XWSSecurityException: Validation of self signed certificate failed at com.sun.xml.wss.impl.misc.WSITProviderSecurityEnvironment.validateCertificate(WSITProviderSecurityEnvironment.java:937) at com.sun.xml.ws.security.opt.impl.incoming.X509BinarySecurityToken.validate(X509BinarySecurityToken.java:185) at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.handleSecurityHeader(SecurityRecipient.java:396) at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.cacheHeaders(SecurityRecipient.java:275) at com.sun.xml.ws.security.opt.impl.incoming.SecurityRecipient.validateMessage(SecurityRecipient.java:225) at com.sun.xml.wss.provider.wsit.WSITServerAuthContext.verifyInboundMessage(WSITServerAuthContext.java:586) .............
When I tried using a bad password in the client xml I got a different exception and when I used a wrong filename I got a file not found exception. So it finds the clientstore at least.
So I thought there might be something wrong with the service keystore (I'm thinking it might be using a default glassfish one and not my own) and found some options in the domain.xml. So I changed these:
-Dcom.sun.enterprise.security.httpsOutboundKeyAlias=myservicekey -Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/config/servicestore.jks -Djavax.net.ssl.keyStorePassword=sspas -Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/config/servicestore.jks -Djavax.net.ssl.trustStorePassword=sspass -DSERVER_KEY_ALIAS=myservicekey -DCLIENT_KEY_ALIAS=myclientkey
but when I restart the server I get this exception and can't get to the login of the admin console:
............. Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:772) at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:55) at java.security.KeyStore.load(KeyStore.java:1214) at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.loadKS(SecuritySupportImpl.java:254) at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.loadStores(SecuritySupportImpl.java:208) ... 63 more Caused by: java.security.UnrecoverableKeyException: Password verification failed at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:770) ... 67 more
Then I read the following in the WSIT tutorial: In order to use WSIT security on Glassfish, you will have to import your trusted stores into GlassFish's keystore and specify those certificates from NetBeans IDE.
So I can't use my own keystores? Did I miss anything when changing the domain.xml? Or did I go wrong before the whole jvm options thing?
From the expection message "Validation of self signed certificate failed", I would conclude the server does not trust the client certificate which signs/encrypt the soap message.
You should check which truststore is used by glassfish and whether it contains the client certificate. I don't know much about glassfish, but here seems to be some directions. Is the servicestore.jks used as the truststore and really contains the exact some client certifcate. One could easily regenerate the clientstore.jks and forget to recreate the truststore.
If the truststore contains the expected certificate and is actually used by glassfish, you should also check which certificate is sent by the client. Look into the header and have a look for the BinarySecurityToken. Depending on your choice of WSIT, it contains the certifcate used in the message.