secure messenger and Epic

[David Barr]

The May 2021 release of Epic adds support for TLS encryption of HL7 interfaces. I’m trying to get this working and having problems. Does anyone else have this set up?

When I try to open a TLS connection with Cloverleaf as the server, Epic connects but immediately shuts down the communications daemon without sending any messages.

Topic

[Vince Angulo]

We don’t use this, but I believe the Secure Messenger add-on is required leverage this type of connection.

[David Barr]

We’ve got secure messenger.

I suspect that the problem is that Epic is trying to validate the server certificate for our HL7 interface using the root CA, but Cloverleaf isn’t sending the complete certificate chain, only the site certificate, and Epic is only looking at the root certificate, so there’s no way validation could be working. Is there any way to get Cloverleaf to send the certificate chain? This seems to be the recommended behavior based on this RFC: https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.2

 

[David Barr]

I contacted Infor support about this, and they were not able to help me resolve the problem. They suggested that I contact their services team or ask questions on Clovertech (which I’m already doing).

I think the root of the problem is that Cloverleaf is not sending the certificate chain on pdl-tcpip server connections with SSL enabled. Epic requires the chain in order to verify the certificate against the CA root certificate.

One recommendation was to use ServerAuth mode instead of Server mode, but this won’t work for us because Epic can’t send a client certificate.

I was able to get this working by routing the messages from Epic to HAProxy to Cloverleaf. This works because HAProxy can send the certificate chain without requiring client authentication (which is how 99% of the secure servers in the world work), but it defeats the purpose of using secure messenger in the first place.

Any recommendations would be appreciated.

[David Barr]

I’ve been making progress getting these interfaces between Cloverleaf and Epic working. I’ve run into one issue that I’m not sure about.

I’m using pdl-tcpip protocol on most of my interfaces with the mlp_tcp PDL. The inbound interfaces are set up using multi-server and SSL. We use multi-server because we have multiple Epic environments connecting to the same port on Cloverleaf for most of our interfaces. I ran into problems because there were some extra Epic environments (training environments) that don’t normally run interfaces. They had an old copy of my interfaces without TLS enabled. So I had TLS and non-TLS coming into Cloverleaf on the same port, and the non-TLS interfaces prevented the TLS interfaces from working. I thought there was supposed to be more segregation between connections on multi-server. Would you all expect that to happen?

Also, some of our interfaces are now using tcpip protocol rather than pdl-tcpip. Is one of these protocols preferred over the other?

We were able to combine the root CA certificate and signing certificate used by Cloverleaf in the Bridges CA file, and that fixed the issues I mentioned in my initial post. We also had to set file permissions on the certificate files so they could be read by the interface processes. They were initially only readable by the epicadm user, and that caused problems. Setting the profile variable VERBOSE_COMMUNICATION_ERRORS=1 on Bridges interfaces is also useful because it causes extra information to go to the error log.

[Cesar Ruiz]

how is TLS working for you now ?

[David Barr]

It’s working fine. All our interfaces between Epic Bridges and Cloverleaf have TLS enabled.

[Author]

Replies