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.
