Start a conversation

The Sequoia Project X.509 Certificate FAQ

**WARNING** Entrust has re-keyed the eHealth Exchange VALIDATION environment.  Please see question 54.

Question 1: What is the URL for uploading our Certificate Signing Request (CSR) and receiving the signed certificate for Carequality or the eHealth Exchange?

Answer: Entrust provides two different web applications for obtaining certificates, one for PRODUCTION certificates and a different one for VALIDATION certificates.  Also note that Carequality only uses PROD certs.


PRODUCTION: To obtain a PROD certificate use the following URL:



(use this end point)


VALIDATION: To obtain a VAL certificate, use the following URL: 




(use this end point)

 Question 2: How do we obtain a PRODUCTION or VALIDATION certificate?

Answer: If you are part of the eHealth Exchange trust domain, then you should send an email to techsupport at sequoiaproject dot org to start the process.  We'll respond with more instructions.  For a Carequality certificate, please contact your Carequality Implementer (CI) for assistance.  The CI has direct access to obtain and securely provide your information to Sequoia. The CI will send this information to Sequoia and that will initiate the process of obtaining a Carequality certificate.


Question 3: Why do you require a specific person to be named and identity proofed (Notarized) as a X.509 certificate Subscriber?

Answer:  Current Federal Bridge Certification Authority (FBCA) policy is that certificates are issued to human subscribers only, not to departments, not to companies, and not to devices. The Sequoia Project issues certificates under this policy in order to maintain interoperability with federal Participants for both the eHealth Exchange and Carequality.

Quoting from:

Section 1.3.4 Subscribers states “A Subscriber is the user or device to whom or to which a certificate is issued. FBCA Subscribers include only FPKI Management Authority personnel and, when determined by the Federal PKI Policy Authority, network or hardware devices. Where certificates are issued to devices, the entity must have a human sponsor who is responsible for carrying out Subscriber duties.”

Additionally, section Authentication of Human Subscribers, for FBCA medium assurance, applies for the identity proofing process proper. 


Question 4: Who should sign the Entrust agreements and be Notarized?

Answer: Typically an executive or senior IT manager that MUST:

  1. Understand how to securely manage X.509 certificates at all phases of their lifecycles,
  2. Understands the technology behind X.509 certificates, PKI, operations, secure data centers,
  3. Be authorized to enter into binding a contract on behalf of the organization that signed the DURSA, and
  4. Must be an direct employee of the organization that signed the DURSA (not a vendor, contractor or member of a child company).

Often this executive is a CIO, CTO, CMIO, or Director of IT of the organization that signed the DURSA.  In many cases this person, known as the Subscriber, will work with someone else at the organization, such as a contractor or a vendor to securely obtain, install and manage the certificate.  In all cases, the Subscriber is responsible for secure management of the certificates at all times, even if the installation occurs by someone else.  The Subscriber must, for example, ensure that the certificate codes are only transmitted using secure means to the person installing the certificate.

Question 5: Why are Sequoia Managed CA certificates only issued for 12 months for production/validation use?

Answer: This is as per common Entrust policy for our Managed CA environments.


Question 6: Why do your instructions require the use of the Reference Code for the X.509 CN (Common Name) field in the CSR?

Answer: The Reference Code, is one of two values we provide to a Subscriber, which then allows that Subscriber to upload the CSR, have it signed by Entrust, for subsequent downloading and installation.  A Reference Code is not part of X.509 terminology; it is specific to Entrust. This allows the Managed CA environment the ability to associate your Certificate Signing Request (CSR) with our authorization for our system to sign your public key/certificate.  Once our Managed CA system determines the legitimacy of your request, then the CN containing your Reference number is replaced with your Fully Qualified Domain Name (FQDN) in the DN of your X.509 Subject field.  To confirm this, you can use a certificate inspection tool.


Question 7: When I first install and attempt to use it the new Entrust cert, why do I receive an error indicating that it is not trusted?

Answer: You must also install the Entrust validation and production root certificates in your trust store in order for your certificate, and those of your trading partners, to be trusted.  This is a separate step that only has to be done the first time you add the Sequoia certificate to your trust store.  From then on, until the Sequoia intermediate or root certs expire, you only need to install your re-issued server certificate, not the Entrust root certificate or intermediate certificate.  This step is needed otherwise your environment will likely view the certificate as being issued under an unknown, and thus untrusted, trust chain.  Once the Entrust root and intermediate certificates are installed, then your environment should automatically trust any valid certificate presented to it by other Subscribers in the same trust domain. But your environment will still likely need to be configured to filter out all other certificates from other trust domains. See questions 37, 38, and 46 for more critically important information.


Question 8: Do we need to install a certificate for each eHealth Exchange or Carequality gateway?

Answer: No.  If you follow the instructions in the Certificates Guide and in this FAQ (install the Entrust root cert and intermediate certs) then your environment should automatically trust any valid certificate presented to it by other Subscribers in your trust domain.  The eHealth Exchange is one trust domain, and Carequality is another trust domain.  See questions 7, 37, 38, and 46 for more critically important information.  In summary, each Sequoia initiatives (Carequality and eHealth Exchange) has its own trust domain established by a legal framework, and a technical trust implementation.  The root certificates for each.


Question 9: Does Sequoia PKI services support certificate revocation?

Answer: Yes.  We support revocation via both an OCSP Responder Network and CRLs.  The X.509 certificate contains fields pointing to the correct CRL location, and the to the OCSP responder network service end point.  See also questions 10, 11, 50 and 51.


Question 10: Who can revoke certificates?

Answer: This is covered in the Entrust agreements.  Only the identity proofed Subscriber may manage, obtain, hold, or revoke a PROD certificate. See also questions 9, 11, 50 and 51.


Question 11: What are the responsibilities of the Subscriber?

Answer: This is covered by the Entrust agreements, FBCA policies, and industry best practices.  In summary, your private key should never leave the server it is intended for, and must be deployed by trusted staff in a secure environment.  See also questions 9, 10, 50 and 51.


Question 12: Can we use our PROD certificate in the VAL environment or vice versa?

Answer: No.  You can only use the PROD certificate in the PROD environment, and you can only use the VAL cert in the VAL environment.  In addition, your VAL environment must not contain any real data; it must only contain synthetic data.


Question 13: Why do you require the mobile telephone number of the production Subscriber?

Answer: To help ensure the security of the X.509 acquisition codes, we use two separate modalities to send the codes.  Often we will send 1/2 of the codes via one method, and the other 1/2 via mobile phone making it more difficult to intercept. The codes are of the highest importance and must be handled securely. See question 40 for more critically important information.


Question 14: Will Sequoia Support Staff notify us before our certificates expire?

Answer: No.  Each organization is responsible for tracking PROD and VAL environment certificate expiration dates and notifying us before the expiration date that a reissued certificate is desired.  eHealth Exchange Participants should file a support ticket.  Carequality Connections should work with their Carequality Implementers to initiate the process of getting a new certificate.


Question 15: How long much ahead of time should we notify the Sequoia Support Staff that we want a new or re-issued certificate?

Answer: We generally issue or re-issue certificates in 1-3 business days.  Please request the certificate enough ahead of time that you have adequate time to replace the certificate.  It is advisable to install the certificate at least 1 week ahead of the expiration date of the prior certificate to allow for any problems.  Most organizations notify Sequoia about 2 weeks ahead of time. 


Question 16: Can Sequoia Support Staff assist in installing our certificate?

Answer: No.  We don't have knowledge about your specific environment and thus cannot officially plan to assist.  Normally the only assistance we can offer is to re-issue certificate codes to allow you to attempt to download and install it again.  However, staff will attempt to provide a limited degree of additional assistance.  The best practice is to have your software vendor engaged and ready to assist in installing your certificate.  With advanced notice, Support Staff may be able to be on standby state in case the certificate installation fails and you need us to re-issue the certificate acquisition codes.


Question 17: Can we use another vendor for our certificates?

Answer: No.  The Sequoia Project initiatives (Carequality, eHealth Exchange) establish trust domains via certificates issued by Sequoia Managed CA services.  


Question 18: Can eHealth Exchange or Carequality certificates be used for other purposes besides securing and transacting transactions for that initiative?

Answer: The eHealth Exchange has adopted a policy and associated operational procedure to allow for certificate re-use, under certain circumstances, at the risk of the Participant.  Please see eHealth Exchange Operating Policy and Procedure #9.  Carequality's Technical Trust Policy makes a very similar statement, that certificates can be used for other, limited purposes, also with the risk being placed on the Subscriber. See question 49 for more information.


Question 19: Does Sequoia Support Staff ever have access to our private key?

Answer: No.  It is an industry best practice that private keys used for digital signatures never leave the possession of the person or computer for which that private key is intended.  We support this practice.  Specifically, your organization should generate its own private/public key pair, and its own certificate (which contains your public key but not your private key).  You would then upload only your public certificate to us, we would sign it, and then you would then install this on your server or server cluster.  In summary, the only information Sequoia would possess would be fully public information (your public certificate and your public key) and we would not possess or have any access to your private key. 


Question 20: Can our eHealth Exchange gateway be configured to trust non-eHealth Exchange certificates?  Can our Carequality gateway be configured to trust non-Carequality certificates?

Answer: See question 18.  In general, the answer is "no", that you should configure your trust store should trust exactly and only certificates issued in the trust domain (Carequality or eHealth Exchange) of which you are a member.  Your gateway must be configured to perform client authentication at the 2-way-TLS OSI/ISO networking layer.  At the application OSI/ISO layer your gateway must confirm that all inbound messages contain a valid XML Digitially Signed SAML 2.0 assertion and timestamp, signed by a valid Subscriber certificate issued under the Sequoia Managed CA, with all services running in FIPS mode.  Any other configuration may result in a breach and is not allowed, except as discussed in question 18.  In addition your deployment must filter based on the X.509 certificate Subject Distinguished Name components and only trust certificates with the correct values.  See questions 7, 37, 38, and 46 for more critically important information.


Question 21: What are the OIDs for your certificate policies for your PRODUCTION Intermediate CA?








All application policies.


Question 22: What are the OIDs for your certificate policies for your PRODUCTION Subscriber certificate?

Answer: 2.16.840.1.114027., All application policies


Question 23: How can we tell if our certificate is installed properly?

Answer: There are four recommended procedures.  1) Use a 3rd party SSL validation tool. A tools we often use is:  This tool should indicate that the host name resolves properly, that the certificate is presented, that some basic common bad keys are not used, the certificate is within is validity period, that the owner is correct, and that the certificate chains back to Entrust's root certificate. 2) Perform a "smoke test" by having your gateway successfully send an outbound and receive an inbound message to/from an exchange partner in the same trust domain (Carequality or eHealth Exchange).  3) You must also perform negative testing to ensure certificates issued under other trust domains are not trusted.  4) Ask Sequoia Support Staff to run a limited scope security test against your gateway by emailing a request to techsupport at sequoiaproject dot org. See questions 7, 37, 38, and 46 for more critically important information.


Question 24: Does the Sequoia issue client or server certificates?

Answer: We only issue server certificates (properly called "End Entity" certificates).


Question 25: Why won't Sequoia Support Staff issue certificates to IP addresses?

Answer: We only issue certificates to Fully Qualified Domain Names (FQDNs) that resolve, via DNS, to one or more public IPs address due to the CA/Browser Forum's deprecation of the issuance of certificates with non-FQDNs. Quoting from "As defined in the Baseline Requirements, the publicly-trusted SSL CAs will stop issuing certificates with non-FQDNs by November 1, 2015, and all unexpired certificates with non-FQDNs will be revoked by October 1, 2016. The CAs must also provide a warning of the deprecated use of such certificate to the applicant before issuance."  More information can be found at: and  As of October 2013, Sequoia Support Staff will no longer issue certificates to anything other than a FQDN other than for the Sequoia security testing tool.


Question 26: What is the Organization Unit (OU), Organization (O) and other values we should enter for our Certificate Signing Request (CSR)? 

Answer: For a validation certificate:

CN=<> (Replace this value with your Reference Number)





For a Carequality production certificate

CN=<> (Replace this value with your Reference Number)





For an eHealth Exchange production certificate

CN=<> (Replace this value with your Reference Number)





Note: Only enter the information after the equals sign '=' 

Note: If City and State are required fields for your CSR enter the City and State of your organization.

Note: Be sure to use the reference number for the CN in the CSR as discussed in question 6.

See questions 7, 37, 38, and 46 for more critically important information.


Question 27: Can we specify a Subject Alternative Name in the certificate?

Answer: Not at this time.


Question 28: Can we use key bit lengths of less than 2048 bits?

Answer: No. Your keys must be 2048 bits.


Question 29: Why don't you use SHA1 for public key digests?

Answer: SHA1 has been deprecated by the NIST and GSA.  So even though we formerly issued TEST keys with SHA1 digests, we rekeyed our TEST environment on 2014-01-14 to use SHA256 digests only.  As we issue keys that interoperate with federal agencies, we are subject to their more stringent requirements.  


Question 30: We understand that Entrust rekeyed the TEST Intermediate CA and root self-signed CA.  How can we obtain the old Intermediate and Root certs?

Answer: Entrust rekeyed our TEST environment on 2014-01-14 (see question 29 for more information).  The current best practice to avoid certificate errors in TEST is to install both the pre-Jan-14 Intermediate CA and Root CA certs and the post-Jan-14 Intermediate CA and Root CA certs in your trust store.  The current (post-Jan-14) Intermediate CA and Root CA certs are available on the same web portal page where you retrieved your signed CSR.  The old Intermediate CA and Root CA certs are available at the web portal AIA link:


Question 31: Does the Jan 14, 2014 certificate rekeying affect both TEST (aka VALIDATION) and PROD environments?

Answer: No.  This change only affects TEST.  PROD certs were already signed with SHA256 and are not impacted in any way by this change.


Question 32: Do we need to install both the old (pre Jan 14, 2014) and the new (post-Jan-14) TEST Intermediate CA and Root CA certs?

Answer: No. This was required during the transition to the new (post Jan 14, 2014) server cert and the associated new Intermediate and Root CA certs from old cert (prior to Jan 14, 2014). See question #30 for locations to obtain both cert chains.  Since all pre Jan 14, 2014 certificates have now expired, you should only trust the newer intermediate and root certificates and should remove any other Entrust certificates in your keystores unless you have a very deliberate reason to retain them.


Question 33: Are TEST/VALIDATION and PROD certificates interoperable?

Answer: No, by design.  We want to completely partition the TEST and PROD environments to ensure that no PHI ever enters into a TEST system.  It would be a significant error, for example, to have a PROD eHEx Gateway configured to trust TEST certificates.  Carequality does not use VAL certificates.


Question 34: Are eHealth Exchange AEGIS DIL certificates interoperable with the eHEX TEST/VALIDATION or PROD environments?

Answer: No.


Question 35: Can you help install the old and new TEST certificates in CONNECT (see question 32)?

Answer: The CONNECT team has developed a method for installing both the pre-Jan-14th and the post-Jan-14 Intermediate CA and Root CA TEST certs into the CONNECT truststore.  See the following URLs for more information.

See questions 7, 37, 38, and 46 for more critically important information.


Question 36: Why is our external security scan indicating that our Sequoia certificate is untrusted?

Answer: Many auditors, such as those in the consumer goods markets (PCI for example) are not familiar with the FBCA program.  Your auditor likely needs to become familiar with the FBCA program, and then add the appropriate additional root certificates to their trusted root certificates store.  In the case of the eHealth Exchange and Carequality, the appropriate certificate is the FBCA Entrust root cert.  More information may be found at the following links:  See questions 7, 37, 38, and 46 for more critically important information.


Question 37: How should our PRODUCTION x.509 certificate trust chain be configured?

Answer: There should be three levels in your trust chain: Your Server cert, the Entrust Intermediate (Signing) CA cert, and the Entrust Root CA (self-signed) cert. Below are more details.  Be sure to NOT install the FBCA cross-signed certs unless you have good reason.

The Entrust Root (self signed) CA cert:
- serial number: 4A:A8:A6:0D
- issued 11/16/2016
- valid until 12/16/2027
- issuer OU = Entrust Managed Services NFI Root CA, OU = Certification Authorities, O = Entrust, C = US
- subject OU = Entrust Managed Services NFI Root CA, OU = Certification Authorities, O = Entrust, C = US

The Entrust Intermediate (Signing) CA cert:
- serial number: 4a a8 b9 ea
- issued 5/16/2017
- valid until 11/16/2027
- issuer OU = Entrust Managed Services NFI Root CA, OU = Certification Authorities, O = Entrust, C = US
- subject OU = Entrust NFI Medium Assurance SSP CA, OU = Certification Authorities, O = Entrust, C = US

Your eHealth Exchange Server cert:
- serial number/dates (customer specific)
- issuer OU = Entrust NFI Medium Assurance SSP CA, OU = Certification Authorities, O = Entrust, C = US
- subject CN = (your FQDN), OU = NHIN, O = HHS-ONC, C = US

Your Carequality Server cert:
- serial number/dates (customer specific)
- issuer OU = Entrust NFI Medium Assurance SSP CA, OU = Certification Authorities, O = Entrust, C = US
- subject CN = (your FQDN), OU = CAREQUALITY, O = HHS-ONC, C = US


 See questions 7, 38, and 46 for more critically important information.


Question 38: How should our VALIDATION x.509 certificate trust chain be configured?

Answer: There should be three levels in your trust chain: Your Server cert, the Entrust Intermediate (Signing) CA cert, and the Entrust Root CA (self-signed) cert. Below are more details.  Be sure to NOT install the FBCA cross-signed certs unless you have good reason. Also note that Carequality does not issue VAL certificates.  Also please note in question 54 below, that you may be using either 2014 or 2016 signed intermediate certificates.  Please see that question and answer below for more information.


The Entrust Root (self signed) CA cert:
- serial number: ‎ 4d 38 23 51
- issued 06/31/2016
- valid until 12/31/2030
- issuer OU = DComRootCA, OU = Certification Authorities, O = Entrust, C = US
- subject OU =DComRootCA, OU = Certification Authorities, O = Entrust, C = US

The Entrust Intermediate (Signing) CA cert:
- serial number: 4d 38 24 28
- issued 07/06/2016
- valid until 12/06/2027
- issuer OU = DComRootCA, OU = Certification Authorities, O = Entrust, C = US
- subject OU = Entrust NFI Test Shared Service Provider, OU = Certification Authorities, O = Entrust, C = US

Your Server cert:
- serial number/dates (customer specific)
- issuer OU = Entrust NFI Test Shared Service Provider, OU = Certification Authorities, O = Entrust, C = US
- subject CN = (your FQDN), OU = NHIN-Test, O = nhin, C = US

See questions 7, 37, 46 and 54 for more critically important information.


Question 39: Why is our web application server indicating that certificates are revoked when they are not?

Answer: Please see this article.  Although it is written for Windows environments, similar issues can occur on any environment. 


Question 40: How should I handle the Production codes sent by Sequoia Support Staff for my certificate?

Answer: It is important to understand that these codes are the keys to obtaining access to millions of patients’ data, therefore it is extremely important that they are handled correctly. The codes are issued by Support Staff directly to, and only to, the x.509 Subscriber.  These codes must not be shared with anyone other than the Subscriber and whomever the Subscriber trusts to actually obtain and install the certificate. Also, a reminder that the use of these codes is covered in the Entrust agreements that your Subscriber notarized and executed, and the associated Entrust and FBCA policies, and applicable state and federal law and regulations.


Question 41: How do I properly handle my X.509 PROD cert and private key?

Answer: Your private key should be treated as being highly confidential information and it should be handled with complete security. Thew PROD certificate allows your organization to access the network and all of its patients’ data. For this reason it is required that your organization take the necessary precautions to ensure that this certificate remains secure during its complete lifecycle. The following items should be followed (including but not limited to):

- Private keys MUST never be shared.
- Private keys MUST be created on the production server.
- Private keys MUST never leave the production server.
- Individuals MUST be familiar with X.509 key management best practices.
- Individuals MUST be familiar with applicable law and FBCA procedures and policies and this FAQ.


Question 42: Why do the eHealth Exchange and Carequality require operation under NIST FIPS 140-2 constraints for our cryptographic modules?

Answer: We operate our PKI under the FBCA federal Bridge Certification Authority program, which can be found here .  It states, in section 6.2.1 6.2.1 Cryptographic Module Standards & Controls, "The relevant standard for cryptographic modules is FIPS PUB 140, Security Requirements for Cryptographic Modules."  This requires that eHealth Exchange cryptographic libraries be listed on the CMVP list of approved modules, and must be running in FIPS mode.  Thus SSL 3.0 is not permitted.  This list changes frequently and implementers are responsible for on-going compliance. 


Question 43: Is SSL 3.0 allowed? How is it enforced?

Answer: SSL is not allowed and has never been allowed in the eHealth Exchange nor in Carequality. It is up to the Subscriber to enforce this policy in their gateway and ensure the proper security and checks are done when connecting/exchanging with others in the same trust domain. See the messaging platform specification section 3.4.1 from In addition, see question 43 for additional information of required operations.  See questions 7, 37, 38, and 46 for more critically important information.


Question 44: Can a VAL environment and a PROD environment have the same host name / FQDN?

Answer: No.  The VAL and PROD environments must have unique host names. In addition, they decided that the two environments must be isolated as per IT best practices (e.g. in two different servers and internal networks or VLANs).  Note that this question does not apply to Carequality as it only uses PROD environments.


Question 45: What are the best practices for handling X.509 Certificates?

Answer: Each Subscriber is responsible for appropriate implementation to ensure that exactly, and only, the correct certificates are trusted.  This is different for every environment.  So Sequoia is unable to provide a complete list of best practices or mandatory practices.  But one key MANDATORY practice is that each gateway MUST only trust certificates issued by the appropriate intermediate certificate and root certificate issued by Entrust (see questions 37 and 38). Furthermore, only server certificates which contain the appropriate Distinguished Name, Subject values should be trusted, as shown below:

  • For eHealth Exchange production OU = NHIN, O = HHS-ONC, C = US
  • For Carequalty production OU = CAREQUALITY, O = HHS-ONC, C = US
  • For eHealth Exchange Validation OU = NHIN-Test, O = nhin, C = US

See questions 7, 37, and 38 for more critically important information. 


Question 46: How should your truststores be configured?

Answer: As discussed in question 46, your environment is unique, so you are responsible for proper configuration to ensure exactly and only the correct certificates are trusted.  One important step is removing any other certificates in your gateway's application and 2-way-TLS truststores, other than the Sequoia Entrust FBCA cross-signed root and intermediate CAs.

See questions 7, 37, and 38 for more critically important information. 


Question 47: Are all certificates issued by the Sequoia to be trusted?

Answer: No. Your system should not accept inbound requests from an X.509 certificate Subject with a CN = in VALIDATION, or CN = in PRODUCTION.  These two FQDNs are only used for certificates issued to the eHealth Exchange UDDI which should never make outbound requests to any eHealth Exchange or Carequality responding gateway.  Your system should also only trust certificates issued to others in the same trust domain (eHealth Exchange, or Carequality, or both as appropriate).


Question 48: Why does The Sequoia Project support staff require a copy of my identification?

Answer:  As per FBCA we are required to confirm the identities presented to the notary. Please see: specifically section 3.2.3 which states, among other items:
The FPKIMA, Entity CAs and/or RAs shall record the information set forth below for issuance of each certificate:

If in-person identity proofing is done, a unique identifying number(s) from the ID(s) of the applicant, or a facsimile of the ID(s);

For the Basic and Medium Assurance Levels:
An entity certified by a State or Federal Entity as being authorized to confirm identities may perform in-person authentication on
behalf of the RA. The certified entity forwards the information collected from the applicant directly to the RA in a secure manner. Packages secured in a tamper-evident manner by the certified entity satisfy this requirement; other secure methods are also acceptable. Such authentication does not relieve the RA of its responsibility to verify the presented data.6a


Question 49: Where can I find the Carequality Technical Trust document?

Answer:  Please see:  for this document.


Question 50: Do we need to check for revoke certificates?

Answer:  Yes, using either CRLs or OCSP. See also questions 9, 10, 11, and 51.


Question 51: Do we need to check for expired certificates?

Answer:  Yes.  And your environment must be set up to check for expired certificates before it checks for revoked certificates since expired certificates are normally not revoked.  See also questions 9, 10, 11, and 50.


Question 52: How can we obtain the Entrust root certificate?

Answer:  This depends on your environment and tools.  Under a clean Windows environment, for example, you can simply view your server (End Entity) certificate and view, obtain, and install each of the certificates in the chain, including the Entrust root certificate. If your environment is not clean, you may get the wrong root and intermediate certificates.  Please see above for specific certificate serial numbers to confirm that you have obtained and installed the correct intermediate and root certificates.


Question 53: Does the eHealth Exchange support the use of Server Name Indication (SNI)?

Answer:  SNI is not allowed at this time, as per several eHealth Exchange Specification Factory discussions.  The reason is that SNI will not work unless all Participants implement it at the same time.  In addition, it is a breaking change as it is not backwards compatible for either the Initiator or the Responder.  In the future, the Spec Factory has indicated, that there is interest in adding SNI as a supported component of 2-way-TLS as used by the eHealth Exchange.  As a result, SNI is forbidden at this time for both sides of the 2-way-TLS connection.

Question 54: Did Entrust rekey the eHealth Exchange VALIDATION environment and how does my organization respond?

Answer: Yes.  Entrust has changed their root and intermediate certificates.  The new VAL certificates use a SHA256 signature hash algorithm and is valid until 2030-12-31. Note that this change is only for the VAL environment; PROD is not impacted. Specifically:

eHealth Exchange Participants using the Entrust VAL environment will need to install two new certs for a total of 3:

               New Entrust Root VAL Cert  (SN: ‎4d 38 23 51)       

               New Entrust Intermediate VAL Cert  (SN: 4d 38 24 28)

               Your Participant "server" Cert (just your cert, not your partner certs)

 The new Entrust Intermediate VAL cert (SN: 4d 38 24 28) can be obtained directly from Entrust, using Microsoft Internet Explorer, at the following URL: Once the page is displayed, select CA Certificates/Display on the left side navigation bar. The associated Entrust root VAL certificate (SN: ‎4d 38 23 51) can then be derived from this intermediate cert using commonly available tools.  The AIA for the Entrust root VAL cert, which should agree with the AIA from the Entrust intermediate VAL cert, is  This file contains multiple certs, and the one of interest is (SN: ‎4d 38 23 51). The old Entrust intermediate cert (SN: 4d 37 bd 5f) can be obtained by the below encoded string, which should not be trusted for anything critical, or directly from Sequoia staff.  If you would like to obtain a file containing all 4 of these certificates directly from Sequoia staff, please send an email to techsupport at sequoiaproject dot org.

New Entrust VAL Intermediate cert SN: 4d 38 24 28 (do not trust until you validate the authenticity and integrity of the certificate):


Question 55: Regarding the new 2016 Entrust VAL cert, does my organization need to obtain a new end entity certificate?

Answer: You should not have to.  

Question 56: Regarding the new 216 Entrust VAL cert, does my organization need to update it's intermediate certificate?

Answer: For outbound requests, you should not have to make a change to the certificates that you are presenting, assuming all was configured correctly before.  But you will likely need to add the new 2016 intermediate and/or root VAL certs to your truststores so that you trust both the 2014 and the 2016 VAL certs being used by your partners.

Question 57: Should our organization have both the root and intermediate certs installed in our truststores?  We prefer not to have the root certificates installed since we would then trust any organization with that root.

Answer: If your system is configured properly, then it should use end entity certificate Subject name filtering based on the OU= field as discussed above.  Thus it should not trust a certificate issued by the same root, or intermediate cert, unless all conditions are met. This is critically important to configure correctly, and your organization should confirm properly operation using positive and negative tests to ensure no certificates are trusted unless they are part of the eHealth Exchange or Carequality security domains, as appropriate.

Question 58: Do responding gateways need to use and validate the XML Digital signatures inside the SOAP Message SAML assertions?

Answer: Yes.  At a minimum responding gateways must validate the the signatures are present, that the hash confirms the data is intact, confirm that the key or certificate used to sign the message content is a trusted certificate issued under the eHealth Exchange or Carequality trust chain, that the certificate is not expired, on hold, or revoked.  For XML-Dsig using RSA keys, then the responding gateway will likey want to implement certificate "pinning" from the 2-way-TLS connection so that the asserting party's certificate can be easily obtained and used for validation.  For XML-Dsig using the X509 version, then the certificate is directly contained in the message.  In both RSA and X509 cases, the obligations are the same in terms of confirming the integrity and authenticity of the XML-Dsig and its associated hash and content.  Note that this section of the XML SOAP message is flagged as "mustUnderstand" obligating the receive to understand and properly process the XML-Disg.  This behavior is also required to support durable non-repudiation of origin.  Put another way, full PKIX path validation of XML-Dsigs must occur.

Question 59: Where is the Entrust Policies and Certification Statement located?


If more information is needed related to certificate installation, please see the knowledge base article entitled Certificate Guide for Organizations which contains detailed instructions for some environments. Also the Entrust site maintains a list of approximately 40 different environments and instructions on how to install a GENERIC Entrust certificate in those environments.  We have not used these instructions and cannot vouch for them, but they may assist in installing a certificate for your environment.  Please keep in mind that the eHealth Exchange uses specific Entrust CA environments, not the generic Entrust environment. 


Question 60: How do Relying Parties know they can trust a given certificate?

Answer: This is, in part done, via PKIX path validation.  This is a standard, and required algorithm defined by the IETF.  Here is also a brief, and somewhat dated, white paper on the topic from one PKI vendor:

Choose files or drag and drop files
Was this article helpful?
  1. Eric Heflin

  2. Posted
  3. Updated