RE: Java updates for Mac OS changes the password on jre_home/lib/security/cacerts

[Colm O hEigeartaigh <co...@progress.com>]

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:andreas.veithen@gmail.com] 
Sent: 17 January 2010 20:56
To: users@cxf.apache.org; mrthompson@lbl.gov
Cc: wss4j-dev@ws.apache.org; rampart-dev@ws.apache.org
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 <mr...@lbl.gov> 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.
> <de...@apple.com>
>
> 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org