Subject Name validation for responding gateways

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

Subject Name validation for responding gateways

vinish.viswan
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.

--
Thank You
Vinish K
--
Thanks & Regards
Vinish K
Sai
Reply | Threaded
Open this post in threaded view
|

Re: Subject Name validation for responding gateways

Sai
Vinish,


Set the property allowNoSubjectAssertion to false, all your security tests should pass.

Thanks,
Sai


On Mon, Nov 6, 2017 at 8:47 AM, vinish.viswan [via CONNECT Community Forum] <[hidden email]> wrote:
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. 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:
http://forums.connectopensource.org/Subject-Name-validation-for-responding-gateways-tp7580778.html
To start a new topic under Technical Issues, email [hidden email]
To unsubscribe from CONNECT Community Forum, click here.
NAML

Thanks & regards,
Sai, Valluripalli
Reply | Threaded
Open this post in threaded view
|

Re: Subject Name validation for responding gateways

vinish.viswan
Sai,

We did the configuration changes, but it did not pass the test. We are still getting the invalid Subject Name filtering error.

This is the error message we are getting.
 
-------------------------------------------------------------------
Scenario 00501: Negative test to determine if the Responding Gateway accepts a connection with a post June 1, 2017 OU=SEQUOIA Prod cert.
 
INFO: 00250 Response code: 500  Response: HTTP/1.1 500 Internal Server Error
Server: Apache-Coyote/1.1
Content-Type: application/soap+xml;charset=UTF-8
Transfer-Encoding: chunked
Date: Sat, 25 Nov 2017 19:46:15 GMT
Connection: close
 
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.
-------------------------------------------------------------------

Thanks
Vinish K
--
Thanks & Regards
Vinish K
Reply | Threaded
Open this post in threaded view
|

Re: Subject Name validation for responding gateways

vinish.viswan
Anyone from CONNECT team can you help us with this issue, any suggestions?

Thanks
Vinish K
--
Thanks & Regards
Vinish K
Reply | Threaded
Open this post in threaded view
|

Re: Subject Name validation for responding gateways

johnhd_at_zen
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)

Ask The Experts: http://consultzen.com/
Reply | Threaded
Open this post in threaded view
|

Re: Subject Name validation for responding gateways

vinish.viswan
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.

Thanks
Vinish K

--
Thanks & Regards
Vinish K
Reply | Threaded
Open this post in threaded view
|

Re: Subject Name validation for responding gateways

johnhd_at_zen
Hi Vinish,

This is venturing a little bit beyond what I'm familiar with, but a quick google yielded this:

https://docs.jboss.org/author/display/AS71/Security+Realms

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).

We used Mirth Connect in the scenario I discussed above, which is open source: https://www.mirth.com/

It needs to use a workaround or custom or licensed plugin to employ HTTPS (it doesn't come with it natively).

(If you want to go this route and need more direct assistance setting it up (e.g. options for HTTPS) I invite you to reach out to us at the information in my tagline, or just send me a DM.)

In any case, take a look and let us know what you think- it would be good to know what route works best for this case for others in the community.
Ask The Experts: http://consultzen.com/