HTTPS Connection Fails Due to Certificate SAN (subject alternative DNS name) mismatch (4382667)

A HTTPS connection attempt fails with an error similar to: 

SSLHandshakeException: No subject alternative DNS name matching <hostname> found

while a client validates a certificate presented by the remote HTTP server.

The failure occurs during TLS handshake, before any application data is exchanged.

This issue can affect any HTTPS client, including agents, services, scripts, or applications.

The hostname used in the HTTPS URL doesn't match any entry in the server certificate’s Subject Alternative Name (SAN) field.

Important notes:

• Modern TLS requires SAN matching: the certificate Common Name (CN) is ignored).
• The hostname in the URL must exactly match a DNS: entry (or IP: if connecting by IP).
• This is a certificate identity mismatch, not a trust or encryption issue.

The certificate being validated belongs to the remote HTTPS service (the server being contacted), not to the client.

Restarting the FMS, FglAM, or the agent doesn't affect this certificate.

Fix the certificate on the remote HTTPS service

1. Identify the HTTPS server
   
   • Determine which system and application are listening on <hostname>:<port> (this is the HTTPS server being contacted).
2. Reissue or replace its certificate
   • Update the certificate used by that HTTPS service so that Subject Alternative Name (SAN) includes the exact hostname(s) used by clients.
   • The hostname shown in the error message must appear as a DNS: entry in the SAN.
3. Restart the correct service
   1. Restart the remote HTTPS service running on <hostname><port> so it bgins presenting the updated certificate.

The restart is performed on the server hosting the HTTPS endpoint, not on the client. 

Note: Do not restart the FMS or FglAM. They act only as HTTPS clients and do not present certificates in this connection.

openssl s_client -connect <hostname>:<port> -servername <hostname> | openssl x509 -noout -text