We are facing following issue on one of our 10.2.4 environment where executing a REST call is failing with "javax.net.ssl.SSLException: hostname in certificate didn't match" where as the certificate has the hostname "DNS Name=abc.services.ftl.corporate.com" and the same endpoint is working in 8.2.0 version. Can you please help understand if there is any additional verification happening in this case with 10.2 version and how we can resolve it!
Trapped Exception: hostname in certificate didn't match: <abc.services.ftl.corporate.com> != <aaa.ccp.corporate.com> OR <aaa.ccp.corporate.com>
Server Name Authentication is an optional enhancement to the TLS handshake wherein the client sends the name of the server to which it is connecting in the Client Hello.
The purpose of this enhancement is to allow a single server to host name based virtual servers whilst allowing each to have its own Certificate and Key pair. Prior to SNI, individual named servers would each require a server of their own or rely on a wildcard certificate and reside under a common domain.
With SNI, a single server may host multiple SSL virtual hosts, with the server itself identifying the correct target using the date held in the Client Hello.
For example, consider the following hypothetical example:
website1.fred.net and website2.eric.org are both hosted on the same server. Resolving their IP addresses shows them both to be located at 10.11.12.13.
Performing a reverse lookup of 10.11.12.13 shows that the canonical name of the host is myserver.mycorp.com. Connection directly to 10.11.12.13 confirms this to be valid
When connecting to https://website1.fred.net the client sends website1.fred.net in the Client Hello - this identifies the correct "site" for the server to use. Since the name is sent in the SSL negotiation, the name is unaffected by proxy usage.
The server is able, therefore, to return the correct certificate for the chosen site of website1.fred.net as opposed to the canonical site of myserver.mycorp.com or the alternative website2.eric.org
If SNI is suspected to be causing issues with connections from DevTest (or, more generally Java applications) then enabling SSL debugging will expose the characteristic signature of a connection being rejected immediately after sending the Client Hello - the collection will be closed from the server end and no Server Hello will be sent.
SNI and Java 8
There is a known issue with Java 8 supporting SNI correctly in all versions before 8u152. Versions after this should function correctly, but versions prior to this may not send SNI information when expected.
Supported versions of DevTest.
Upgraded to Java 8 u161 for the DevTest jre, following instructions in DevTest documentation in section: