You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Chris.Trufan" <ch...@gmail.com> on 2012/06/26 07:42:02 UTC
Merlin 'verifyTrust' fails if there's a certificate in a
key/truststore with bad NameConstraints
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.
Re: Merlin 'verifyTrust' fails if there's a certificate in a
key/truststore with bad NameConstraints
Posted by "Chris.Trufan" <ch...@gmail.com>.
Colm,
Yes, that's exactly what I should probably do here. My apologies, I realized
right after I sent the email that this was a topic far better suited to
WSS4J than CXF.
-Chris
coheigea wrote
>
> 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 <chris.trufan@>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
>
--
View this message in context: http://cxf.547215.n5.nabble.com/Re-Merlin-verifyTrust-fails-if-there-s-a-certificate-in-a-key-truststore-with-bad-NameConstraints-tp5710322p5710338.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Merlin 'verifyTrust' fails if there's a certificate in a
key/truststore with bad NameConstraints
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <ch...@gmail.com>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