Hi Andreas, I don't think we can change the current behavior for backwards compatibility reasons. I agree that the current practice of falling back to the default cacerts password of "changeit" does not buy us any security for the default case. However, if we were to switch to using "null" as the default cacerts password, then there would be no integrity checking done by default on the cacerts if the administrator changed the password on cacerts, and didn't specify the password in the configuration. As things stand, integrity checking on the cacerts is always performed.
Colm. -----Original Message----- From: Andreas Veithen [mailto:[email protected]] Sent: 17 January 2010 20:56 To: [email protected]; [email protected] Cc: [email protected]; [email protected] Subject: Re: Java updates for Mac OS changes the password on jre_home/lib/security/cacerts [Cross-posting to wss4j-dev and rampart-dev] Mary, Thanks for sharing these findings. I encountered the same problem while doing some tests with Rampart (WS-Security module for Axis2). I am wondering why WSS4J actually accesses the cacerts file by specifying a password (by default). Since the keystore contains only public keys, it is perfectly possible to access it without specifying a password (simply by passing null as second parameter to KeyStore#load). One may argue that using a password to access a trust store protects against tampering, but this is only true if a non default secret password is used. Therefore I would expect WSS4J to access cacerts without password unless one is explicitly specified using the org.apache.ws.security.crypto.merlin.cacerts.password property. Maybe somebody from the wss4j-dev list can shed some light on this? Andreas On Mon, Jan 4, 2010 at 20:58, Mary Thompson <[email protected]> wrote: > Since a quick review of this mailing list does not mention this, let me > be the first. > The Apple java 1.5 update 6 and java 1.6 update 1 that occurred in > early December changed the password on the > java.home/lib/security/cacerts file. This broke an application of mine > with a "keystore has been tampered with or incorrect password" error. > Since we have our own keystore and truststore and I didn't even know > about the system default cacerts, it took me a while to figure this out. > > The class org.apache.ws.security.components.crypto.AbstractCrypto (line > 135) is trying to load cacerts from that file and using the default > password "changeit" if it hasn't been set by the > "org.apache.ws.security.crypto.merlin.cacerts.password" property. > I'm using cxf version 2.2.3. > > This change is not mentioned on the Apple Java update release notes > because it did not seem important enough. To quote an Apple java > engineer from the apple developers list "I don't believe any of us > realized that digging around in the cacerts file was such a common > practice". They may change it back if they get enough complaints. > <[email protected]> > > Anyway maybe this will save someone some hours when your Mac application > breaks after a Java update. > > BTW my solution was to use keytool to change the password back. > > sudo keytool -storepasswd -new changeit -keystore > /System/Library/Frameworks/JavaVM.framework/Resources/Deploy.bundle/Contents/Home/lib/security/cacerts > -storepass changeme > > Mary Thompson > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
