After upgrading a Symantec Endpoint Protection (SEP) client to version 14.2, the client fails to communicate with the Symantec Endpoint Protection Manager (SEPM).
There are multiple errors that you may see in the CVE log. If the SEPM is configured to use a chained certificate (root > intermediate > server), you will see the following error:
[2018-Jul-23 11:02:12.108845] [WARN ] HTTPS certificates related error (60) SSL
certificate problem: unable to get local issuer certificate
On the impacted client, navigating to Help > Troubleshooting > Server Connection Status shows the following error:
"Peer certificate cannot be authenticated with given CA"
If the client attempts to connect to a SEPM address that is not listed as a Common Name or Subject Alternative Name in the certificate, you will see the following error:
[2018-Jul-24 13:49:01.158307] [WARN ] HTTPS certificates related error (51) SSL: no alternative certificate subject name matches target host name '10.1.10.10'
The SEPM is configured to use a certificate issued either by a third party or internal Certificate Authority for secure communications over HTTPS.
The SEP 14.2 client attempts to verify the certificate, but certificate verification is disabled in the Management Server List.
This issue is fixed in Symantec Endpoint Protection 220.127.116.11 (14.2 MP1) or later. For information on how to obtain the latest build of Symantec Endpoint Protection, see Download the latest version of Symantec Endpoint Protection.
To work around this issue, either:
|Verification and Error
The SEP client must connect to a hostname included as either a Common Name or Subject Alternative Name in the certificate. If the certificate was issued by a third party Certificate Authority, the certificate will not include an IP address.
To work around this issue, modify the management server list so that the client connects to an address that is valid for the certificate.
The SEP client must trust the root certificate, as well as any intermediate certificate in the certificate path.
If the certificate being used by the SEPM has an intermediate certificate, you can make the following changes to the SEPM configuration to work around the issue: