MID Server requires DigiCert OCSP responder URL on HTTP port 80 open on customer firewalls Table of Contents What is OCSP and why?How is it used by ServiceNow MID Servers?Which URLs / IP addresses need opening? Testing connectivity with a BrowserTesting connectivity with Powershell on WindowsTesting connectivity with Curl on LinuxHow to confirm the specific URL from the Instance Certificate Why is it http port 80? What is OCSP and why? The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an digital certificate, such as ones used to secure Web Servers. All commonly trusted certificate authorities/vendors will have OCSP and/or CRL servers hosting revocation lists, allowing them to withdraw a certificate before its planned expiry date, perhaps when there is reason to believe that the private key of the certificate has been compromised. How is it used by ServiceNow MID Servers? Since the Orlando release, various Certificate security checks were added to the MID Server code, ending up as the MID Security Policy feature in the Quebec release. A MID Server that cannot contact the OCSP responder will treat that as a Failure of the check, and assume it may have been revoked, even though had it reached the responder it would know it wasn't revoked. A MID Server will not connect to the instance in this situation, and be in Down state. Remote debugging of that MID Server via the instance would therefore be impossible too. The agent log files from the installation folder of the MID Server are needed to diagnose the cause. Although it is possible for customer admins to disable the Revocation check for the connections to *.service-now.com, perhaps temporarily as part of debugging, this is not supported as a permanent solution due to the security risks it adds. Which URLs / IP addresses need opening? The CA's database is the only trusted location where a compromised certificate is recorded. The server URLs given by those CAs need opening. Since 2024/25 hosted instances have used a DigiCert certificate, which specifies the OCSP server as http://ocsp.digicert.com DigiCert list all their server URLs and IPv4/6 addresses here:https://knowledge.digicert.com/alerts/digicert-certificate-status-ip-address Note: Prior to 2024/25 hosted instances have used an Entrust certificate, which internally specifies the OCSP server as http://ocsp.entrust.netURLs documented here: https://www.entrust.com/knowledgebase/ssl/ip-range-for-entrust-revocation-crlocspThe change from Entrust to Digicert was documented here: KB1702083 Replacing Entrust Certificate Authority (CA) Testing connectivity with a Browser To test connectivity with the DigiCert OCSP server:Open a browser and go to http://ocsp.digicert.com/. You should see "CRL/CACERT Repository ". An error such as "This site can’t be reached" would indicate your firewall is blocking it. However browser proxy server settings may not be the same as what Java is using, even on the same host. Confirm using command line tests:- Testing connectivity with Powershell on Windows For a lower level test, this powershell command could be used: Invoke-WebRequest http://ocsp.digicert.com/ Testing connectivity with Curl on Linux curl http://ocsp.digicert.com/ philip.harcourt@localhost % curl http://ocsp.digicert.com<html><body> CRL/CACERT Repository</body></html> How to confirm the specific URL from the Instance Certificate Qualys SSL Labs have a useful certificate checking tool, which will give you the IP and certificate seen from a computer on the internet.https://www.ssllabs.com/ssltest/ Enter your instance URL. It will return something like Revocation informationCRL, OCSPCRL: http://crl3.digicert.com/DigiCertEVRSACAG2.crlOCSP: http://ocsp.digicert.com Revocation statusGood (not revoked) That should be the same certificate seen by the MID Server when connecting to the instance, unless an internal interception/inspection firewall is faking ServiceNow's instance certificate for doing a deliberate man-in-the middle to check the MID Server traffic. It is best to add a bypass to your firewall so that this is not done. Why is it http port 80? Certificate Authorities' OCSP responders tend to use http on Port 80. The Servers are not maintained by Servicenow. Servicenow has no influence on how these certificate vendors implement their OCSP/CRL server. If these servers were to use https/port 443, that would mean OCSP traffic is encapsulated within TLS traffic, but then since TLS needs certificate revocation, and OCSP is meant for Certificate Revocation check, there is no way to perform a revocation check for the OCSP request itself without going recursive.A potential proxy TLS service that proxies OCSP traffic to the right OCSP server. Client to proxy connection on port 443 and proxy to OCSP Server connection on port 80. This however would not change the security scenario in any way since there would still be a client reaching out to port 80.