Deploying the new production Entrust certs to Connect for the eHealth Exchange (Sequoia)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Deploying the new production Entrust certs to Connect for the eHealth Exchange (Sequoia)

mmccune
Hi All,

Can anyone provide a keystore and truststore dump of the certs used by CONNECT under an environment setup for the eHealth Exchange (Sequoia)?  I need to see the correct setup with the new Entrust root and intermediate certs which were released around June 1, 2017.  Of course, any sensitive security information can be removed.

We have deployed the new set of Entrust certs to our trust store (and kept the older set in our trust store as well), but we could no longer validate incoming patient discovery (PD) requests.

We are using CONNECT 4.2.1.

There is a potential bug in the WSS4J open source (utilized by CONNECT) with our version of CONNECT:
https://issues.apache.org/jira/browse/WSS-583
Topic: crypto.verifyTrust can fail when the DN of the issuer is more than once in the truststore

I'm thinking that's not our issue, as even the most recent release of CONNECT does not have a version of WSS4J in which the issue was fixed.

Below is a snippet of the stack trace we see with all 4 Entrust certs deployed to our trust store:

Caused by: org.apache.ws.security.WSSecurityException: General security error (Error during certificate path validation: signature check failed)
        at org.apache.ws.security.components.crypto.Merlin.verifyTrust(Merlin.java:838)
        at org.apache.ws.security.validate.SignatureTrustValidator.verifyTrustInCert(SignatureTrustValidator.java:213)
        at org.apache.ws.security.validate.SignatureTrustValidator.validate(SignatureTrustValidator.java:72)
        at org.apache.ws.security.validate.SamlAssertionValidator.verifySignedAssertion(SamlAssertionValidator.java:121)
        at gov.hhs.fha.nhinc.callback.cxf.CONNECTSamlAssertionValidator.checkSignedAssertion(CONNECTSamlAssertionValidator.java:303)
        at gov.hhs.fha.nhinc.callback.cxf.CONNECTSamlAssertionValidator.validate(CONNECTSamlAssertionValidator.java:284)
        at org.apache.ws.security.processor.SAMLTokenProcessor.handleSAMLToken(SAMLTokenProcessor.java:188)
        at org.apache.ws.security.processor.SAMLTokenProcessor.handleToken(SAMLTokenProcessor.java:78)
        at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:396)
        at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:274)
        ... 28 more
Caused by: java.security.cert.CertPathValidatorException: signature check failed
        at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:159)
        at sun.security.provider.certpath.PKIXCertPathValidator.doValidate(PKIXCertPathValidator.java:351)
        at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:191)
        at java.security.cert.CertPathValidator.validate(CertPathValidator.java:279)
        at org.apache.ws.security.components.crypto.Merlin.verifyTrust(Merlin.java:814)
        ... 37 more
Caused by: java.security.SignatureException: Signature does not match.
        at sun.security.x509.X509CertImpl.verify(X509CertImpl.java:426)
        at sun.security.provider.certpath.BasicChecker.verifySignature(BasicChecker.java:160)
        at sun.security.provider.certpath.BasicChecker.check(BasicChecker.java:139)
        at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:133)

Thanks,
Mike
Reply | Threaded
Open this post in threaded view
|

Re: Deploying the new production Entrust certs to Connect for the eHealth Exchange (Sequoia)

Minh
Administrator
hi Mike
The issue that wss4j reports is slightly different than what ehealth exchange partners are facing after rekey Production Root.  We have patched several versions but will need to work on a patch for 4.2.  I will reach out to you directly to discuss timelines and installation of the patch.

Thanks,
Minh-Hai Nguyen
CONNECT Product Team Member
Reply | Threaded
Open this post in threaded view
|

Re: Deploying the new production Entrust certs to Connect for the eHealth Exchange (Sequoia)

mmccune
Hi Minh,

It would be great to get a fix for 4.2.  Let me know if you need more logging or if you need SSL debug logging turned on to make sure that the issue is correctly identified.

Thanks again,
Mike
Reply | Threaded
Open this post in threaded view
|

Re: Deploying the new production Entrust certs to Connect for the eHealth Exchange (Sequoia)

johnhd_at_zen
Yup, we ran into this same issue and came to the same conclusion. The workaround is to install head certs of all the effected partners you're connecting with:

http://forums.connectopensource.org/org-apache-cxf-binding-soap-SoapFault-General-security-error-Error-during-certificate-path-validatioh-td7580669.html#a7580705

This patch going back as far as 4.2 is news to me. Minh, is or will there be one for 4.4.1?
Ask The Experts: http://consultzen.com/
Reply | Threaded
Open this post in threaded view
|

Re: Deploying the new production Entrust certs to Connect for the eHealth Exchange (Sequoia)

mmccune
Thanks for the "head certs" suggestion.  The fix is working for us in production, so that is great news.

On Fri, Dec 1, 2017 at 2:30 PM, johnhd_at_zen [via CONNECT Community Forum] <[hidden email]> wrote:
Yup, we ran into this same issue and came to the same conclusion. The workaround is to install head certs of all the effected partners you're connecting with:

http://forums.connectopensource.org/org-apache-cxf-binding-soap-SoapFault-General-security-error-Error-during-certificate-path-validatioh-td7580669.html#a7580705

This patch going back as far as 4.2 is news to me. Minh, is or will there be one for 4.4.1?


To unsubscribe from Deploying the new production Entrust certs to Connect for the eHealth Exchange (Sequoia), click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: Deploying the new production Entrust certs to Connect for the eHealth Exchange (Sequoia)

johnhd_at_zen
mmccune wrote
The fix is working for us in production, so that is great news.
Meaning a hotfix was implemented that allowed you to trust the two Sequioa intermediate CAs properly so you did not need to install head certificates? (Or you needed to install head certificates?)
Ask The Experts: http://consultzen.com/
Reply | Threaded
Open this post in threaded view
|

Re: Deploying the new production Entrust certs to Connect for the eHealth Exchange (Sequoia)

mmccune
No need to install head certificates.
We have both the legacy Entrust certs and the latest Entrust certs (issued on/around June 1, 2017) installed in our trust store.

Thanks,
Mike

On Fri, Dec 1, 2017 at 5:14 PM, johnhd_at_zen [via CONNECT Community Forum] <[hidden email]> wrote:
mmccune wrote
The fix is working for us in production, so that is great news.
Meaning a hotfix was implemented that allowed you to trust the two Sequioa intermediate CAs properly so you did not need to install head certificates? (Or you needed to install head certificates?)
Ask The Experts: http://consultzen.com/



To unsubscribe from Deploying the new production Entrust certs to Connect for the eHealth Exchange (Sequoia), click here.
NAML