Sectigo AddTrust External CA Root IssuesSummarySectigo AddTrust External CA Root Issues On 30 May 2020 the Sectigo (formerly Comodo) AddTrust External CA Root certificate expired. The Sectigo/Comodo article on this issue (see Additional Information) explains that this was a kind of 'cross' certificate to cover the years it can take for their newer USERTrust RSA Certification Authority (Root CA) certificate to be accepted into all relevant client applications (browsers etc). Having both the newer USERTrust RSA Certification Authority (Root CA) and older Sectigo (formerly Comodo) AddTrust External CA Root certificate enabled on your webserver/API endpoint means there are two potential 'trust chain' paths to validate your webserver/API endpoint's certificate. After 30 May 2020 one of these trust paths will fail to validate. Many modern web browsers can intelligently pick the working path and ignore the failing one. However other TLS client applications, including the libraries used by ServiceNow as well as Openssl versions 1.0x, will see the failing trust path and see the certificate as invalid. The fix for this would be to remove the certificate trust path related to the expired certificate AddTrust External CA Root on the webserver/API endoint side. Please contact your webserver/API endpoint administrator about this. For any questions about these certificates and how they're managed please contact Sectigo (formerly Comodo). Checking If You're Affected by this Issue On the Instance If you see this error message when trying to make an outbound TLS connection from the instance (examples: a REST or SOAP outbound call (REST Message, SOAP Message), LDAPS connection) you may be affected by this issue: org.apache.commons.httpclient.HttpException: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated Using External Websites Both https://www.sslshopper.com and https://www.ssllabs.com will flag whether server is affected by this issue. The message from sslshopper.com will look something like this: Whereas ssllabs.com will show multiple Certification Paths Using the openssl Command To confirm whether you're affected by this issue you can run the openssl command (usually available on Linux or MacOS machines, may need separate installation on Windows) to confirm whether the AddTrust External CA Root certificate is being used by the remote server. Versions 1.0x of openssl will fail to validate the the certificate if the expired AddTrust External CA Root is on one of the trust paths (refer Fixing the Breakage from the AddTrust External CA Root Expiration under Additional Information): openssl s_client -connect <endpoint>:<port>" -showcertsCONNECTED(00000005)depth=1 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Rootverify error:num=10:certificate has expirednotAfter=May 30 10:48:38 2020 GMTverify return:0depth=1 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Rootverify error:num=10:certificate has expirednotAfter=May 30 10:48:38 2020 GMTverify return:0depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Rootverify error:num=10:certificate has expirednotAfter=May 30 10:48:38 2020 GMTverify return:0---Related LinksSectigo Chain Hierarchy and Intermediate Roots https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000rgSZ FAQ: Sectigo AddTrust External CA Root Expiring May 30, 2020 https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA03l00000117LT Third party Blog Post: "Fixing the Breakage from the AddTrust External CA Root Expiration" https://www.agwa.name/blog/post/fixing_the_addtrust_root_expiration Redhat KB: Sectigo Root and Intermediate Certificate Expiry - May 2020 https://access.redhat.com/articles/5117881 UC Berkely article: ADDTrust External Root Expiration May 2020 https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020