Outbound Web Services — Connection Failures & TLS Errors - Support and Troubleshooting

Outbound Web Services — Connection Failures & TLS Errors .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Contents

1. Issue 2. About HTTP 0 and -1 3. Root Causes 3.1 Certificate not trusted — Session contains no certificates - Untrusted 3.2 No subject alternative name 3.3 No issuer certificate found 3.4 Certificate revoked 3.5 mTLS failures — Socket is closed / Integration crypto failure 3.6 ConnectTimeoutException — host did not accept connection 3.7 DNS resolution failure 3.8 Socket closed / Connection reset (intermittent) 4. MID Server — Additional Diagnostics 5. Diagnostic Steps 6. Resolution Summary 7. Related Articles

1. Issue Outbound web service calls from ServiceNow fail before receiving a valid HTTP response. The failure occurs at the network or TLS layer — the call never completes a successful connection to the endpoint.

Symptoms this article covers:

Response status is HTTP 0 or -1 in sys_outbound_http_log . Error message contains: Session contains no certificates - Untrusted , No issuer certificate found , SSLHandshakeException , SSLPeerUnverifiedException: peer not authenticated , CertificateException: No subject alternative DNS name matching . mTLS call fails with Integration crypto failure protocol/Socket is closed or certificate_required . Error contains ConnectTimeoutException , The host did not accept the connection within timeout , or UnknownHostException . Intermittent Socket is closed or Connection reset errors. Call works from Postman or cURL but fails from ServiceNow. Call works in one environment (e.g. Production) but fails in another (e.g. Beta, UAT). Not covered here

If the endpoint returns a valid HTTP status code (401, 403, 500, etc.), the TCP connection and TLS handshake succeeded. That failure is not a connection or TLS issue. See Outbound Web Services — Authentication & Authorization Failures or Outbound Web Services — Endpoint Errors (4xx/5xx) instead.

2. About HTTP 0 and -1 HTTP 0 and -1 are not real HTTP status codes. ServiceNow sets the response status to 0 or -1 when the call never completed an HTTP exchange at all. The most common reasons, in order of frequency from case data:

The endpoint's SSL/TLS certificate is not trusted by ServiceNow or the MID Server JVM. The TCP connection timed out before the TLS handshake completed — typically a firewall block. A DNS resolution failure prevented the connection from being established. The socket was closed mid-handshake, most commonly with mTLS misconfigurations. The two diagrams below show where in the call path each failure type originates — first for direct calls, then for calls via MID Server.

Direct path (no MID Server):

Via MID Server:

HTTP 0 / -1: always start here

An HTTP 0 or -1 always means investigate the connection and TLS layer first, before looking at anything else. The Outbound HTTP log Response tab will contain the Java exception string that identifies the exact cause — find that string and match it to Section 3.

3. Root Causes 3.1 Certificate not trusted — Session contains no certificates - Untrusted The most frequent failure pattern in this category. ServiceNow's JVM trust store — or the MID Server's JVM trust store — does not contain the CA certificate that signed the endpoint's SSL certificate.

The full error typically appears in the Outbound HTTP log Response tab as:

org.apache.commons.httpclient.HttpException: Session contains no certificates - Untrusted [ERROR CODE: -1] Session contains no certificates - Untrusted, errorCode:1 This happens most often when:

The endpoint uses a private or internal CA (not a public trusted CA). The endpoint's intermediate CA certificate is missing from the trust store. A specific CA (e.g. DigiCert, Entrust) rotated or added an intermediate that has not yet been imported. The instance was upgraded and the JVM trust store was not carried forward correctly. Resolution:

Import the endpoint's root and/or intermediate CA certificate into sys_certificate (X.509 Certificate table) in ServiceNow at Filter Navigator → System Definition → Certificates. For calls via MID Server, also import the certificate into the MID Server's Java CACerts file at /jre/lib/security/cacerts using keytool , or configure a trust store in the MID Server config.xml . Importing to sys_certificate alone is not sufficient for MID Server calls. If the instance JVM trust store is missing a well-known public CA (e.g. a DigiCert intermediate), open a HI ticket to request a trust store update — cloud-hosted customers cannot update the instance JVM trust store directly.

3.2 No subject alternative name — hostname mismatch The endpoint's SSL certificate was issued for a different hostname than the one being called. The full error:

[ERROR CODE: -1] java.security.cert.CertificateException: No subject alternative DNS name matching found Common triggers:

Calling an endpoint by IP address when the certificate is issued for a hostname. Internal APIs with certificates issued for a different internal FQDN. After a migration where the endpoint URL changed but the certificate was not reissued for the new hostname. Resolution:

Confirm the hostname in the REST/SOAP message endpoint URL exactly matches a Subject Alternative Name (SAN) on the endpoint's certificate. Use a browser or openssl s_client -connect :443 to inspect the certificate SANs. If the URL is correct but the certificate does not include the hostname as a SAN, the endpoint owner must reissue the certificate. The system property com.glide.communications.httpclient.verify_hostname controls hostname verification — review with your security team before disabling, as it weakens TLS security.

3.3 No issuer certificate found — incomplete chain The certificate chain is incomplete. ServiceNow received the endpoint's leaf certificate but cannot build a trusted chain to a root CA because an intermediate certificate is missing.

No issuer certificate found for Resolution:

Obtain the missing intermediate CA certificate from the CA's website (most public CAs publish their intermediate certificates). Import root → intermediate → verify the chain resolves. Intermediate certificates are imported into sys_certificate the same way as root CAs. For MID Server calls, also add the intermediate to the MID Server JVM cacerts.

3.4 Certificate revoked ServiceNow's OCSP (Online Certificate Status Protocol) check determined the endpoint's certificate has been revoked.

[ERROR CODE: -1] Server certificate cached revoked This can also appear intermittently if the OCSP responder is unreachable from the ServiceNow instance or MID Server host — the cached revocation status may be stale.

Resolution:

The endpoint owner needs to reissue a valid certificate. If OCSP is causing false positives due to network access issues to the OCSP responder, the property com.glide.communications.ssl.check_ocsp_revocation controls this behavior. Consult ServiceNow Support before modifying this property.

3.5 mTLS failures — Socket is closed / Integration crypto failure Mutual TLS (mTLS) requires ServiceNow to present a client certificate to the endpoint during the TLS handshake. Multiple failure patterns:

Error

Cause

Integration crypto failure protocol/Socket is closed

Client certificate or private key not correctly configured in the Mutual Authentication Protocol Profile

SSLHandshakeException: certificate_required

Endpoint demanded a client certificate but ServiceNow did not send one — Protocol Profile not attached to the message record

unsupported protocol or unsupported proto

TLS version or cipher suite mismatch between ServiceNow (or MID Server) and the endpoint

REST Msg Outbound: Error executing REST request: unsupported proto

Same as above — cipher or protocol version negotiation failed

Resolution for instance-side mTLS:

Verify the Mutual Authentication Protocol Profile is attached to the REST or SOAP message record under the Authentication field. Confirm the client certificate in sys_certificate has the private key imported — not just the public certificate. A certificate record without a private key cannot be used as a client certificate for mTLS. Test the connection using the Test related link on the REST message record to capture the exact TLS error. Resolution for MID Server mTLS:

The client certificate and key must be configured in the MID Server config.xml using the mid.ssl.keystore parameters. Importing the client certificate to sys_certificate in ServiceNow is not sufficient for MID Server mTLS — the MID Server JVM handles the TLS handshake independently. Check the MID Server agent log ( agent0.log ) for SSLHandshakeException or PKIX path building failed entries around the time of the failure.

3.6 ConnectTimeoutException — host did not accept connection The TCP connection attempt timed out. The endpoint never acknowledged the connection attempt.

org.apache.commons.httpclient.ConnectTimeoutException: The host did not accept the connection within timeout of 10000 This is distinct from a read timeout (where the connection succeeded but the response was slow). A connect timeout means the three-way TCP handshake never completed.

Common causes:

A firewall is blocking outbound traffic from the ServiceNow instance IP range to the endpoint. For MID Server calls: a firewall is blocking outbound traffic from the MID Server host machine. The endpoint is overloaded and not accepting new TCP connections. Wrong port in the endpoint URL — a common oversight after endpoint migrations. Resolution:

Confirm the ServiceNow instance IP range is whitelisted at the endpoint's firewall. ServiceNow publishes outbound IP ranges by datacenter — refer to the KB0745054 for IP range details. For MID Server calls, test connectivity directly from the MID Server host: telnet or curl -v https:// . If this fails from the MID Server host, the issue is network-side, not ServiceNow-side. Verify the port in the endpoint URL is correct and that no proxy configuration is required on the MID Server.

3.7 DNS resolution failure — UnknownHostException The hostname in the endpoint URL cannot be resolved to an IP address.

[ERROR CODE: -1] java.net.UnknownHostException: Resolution:

Confirm the hostname is publicly resolvable via DNS. Use nslookup or dig from any external machine to verify. For internal endpoints (private DNS namespaces not resolvable from the public internet), the MID Server is the correct routing path. Direct calls from the ServiceNow cloud instance cannot resolve internal DNS names — route the call through a MID Server on the same internal network as the endpoint. For calls already routed through a MID Server, confirm DNS resolution works from the MID Server host machine specifically: nslookup from the MID Server host.

3.8 Socket closed / Connection reset (intermittent) The socket was closed unexpectedly after the connection was established. These errors appear intermittently, often after a period of inactivity.

[ERROR CODE: -1] Socket is closed Socket error: Connection reset java.net.SocketException: Socket is closed The most common cause is a keep-alive connection being closed by a load balancer, proxy, or firewall between the caller and the endpoint — the connection appeared open on the ServiceNow or MID Server side but had already been silently closed on the network side.

Common network intermediaries that cause this pattern:

Zscaler SSL inspection appliances Customer-managed proxy servers with short idle connection timeouts Load balancers between the MID Server and the endpoint Resolution:

These errors are typically intermittent and self-resolve on the next retry. A single occurrence is not a signal to open a case. If the pattern is persistent or occurring at a high rate, check whether a proxy or SSL inspection device (Zscaler is a frequent culprit) sits between the MID Server host and the endpoint. Review the proxy or SSL inspection device's idle connection timeout settings — they may be shorter than ServiceNow's connection keep-alive window. For Zscaler specifically: check whether the integration endpoint's domain is excluded from SSL inspection, or whether the MID Server's egress traffic bypasses Zscaler entirely.

4. MID Server — Additional Diagnostics When the call routes through a MID Server, the connection and TLS checks happen on the MID Server host machine, not the ServiceNow instance. This has three critical implications:

The endpoint must be reachable from the MID Server host. Instance-side network tests are irrelevant. A successful curl from your laptop does not confirm the MID Server can reach the endpoint. The MID Server has its own JVM trust store. Importing a certificate into sys_certificate in ServiceNow does not automatically update the MID Server trust store. Both must be updated independently. mTLS client certificates must be configured in MID Server config.xml , not just in the ServiceNow instance certificate table. MID Server logs to check Navigate to Filter Navigator → MID Server → MID Servers, open the relevant MID Server record, and check the Log Files related list. Alternatively access the agent log directly on the MID Server host at /logs/agent0.log .

To correlate the log to a specific failed call:

Open the ECC Queue record for the failed probe ( ecc_queue , filter by Source = your MID Server, State = Error or Processed). Note the ECC Queue record's Created time. Search the MID Server agent log for entries within that time window containing the following strings: SSLHandshakeException PKIX path building failed No issuer certificate found peer not authenticated Socket is closed ConnectTimeoutException UnknownHostException Note

The MID Server log will often contain a more detailed error than the Outbound HTTP log. For certificate chain failures in particular, the MID Server log shows the full PKIX path building failure including which CA is missing. Always check both logs.

5. Diagnostic Steps Open the Outbound HTTP log record. Navigate to Filter Navigator → Outbound HTTP Requests ( sys_outbound_http_log ). Filter by URL contains your endpoint URL. Open the failing record and read the Response tab — the Java exception string is the primary diagnostic signal for every failure in this article. Match the error string. Find the exception text in the Response tab and match it to the root cause in Section 3 . The resolution summary table in Section 6 provides a quick lookup. Confirm the call path. Is the call going through a MID Server? Check the REST or SOAP message record for the MID Server field. If it is populated, the connectivity check is from the MID Server host — move to step 5. For direct calls: test the same request from Postman or curl from outside ServiceNow. If it also fails, the problem is on the endpoint or network side. If it succeeds, the problem is specific to the ServiceNow certificate trust configuration — proceed to Section 3. For MID Server calls: test connectivity directly from the MID Server host using curl -v https:// . Check the MID Server agent log for TLS-level errors as described in Section 4 . Before opening a case, capture: Full error string from the Response tab in sys_outbound_http_log . Endpoint URL and port. Whether the call works from Postman or cURL externally. MID Server name if applicable. Which certificate or Protocol Profile is configured on the message record. MID Server agent log excerpt (if MID Server path).

6. Resolution Summary

7. Related Articles KB0659194 - Outbound Web Services — Troubleshooting Guide KB3067106 - Outbound Web Services — Authentication & Authorization Failures KB3067152 - Outbound Web Services — Timeouts & Slow Responses KB3067183 - Outbound Web Services — Endpoint Errors (4xx/5xx) KB0960404 — MID Server Landing Page