ServiceNow ACC ERROR_040: Port 443 Was Open, but HTTPS Still Failed

ServiceNow ACC ERROR_040 appeared when I tried to bring back an agent that ITOM was showing as down. The installer reported that it couldn’t fetch a version file from the MID Server. TCP 443 was reachable, but the HTTPS request failed during certificate validation. I started with connectivity checks and narrowed it down to the Windows certificate store. Hostnames below are replaced with mid-server.example.com.

How I Got Here

ITOM was showing one of our Windows servers as down. An older version of the ACC agent was installed on it, and its automatic update had failed. I didn’t investigate why, and I don’t think it was a certificate problem, since the update also failed on a server where the current script ran without trouble. I reinstalled with the current installer script, which comes from the team that owns our ServiceNow ITOM setup, and that run produced ERROR_040.

That older agent had been installed by copying the agent files onto the server, not by downloading them from the MID Server. That difference matters later.

The Setup

• Windows Server with Windows PowerShell 5.1
• ServiceNow Agent Client Collector (ACC), installed with the current installer script
• A ServiceNow MID Server in the same corporate environment, reached over HTTPS (TCP 443), with TCP 8443 also used by the installer

The Symptom

The installation stopped with:

[ERROR_040]: Failed to download version file from Mid Server

That wording points at connectivity: DNS, a firewall rule, a port, or a MID Server that’s down. The PowerShell error underneath it said something different:

The underlying connection was closed:
Could not establish trust relationship for the SSL/TLS secure channel.

That message points at certificate validation, not the network.

First Check: TCP 443

Test-NetConnection mid-server.example.com -Port 443

TcpTestSucceeded : True

The TCP connection succeeded, so port 443 was reachable from the affected server. That didn’t confirm HTTPS was working. Test-NetConnection checks TCP connectivity only, and HTTPS also needs a TLS handshake and a certificate the client trusts. I tested the HTTPS request separately.

Reproducing the Request by Hand

Invoke-WebRequest https://mid-server.example.com -UseBasicParsing

On the affected server it failed with the same trust error the installer had shown:

Could not establish trust relationship for the SSL/TLS secure channel

That pointed at TLS or certificate validation instead of TCP reachability.

Checking TLS 1.2

I checked which protocols PowerShell was offering:

[Net.ServicePointManager]::SecurityProtocol

Default

The session was using the default value. I then forced TLS 1.2 explicitly and repeated the request:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest https://mid-server.example.com -UseBasicParsing

Same error. That fit what I found later in the installer script, which already enables the TLS protocols itself, TLS 1.2 included. Protocol selection wasn’t the cause.

Comparing With a Working Server

I ran the same request from another server where the current installer script worked. It returned:

HTTP 404 Not Found

while the affected server failed with the certificate trust error.

A 404 isn’t a successful application response. But getting one at all means the request had gone past TLS negotiation and certificate validation to the HTTP layer. My reading of how far each request got:

Working:  DNS → TCP 443 → TLS handshake → certificate validation → HTTP request → HTTP response
Failing:  DNS → TCP 443 → TLS / certificate validation → FAIL

What the Installer Was Doing

The installer script uses Invoke-RestMethod to pull version information from the MID Server, roughly:

$version = Invoke-RestMethod -Uri $versionUrl

When that call fails, the script produces ERROR_040:

Certificate trust failure
  → Invoke-RestMethod fails
  → version information not retrieved
  → ERROR_040

ERROR_040 was where the failure surfaced. Nothing in the script handles certificate trust. It expects the server to already trust the MID Server’s certificate chain, and when it doesn’t, the request fails and the script reports a download error.

The earlier installation method, copying the agent files onto the server, never made this HTTPS request. It may also not have checked the certificate at all, which would explain why an open port 443 was enough before. I haven’t compared the two methods in code, so that part is a guess.

Root Cause

The affected server didn’t have the Root CA needed to validate the MID Server’s certificate, and the installer script doesn’t handle that failure, so the version-file request failed and the script reported ERROR_040.

MID Server certificate
  → Windows certificate validation
  → required trusted CA not present
  → chain can't be trusted
  → HTTPS connection fails
  → ERROR_040

The Fix

I obtained the Root CA certificate behind our organization’s wildcard certificate, which the MID Server’s HTTPS certificate chains to, and installed it here:

Local Computer
  └─ Trusted Root Certification Authorities
       └─ Certificates

An intermediate CA exists in that chain too, but I didn’t install it. The Root CA alone was enough for the request to succeed.

A certificate added to Trusted Root is trusted by the whole machine, so confirm where it came from and compare its thumbprint with the issuer’s before importing it. I didn’t do the thumbprint comparison here, since it was our own organization’s CA, but it’s a step I’d treat as standard. Turning off certificate validation in PowerShell would have gotten the installer past the error too, and it would have hidden the problem instead of fixing it.

Verification

I repeated the HTTPS request to the MID Server URL. The result changed from the trust error to HTTP 404 Not Found, the same response the working server had given, so the request now reached the HTTP layer. I reran the ACC installer, and it got past the ERROR_040 stage. After the reinstall, ITOM showed the server as healthy again.

The failed auto-update is a separate question, and this fix didn’t answer it.

What I Took From This

Port 443 being open only proves TCP connectivity. HTTPS can still fail when Windows doesn’t trust the server’s certificate chain. Testing one layer at a time showed where this one broke:

Layer	Result
DNS	OK
TCP 443	OK
TLS protocol (forcing TLS 1.2)	Not the fix
Certificate trust	Failed
HTTP	Not reached
ACC installer	ERROR_040

The installer script assumed the server already trusted the MID Server’s certificate chain, and nothing in it said so. Switching from copying the agent files to downloading them from the MID Server also changed what the server had to trust. I’ve passed the script gap back to the team that owns it.

Quick Troubleshooting Checklist

•  DNS resolves the MID Server
•  TCP 443 is reachable
•  If the installer uses TCP 8443, verify it separately (I didn’t test it in this incident)
•  Invoke-WebRequest / Invoke-RestMethod can establish an HTTPS connection
•  TLS protocol configuration has been checked
•  The server certificate is valid
•  The certificate chain is trusted
•  The required Root and Intermediate CA certificates exist
•  The correct certificate store (Local Computer) is being used
•  The ACC installer succeeds after the fix

Related reading: The Agent Was Installed and Running. It Had Never Connected. covers a different ACC failure, where the service showed Running while backend-url pointed at 127.0.0.1.

Frequently Asked Questions

Does a successful Test-NetConnection on port 443 mean HTTPS is working?

No. It only shows that a TCP connection to the port can be opened. HTTPS additionally needs a successful TLS handshake and a certificate chain the client trusts. In our case TcpTestSucceeded was True while Invoke-WebRequest to the same host failed on certificate trust.

What does “Could not establish trust relationship for the SSL/TLS secure channel” mean in PowerShell?

It means the client couldn’t validate the server’s certificate chain. Common causes are a missing Root or Intermediate CA, an expired certificate, or a name mismatch. In our case the Root CA wasn’t in the server’s Trusted Root store. Forcing TLS 1.2 didn’t help, and the fix was installing the correct Root CA.