Hi Chris, Have you considered submitting a patch to the WSS4J project for this?
Colm. On Tue, Jun 26, 2012 at 6:42 AM, Chris.Trufan <[email protected]>wrote: > When Merlin calls the "verifyTrust" method, it runs through all > certificates > in the key and trust stores, constructing a "TrustAnchor" with each. > > When a TrustAnchor constructor is called with a byte array that can't be > decoded into a proper NameConstraints extension, the Java code throws an > IllegalArgumentException over it - I've encountered this issue with > certificates that other architectures are willing to accept as having valid > Name Constraints extensions - as in, otherwise acceptable certificates have > their name constraints rejected (in all scenarios I've encountered this, > the > certificate has an empty "excluded namespace" branch of the extension - > this > isn't an exhaustive analysis, though). > > The (current) Merlin code throws an exception even if the given > certificate/trust anchor isn't part of path validation. I was wondering if > this was deliberate - arguably this is something that the underlying > TrustAnchor code should be dealing with, but at the same time, proper path > validation shouldn't require that the provided trust stores contain > exclusively X.509 compliant certificates, and fail otherwise. Currently, > it's possible to have an intermediate certificate that isn't involved at > all > with path validation, and Merlin will refuse to approve any certificate, at > all, while the 'bad' cert is in the cert store. > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/Merlin-verifyTrust-fails-if-there-s-a-certificate-in-a-key-truststore-with-bad-NameConstraints-tp5710287.html > Sent from the cxf-user mailing list archive at Nabble.com. > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
