Forum Discussion
ericacm
16 years agoOccasional Contributor
So it turns out that Apple changed the password on the cacerts keystore file. By default, WSS4J tries to open that file with the "default" password of "changeit". Some clever dude on the Apple Java mailing list found they had changed it to "changeme" (see http://lists.apple.com/archives/java-de ... 00097.html)
There are a few ways to solve the problem. Two are:
1. Change the password on the cacerts keystore back to "changeit". This is what I've done to get SoapUI working. I'm not thrilled about this approach because who knows what is going to break. Hopefully Apple will fix the problem.
2. Add the following WSS4J property org.apache.ws.security.crypto.merlin.load.cacerts=false. This would require hacking the soapui source (see src/java/com/eviware/soapui/impl/wsdl/support/wss/crypto/MerlinCrypto.java) which I am even less thrilled about. Perhaps Eviware can put that in one of the upcoming releases. I am not sure if SoapUI is dependent on the cacerts functionality of WSS4J - it doesn't seem to be but I wouldn't want to risk it.
There are a few ways to solve the problem. Two are:
1. Change the password on the cacerts keystore back to "changeit". This is what I've done to get SoapUI working. I'm not thrilled about this approach because who knows what is going to break. Hopefully Apple will fix the problem.
2. Add the following WSS4J property org.apache.ws.security.crypto.merlin.load.cacerts=false. This would require hacking the soapui source (see src/java/com/eviware/soapui/impl/wsdl/support/wss/crypto/MerlinCrypto.java) which I am even less thrilled about. Perhaps Eviware can put that in one of the upcoming releases. I am not sure if SoapUI is dependent on the cacerts functionality of WSS4J - it doesn't seem to be but I wouldn't want to risk it.