Subject Name validation for responding gateways

Subject Name validation for responding gateways

This post was updated on .

Hi,

We have used CONNECT 4.7 to integrate with CareQuality framework. During the testing process the CareQuality team said gateway is not properly performing subject name filtering. The gateway is accepting invalid OU name. The gateway should reject the requests with OU names other than carequality. Is there any configuration to solve this issue? Please help us to solve this issue.

We have used CONNECT 4.7 to integrate with CareQuality framework. During the testing process the CareQuality team said gateway is not properly performing subject name filtering. All the other tests pass. Is there any configuration to solve this issue? Please help us to solve this issue.
--
Thank You
Vinish K

--
Thanks & Regards
Vinish K

If you reply to this email, your message will be added to the discussion below:

FAIL: 00501 Responding Gateway appears to establish a TLS connection with a certificate it should not trust! It accepts a Subject OU that is incorrect. The Responding Gateway must implement x.509 Subject name filtering. Expected -1, 400, 401, or 403 received 500.
-------------------------------------------------------------------

Re: Subject Name validation for responding gateways

Re: Subject Name validation for responding gateways

I'm not on the CONNECT team, but I have some experience with this I can share.

I'm not clear on whether the allowNoSubjectAssertion config mentioned above would help or not, but I do have a decent understanding of what issue you're encountering- I've run into it in the past on a few occasions.

Sequoia requires you (Server) to validate some qualitative factors of the certificates for parties that connect to you (Client), beyond the traditional "is it in my trust store and/or signed by a CA that's in my trust store? Is it expired?", which is generally handled automatically by whatever libraries your application (or application server most likely) uses.

Sequoia specifically requires that your application check elements of the Distinguished Name (i.e. "Subject") of the client's certificate against a specific set of values.

The quick and dirty reference for what these values are in which contexts, along with a little bit of discussion, exists here, Under Question 45.

For posterity I'll paste it here:

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.

Note that in practice this applies to the actual SSL handshake process, not (just?) the certificate contained in the SAML header.

The reason for this as i understand it is that the issuing CA certificate used to sign Sequioa certificates is NOT dedicated strictly to CareQuality/EhealthExchange/Sequoia purposes; it's used to sign some other kinds of certificates (not sure which ones, I vaguely recall something about the FBI maybe?). So these other "non-Sequoia" certificates are issued by the same CA and would be trusted by conventional certificate validations steps, despite not being "Sequoia certificates". To make up for this, the decision was made to consistently apply these specific OU, O, and C values to each Sequoia (CareQuality / EhealthExchange) head certificate to differentiate them from the "others" signed by this same CA.

(I think it would have made a lot of sense to get a dedicated CA so all this overhead could have been avoided, but there may be some factors I'm not aware of that came into play for this design.)

Anyway, the only way to tell "Sequoia" from "Non-Sequoia" certificates in a situation like this is to check the O, OU, and C elements in the DN of the head certificate presented to you when a client connects to you. (The specific values differ depending on which network (EhealthExchange/CareQuality) and environment (TEST/PROD) you're "connecting" to as outlined in the FAQ question above.)

This validation can be challenging as most applications and application servers don't handle it natively or at least by default. There are solutions to handle this kind of check before the connection gets to your application which I believe most implementers do- some kind of firewall configuration I think, I'm not really sure. In our specific instances we actually applied a middleware that ran these validation steps using some custom code, before passing the connection through to CONNECT.

This was a long time ago, on a now-deprecated version of the CONNECT gateway so I'm not sure if some native support now exists to do this kind of checking. It's unlikely though, since the SSL handshake is typically handled by the application server (e.g. JBOSS/Wildfly, Glassfish, etc) and that's where adding this kind of check would probably need to happen (That said, I did find this very vague reference to a "checkDistinguishedName"...method? in the CONNECT JIRA, no corresponding results in the CONNECT WIKI though).

What application server are you using?

(Just a heads up if you haven't encountered this already, another similar challenge we encountered was that the CareQuality tests also test CRL & OCSP checking, which is disabled or nonfunctional in many environments by default)

Re: Subject Name validation for responding gateways

Thank You John.

We are using Jboss 7.1.1 as application server. We have CRLDP enabled in the system and it is working fine. But we still have Subject Name filtering issue. Any suggestion/inputs are greatly appreciated.

Re: Subject Name validation for responding gateways

It appears there is some means to configure a "security realm" in Jboss/Wildfly to perform this kind of validation. I recall discussing this issue (maybe 2 years ago now...) with someone familiar with how others had worked around this, and I believe implementing/modifying security realms (in Apache in his case) was the crux of the solution.

I'm not familiar with your network, but if you have some kind of proxy between the gateway and the outside world, it may be possible to do this check there as well.

If all else fails, it may make sense to set something up in the middle to pass the connection "through", purely for the sake of running this check (and the others such as CRL & OCSP will need to happen there as well).

Re: Subject Name validation for responding gateways

Administrator

Sorry for the delayed response.

Filtering of subject name values is handled by adapters so users can implement their own custom logic. Adding this validation to the CONNECT gateway has not been a prioritized request although you can certainly open a new feature request in our JIRA tracking system.

To be clear, this comes from the SAML information contained in the message itself, NOT from the actual client certificate that's used to establish the TLS connection, right? (I assume the answer is yes because the TLS connection is left to the application server, but I wanted to confirm.)

While in practice the same certificate is used for both SAML and TLS, Sequoia actually tests that you reject the TLS handshake (or respond with a HTTP failure response like a 403) if the head certificate was issued by the right CA but has the "wrong" O, OU, and/or C values in the subject line. The implication here is that you can't 'fudge it' by just checking the certificate information included in the SAML.

We have a few solutions that address this for Sequioa network connections that take place outside the CONNECT gateway and adapters. But if the adapters give us this information (directly from the client cert) && we can use the adapters to prompt a HTTP error response, that would lend itself to something more streamlined.