Securing MID Server - Agent Client Collector agents (TLS) (Utah)

[rfsnowman]

Our mid server was initially configured with a MID Web Server endpoint that uses a non-standard port for communication (8081). We also deployed the agent client collector to a few hosts, and were able to communicate with this clients without issue.

In an effort to collect from hosts behind a heavily restricted internal network zone, we would like to switch to using port 443 and ensure communication between the MID server and clients are secure.

The ServiceNow documentation is not very clear in this area. I can simply switch to using port 443 with the "Secure Connection" option enabled, but this results in the endpoint being accessible from the browser with a default certificate that does not validate the FQDN of the midserver.

We only need to access the mid servers from hosts internal to our network. We would like the mid server web endpoint to be secured with a certificate that allows for hostname validation. Can someone kindly give me guidance as to how to configure the MID servers to meet the above requirements? I'm not sure if mTLS is required, or if we can simply secure the web endpoint with an SSL certificate. Any help would be appreciated.

Thank You Kindly.

[Severin Launiau]

Hi @rfsnowman !

By default, the MID web server runs with a self-signed certificate. It is indeed recommended to replace this cert with a certificate signed by your internal Certificate Authority (CA) from your Corporate IT / PKI team. For more details with step-by-step guide, see the attachments from KB1122613 and download the pdf All About ACC over TLS.

Regarding the network access: you should run the MID on a network that has access controls enforced. Meaning, you shouldn't allow clients like your laptop's browser to connect to a service hosted on a MID if it is supposed to be dedicated to your restricted zone. If your networking team operates a load-balancer in that environment, you can place the MID web server behind a load-balanced service and only allow traffic coming from the LB. On the LB service itself, only allow access from your secure zone.

About mTLS: this is to authenticate the clients (ACC) to the MID. By default the MID web servers are configured to accept an api-key, which is mostly shared across multiple systems. You can create multiple API keys if you want dedicated keys per environment (prod vs. non-prod, colos vs. cloud vs. laptops, etc.) or just simply rotate the api-key without causing the agents to disconnect. Using mTLS does help with controlling the identity of the client: each client would have its own private key + signed certificate to authenticate with the MID. If your group does have the automation in place to handle client-side certificates on the target systems (running ACC), this is a good option to consider. Again, see the All About TLS doc for some examples.

I hope it helps!

Séverin

[Severin Launiau]

Hi @rfsnowman !

By default, the MID web server runs with a self-signed certificate. It is indeed recommended to replace this cert with a certificate signed by your internal Certificate Authority (CA) from your Corporate IT / PKI team. For more details with step-by-step guide, see the attachments from KB1122613 and download the PDF All About ACC over TLS.

Regarding the network access: you should run the MID on a network that has access controls enforced. Meaning, you shouldn't allow clients like your laptop's browser to connect to a service hosted on a MID if it is supposed to be dedicated to your restricted zone. If your networking team operates a load-balancer in that environment, you can place the MID web server behind a load-balanced service and only allow traffic coming from the LB. On the LB service itself, only allow access from your secure zone.

About mTLS: this is to authenticate the clients (ACC) to the MID. By default the MID web servers are configured to accept an api-key, which is mostly shared across multiple systems. You can create multiple API keys if you want dedicated keys per environment (prod vs. non-prod, colos vs. cloud vs. laptops, etc.) or just simply rotate the api-key without causing the agents to disconnect. Using mTLS does help with controlling the identity of the client: each client would have its own private key + signed certificate to authenticate with the MID. If your group does have the automation in place to handle client-side certificates on the target systems (running ACC), this is a good option to consider. Again, see the All About TLS doc for some examples.

I hope it helps!

Séverin