Let's say your HPEL or SystemOut log contains something like this.

[6/24/25 23:34:38:892 CDT] 00000080 WSX509TrustMa E   CWPKI0062E: SSL HANDSHAKE FAILURE:  Host name verification error while connecting to host [dmgr.example.com].  The host name used to access the server does not match the server certificate's [Subject Alternative Name [dnsName:node.example.com]].  The extended error message from the SSL handshake exception is: [No subject alternative DNS name matching dmgr.example.com found.].

This error suggests that the SSL handshake could not be established between the WebSphere deployment manager and WebSphere node because the SSL certificate being presented by the WebSphere node does not contain a Subject Alternative Name (SAN) for the WebSphere deployment manager. In this example, the SSL certificate being presented by the WebSphere node does not contain Subject Alternative Name (SAN) dmgr.example.com.

This probably occurs when attempting to federate a WebSphere node into the WebSphere deployment manager or when attempting to synchronize the WebSphere node with the WebSphere deployment manager.

The serverindex.xml file (e.g. /opt/WebSphere/AppServer/profiles/your_profile/config/cells/your_cell/nodes/your_node/serverindex.xml) will list the ports being used by the node, something like this.

<specialEndpoints xmi:id="NamedEndPoint_1528464832906" endPointName="SOAP_CONNECTOR_ADDRESS">
  <endPoint xmi:id="EndPoint_1528464832906" host="node.example.com" port="12345"/>
</specialEndpoints>

The openssl s_client command can be used to display the SSL certificates being presented by the WebSphere node, using the node hostname and SOAP port.

~]# echo | openssl s_client -connect node.example.com:12345 --showcerts
CONNECTED(00000003)
depth=2 CN = RootCA
verify return:1
depth=1 DC = com, DC = example, CN = IntermediateCA
verify return:1
depth=0 C = US, ST = CALIFORNIA, L = Guam, O = Acme, CN = node.example.com
verify return:1
---
Certificate chain
 0 s:C = US, ST = CALIFORNIA, L = Guam, O = Acme, CN = node.example.com
   i:DC = com, DC = example, CN = IntermediateCA
-----BEGIN CERTIFICATE-----
MIIMADCCCuigAwIBAgITQgAAC+SO7owHpwpwZAADAAAL5DANBgkqhkiG9w0BAQsF
ADBKMRMwEQYKCZImiZPyLGQBGRYDY29tMRswGQYKCZImiZPyLGQBGRYLVGhyaXZl
bnRTdGcxFj...a7qw2A==
-----END CERTIFICATE-----

Let's put the BEGIN CERTIFICATE to END CERTIFICATE block into a file named my.pem and then use the openssl x509 command to display the details of the certificate. Something like this should be returned. This should contain the same Subject Alternative Names (SAN) that were being displayed in the error message in the HPEL or SystemOut log. Notice in this example that the SSL certificate being presented by the WebSphere node does not contain a Subject Alternative Names (SAN) for the WebSphere deployment manager (dmgr.example.com in this example).

~]$ openssl x509 -in my.pem -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: DC = com, DC = example, CN = IntermediateCA
        Validity
            Not Before: Jan 30 21:29:37 2025 GMT
            Not After : Jan 30 21:29:37 2026 GMT
        Subject: C = US, ST = CALIFORNIA, L = Guam, O = Acme, CN = node.example.com
        Subject Public Key Info:
            X509v3 Subject Alternative Name:
                DNS:node.example.com

The SSL certificate being presented by the WebSphere node should be the SSL certificate in the key.p12 file (e.g. /opt/WebSphere/AppServer/profiles/your_profile/etc/key.p12). The Java keytool command can be used to list the entries in the key.p12 file. In this example, there is a PrivateKeyEntry with alias node.example.com.

~]$ keytool -keystore /opt/WebSphere/AppServer/profiles/myNode/etc/key.p12 -storetype pkcs12 -list
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SunJSSE
Your keystore contains 1 entry
node.example.com, Jun 25, 2025, PrivateKeyEntry,

The Java keytool command can be used to display the details of the PrivateKeyEntry, which should return similar output that was returned by the openssl s_client command, most importantly, the Subject Alternative Names (SAN).

]$ keytool -keystore /opt/WebSphere/AppServer/profiles/myNode/etc/key.p12 -storetype pkcs12 -list -alias node.example.com -v
Enter keystore password:
Alias name: node.example.com
Creation date: Jun 25, 2025
Entry type: PrivateKeyEntry
Certificate chain length: 3
Certificate[1]:
Owner: CN=node.example.com, O=Acme, L=Guam, ST=CALIFORNIA, C=US
Issuer: CN=IntermediateCA, DC=example, DC=com
Valid from: Thu Jan 30 15:29:37 CST 2025 until: Fri Jan 30 15:29:37 CST 2026
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
#8: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
  DNSName: node.example.com
]

Thus the most likely resolution to this issue is to ensure the key.p12 files being used by the node contain a Subject Alternative Name (SAN) for the deployment manager. It is noteworthy that if you update the key.p12 files being used by the node, you will probably want to restart the deployment manager, node agents, and WebSphere application servers to ensure the updated key.p12 file is being used.

• FreeKB - IBM WebSphere - Start Stop or Restart a Node
• FreeKB - IBM WebSphere - Start Stop Restart Node Agent
• FreeKB - IBM WebSphere - Start Stop or Restart a network deployment manager
• FreeKB - IBM WebSphere - Start Stop or Restart an application server

If the issue persists, I would next check to see if you have the com.ibm.ssl.defaultCertReqSubjectDN property set at Security > Global Security > Custom properties. If you do, and if the value contains a common name (cn) that is not included in the Subject Alternative Names in key.p12, you may need to update the com.ibm.ssl.defaultCertReqSubjectDN property to have one of the Subject Alternative Names in key.p12.