We are using EMA with the RRT Optimized AWS endpoints. As such, the servers that we are trying to connect to appear to lie in our own network, and we have custom hostnames/IP addresses - but the actual servers are hosted by Refinitiv in Singapore.
We recently upgraded from EMA 3.5 to 3.6.1 (Java) to find we see the following error. It seems that the new EMA API is attempting to verify the TLS certificate hostname. This will naturally fail in an AWS endpoint scenario because we won't be using the Refinitiv hostname.
When we connect to the internal IP address, we see a certificate issued to 'apac-1-t1.streaming-pricing-api.refinitiv.com'.
We would like to disable TLS certificate verification (or at least the hostname verification). Although this is normally extremely reckless, because we are using an AWS endpoint, we know that the communication is not going to be subject to MITM attacks.
Here is the error we see in our logs. The presence of 'subject alternative DNS name' is proof that the problem is because of the TLS certificate verification.
Please help us to investigate why we saw this regression moving from EMA 3.5 to EMA 3.6.1 and let us know how we can address it (example: registering our own Java trust manager, or otherwise setting an option to disable the verification that EMA is passing to its HTTP client library.
[18:53:31,908] WARN [our process] main - loggerMsg
ClientName: ChannelCallbackClient
Severity: Warning
Text: Received ChannelDownReconnecting event on channel Channel_1
RsslReactor @6574a52c
RsslChannel @6c1a5b54
Error Id 0
Internal sysError 0
Error Location Reactor.processWorkerEvent
Error text Error initializing channel: errorId=-1 text=No subject alternative DNS name matching our-hostname.our-domain.com found.
loggerMsgEnd
