Ok. Unfortunatelly I got a side effect while putting root CA. I have enable
revocation validation and if I put the Root CA in the truststore then it
tries also to validate the Interdemediate CA with the crl from the Root CA.
For the moment, it could be done easily cause this is a custom Root CA. So
we can generate a CRL available for a long time. However if we move to a
public CA such as GlobalSign,Quovadis,... then we would have to download
CRL quite often which will  be a little complicated for our
infrastructure...
Any toughts?
Best Regards,
Claude

2016-09-30 12:12 GMT+02:00 Colm O hEigeartaigh <[email protected]>:

> No, but it would be pretty easy to implement as a custom extension of the
> SignatureTrustValidator.
>
> Colm.
>
> On Fri, Sep 30, 2016 at 11:06 AM, Claude Libois <[email protected]>
> wrote:
>
> > Thanks for the answer,
> > Is there something like wss.subject.cert.constraints that could add a
> > constraint on the issuer DN ?
> > Best Regards,
> > Claude
> >
> > 2016-09-30 12:04 GMT+02:00 Colm O hEigeartaigh <[email protected]>:
> >
> >> I think the best way to proceed is to have both the root and
> intermediate
> >> CA in the truststore. Then override the SignatureTrustValidator in WSS4J
> >> to
> >> specify a constraint on the Issuer DN of the certificate (after
> validating
> >> the cert path as normal), to make sure that it's the Intermediate
> >> Certificate that's the Issuer and not the root cert.
> >>
> >> Colm.
> >>
> >> On Fri, Sep 30, 2016 at 10:36 AM, Claude Libois <[email protected]
> >
> >> wrote:
> >>
> >> > Ok I have checked the RFC3280 http://www.ietf.org/rfc/rfc3280.txt
> which
> >> > defined the algorithm implemented by the SUN provider.
> >> > So we have a certificate path and a TrustAnchors which must respect
> the
> >> > following constraints:
> >> >
> >> >       (a)  for all x in {1, ..., n-1}, the subject of certificate x is
> >> >       the issuer of certificate x+1;
> >> >       *(b)  certificate 1 is issued by the trust anchor;*
> >> >       (c)  certificate n is the certificate to be validated; and
> >> >
> >> >       (d)  for all x in {1, ..., n}, the certificate was valid at the
> >> >       time in question.
> >> >
> >> >  The problem is the point b. I have noticed that in the certificate
> >> path I
> >> > have the Intermediate CA as certificate 1 and the client certificate
> as
> >> > certificate 2. In my trust anchor set I got the Intermediate CA.
> >> > The problem is that as , the Intermediate CA is not self-signed, b is
> >> not
> >> > true.
> >> > While debugging the Merlin classe I have removed the Intermediate CA
> >> from
> >> > the path and then everything works fine. I'm using WSS4J 2.0.4 and
> don't
> >> > know if there is a way to fix this by a configuration or a bug(not
> sure
> >> > it's one) fix ?
> >> > Best Regards,
> >> > Claude
> >> >
> >> >
> >> >
> >> > 2016-09-29 15:31 GMT+02:00 Claude Libois <[email protected]>:
> >> >
> >> > > With the debug info I get:
> >> > > certpath: PKIXCertPathValidator.engineValidate()...
> >> > > certpath: AdaptableX509CertSelector.match: subject key IDs don't
> >> match.
> >> > > *Expected: [4, 20, 79, -116, -94, -3, -13, 4, -19, -80, 42, -25,
> -69,
> >> > -80,
> >> > > 81, -87, 81, -36, 108, -3, -6, 28] *
> >> > >
> >> > > *Cert's: [4, 20, -113, -75, -53, -32, -56, -33, 25, -117, -83, -65,
> >> 99,
> >> > > -87, -122, -61, -48, -111, -30, -80, 80, -99]*
> >> > > *certpath: NO - don't try this trustedCert*
> >> > >
> >> > > The first one(Expected) is the root CA and the second one(Cert's) is
> >> the
> >> > > intermediate CA.
> >> > > So it expect that both key identifier are same. I guess to check if
> >> it's
> >> > a
> >> > > self-signed ?
> >> > > BTW I'm using java 8.
> >> > > Best Regards,
> >> > > Claude
> >> > >
> >> > > 2016-09-29 15:02 GMT+02:00 Claude Libois <[email protected]>:
> >> > >
> >> > >> Well unfortunately that doesn't work. I have debug till Merlin
> crypto
> >> > >> java file and saw that everything looks fine(chain path to check
> with
> >> > >> client cert+intermediate CA and trust anchor on intermediate CA).
> >> > However
> >> > >> the validator seems to have a problem with this and since it's sun
> >> code
> >> > >> it's a bit harder to find why.
> >> > >> *            if (provider == null || provider.length() == 0) {*
> >> > >> *                validator = CertPathValidator.getInstance(
> "PKIX");*
> >> > >> *            } else {*
> >> > >> *                validator = CertPathValidator.getInstance("PKIX",
> >> > >> provider);*
> >> > >> *            }*
> >> > >> *            validator.validate(path, param);*
> >> > >> I have decompiled some classe but can't debug since it's part of
> >> rt.jar.
> >> > >> I have enable the *-Djava.security.debug*  and hope I will get
> >> usefull
> >> > >> info...
> >> > >> Claude
> >> > >>
> >> > >> 2016-09-29 14:07 GMT+02:00 Jose María Zaragoza <
> [email protected]
> >> >:
> >> > >>
> >> > >>> 2016-09-29 11:14 GMT+02:00 Claude Libois <[email protected]
> >:
> >> > >>> > Hello,
> >> > >>> > This problem might be more related to how java validate
> >> certificate
> >> > >>> but I
> >> > >>> > give a try here.
> >> > >>> > My client certificate chain is Root CA>Intermediate CA> client
> >> Cert.
> >> > >>> > I wish to only trust certificate coming from Intermediate CA and
> >> not
> >> > >>> the
> >> > >>> > Root CA.
> >> > >>> > However, I have noticed that the PKI validator(which is the
> >> default
> >> > >>> one)
> >> > >>> > called by the Merlin failed to validate :
> >> > >>> > *Exception in thread "main" javax.xml.ws.soap.
> SOAPFaultException:
> >> > >>> Error
> >> > >>> > during certificate path validation: Path does not chain with any
> >> of
> >> > the
> >> > >>> > trust anchors*
> >> > >>> > * at
> >> > >>> > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProx
> >> > >>> y.java:160)*
> >> > >>> > * at com.sun.proxy.$Proxy34.submit(Unknown Source)*
> >> > >>> > * at
> >> > >>> > client.OffresEmploiClientSigning.doCall(OffresEmploiClientSi
> >> > >>> gning.java:87)*
> >> > >>> > * at
> >> > >>> > client.OffresEmploiClientSigning.main(OffresEmploiClientSign
> >> > >>> ing.java:65)*
> >> > >>> > * at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)*
> >> > >>> > * at
> >> > >>> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> >> > >>> ssorImpl.java:57)*
> >> > >>> > * at
> >> > >>> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> >> > >>> thodAccessorImpl.java:43)*
> >> > >>> > * at java.lang.reflect.Method.invoke(Method.java:606)*
> >> > >>> > * at com.intellij.rt.execution.application.AppMain.main(
> AppMain.j
> >> > >>> ava:120)*
> >> > >>> > *Caused by: org.apache.cxf.binding.soap.SoapFault: Error during
> >> > >>> certificate
> >> > >>> > path validation: Path does not chain with any of the trust
> >> anchors*
> >> > >>> > * at
> >> > >>> > org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterce
> >> > >>> ptor.unmarshalFault(Soap11FaultInInterceptor.java:86)*
> >> > >>> > * at
> >> > >>> > org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterce
> >> > >>> ptor.handleMessage(Soap11FaultInInterceptor.java:52)*
> >> > >>> > * at
> >> > >>> > org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterce
> >> > >>> ptor.handleMessage(Soap11FaultInInterceptor.java:41)*
> >> > >>> > * at
> >> > >>> > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(Phase
> >> > >>> InterceptorChain.java:307)*
> >> > >>> > * at
> >> > >>> > org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserv
> >> > >>> er.onMessage(AbstractFaultChainInitiatorObserver.java:113)*
> >> > >>> > * at
> >> > >>> > org.apache.cxf.binding.soap.interceptor.CheckFaultIntercepto
> >> > >>> r.handleMessage(CheckFaultInterceptor.java:69)*
> >> > >>> > * at
> >> > >>> > org.apache.cxf.binding.soap.interceptor.CheckFaultIntercepto
> >> > >>> r.handleMessage(CheckFaultInterceptor.java:34)*
> >> > >>> > * at
> >> > >>> > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(Phase
> >> > >>> InterceptorChain.java:307)*
> >> > >>> > * at org.apache.cxf.endpoint.ClientImpl.onMessage(
> ClientImpl.java
> >> > >>> :802)*
> >> > >>> > * at
> >> > >>> > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStrea
> >> > >>> m.handleResponseInternal(HTTPConduit.java:1645)*
> >> > >>> > * at
> >> > >>> > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStrea
> >> > >>> m.handleResponse(HTTPConduit.java:1533)*
> >> > >>> > * at
> >> > >>> > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStrea
> >> > >>> m.close(HTTPConduit.java:1336)*
> >> > >>> > * at
> >> > >>> > org.apache.cxf.transport.AbstractConduit.close(AbstractCondu
> >> > >>> it.java:56)*
> >> > >>> > * at org.apache.cxf.transport.http.
> HTTPConduit.close(HTTPConduit.
> >> > >>> java:652)*
> >> > >>> > * at
> >> > >>> > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageS
> >> > >>> enderEndingInterceptor.handleMessage(
> MessageSenderInterceptor.java:
> >> > 62)*
> >> > >>> > * at
> >> > >>> > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(Phase
> >> > >>> InterceptorChain.java:307)*
> >> > >>> > * at org.apache.cxf.endpoint.ClientImpl.doInvoke(
> >> > ClientImpl.java:516)*
> >> > >>> > * at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:
> >> 425)*
> >> > >>> > * at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:
> >> 326)*
> >> > >>> > * at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:
> >> 279)*
> >> > >>> > * at org.apache.cxf.frontend.ClientProxy.invokeSync(
> ClientProxy.j
> >> > >>> ava:96)*
> >> > >>> > * at
> >> > >>> > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProx
> >> > >>> y.java:138)*
> >> > >>> >
> >> > >>> > Is there a way to configure validation to trust non-selfsigned
> CA
> >> ?
> >> > >>>
> >> > >>> I guess that if you import only the Intermediate CA cert into your
> >> JKS
> >> > >>> as trusted certificate ,  certificate path validation doesn't
> >> required
> >> > >>> any more.
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>> > Best Regards,
> >> > >>> > Claude
> >> > >>>
> >> > >>
> >> > >>
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Colm O hEigeartaigh
> >>
> >> Talend Community Coder
> >> http://coders.talend.com
> >>
> >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>

Reply via email to