Following ServiceNow Product documentation, starting in Rome Patch 4, you can configure mutual authentication for the MID Web Server extension using the Transport Layer Security (TLS) protocol. Mutual authentication for TLS is called mTLS. During mutual authentication, the client authenticates the server's certificate, and the server authenticates the client's certificate. (link)

On ServiceNow support pages, there are many Knowledge Articles on that topic, however, every time someone wants to establish this type of connection, looks like it is not as easy as described in the KBA.

I decided to write a Community Article about that, hope you can use it to play with that functionality.

Please note, that my setup is based on a self-signed certificate! Officially connection between MID Server and the platform with self-signed certificate is not supported. Additionally, this can be used for a dev environment, but I would not recommend using a self-signed certificates in Production environment.

Said that, let's start.

First thing – CA, what it is? CA stands for a Certificate Authority – an entity that is trusted and can confirm the identity of the certificate requestor. So, if we want to establish an encrypted connection between two hosts, we need to encrypt that connection with the Public Key of the one host that is confirmed by CA that the second host trust, so the connection can be established. In my case confirmation of the identity is done based on the signed-off by the CA certificate of the host.

Now, what is a self-signed certificate?

The self-signed certificate is a certificate signed off by CA, but that CA is not known/trusted by any official CAs = can be created by anyone. If we know who created that CA, and we trust that person/organization, we can use it, but as I mentioned above, for the Production environment it is not recommended to use a self-signed certificate.

Coming to the ServiceNow platform – let's check prerequisites.

Before we start creating the certificates, we need to ensure that our platform is ready for that.

How to check this?

First thing is to check if our infrastructure is already migrated to a modern version of the load balancer – ADCv2.

We can do it using the command:

curl -I https://<instance-name>

If as a result, you can see “Server: snow_adc” – that means your instance is already migrated. If the result is different, you need to raise a support case to migrate your instance to ADCv2.

Next thing is to check if your instance has enabled TLS support. How..?

Use command:

curl https://<instance-name>/adcv2/supports_tls -w ‘\n’

If the result is ‘true’ or ‘mixed’ – your instance is ready. If the answer is different, you need to raise a support case to enable TLS support on the instance (Warning! Requires node restart).

The instance is ready, so we can move forward.

The next thing would be to install a MID Server on the Virtual Machine. All required information can be found in Product Documentation (link).

After installation of the MID Server and making it running, do not validate the MID. Check if the MID is connected to the platform, if needed allow an update, but do not validate it, as if MID has been validated, it will require additional steps to make the MID Server ‘clean’ and ready (relevant KBA with procedure how to do that you can find on Now Support).

An important pre-requisite for the MID is that java in the supported version has to be properly installed on the (virtual) machine, including set the system variables like JAVA_HOME.

Time to start playing with CA and certificates.

Note: for MID Server I propose to use an alias = a hostname – that makes it all easier for maintenance.

Regardless of the platform OS, if that is Windows or Linux, commands are the same, but if you are not working on a root account in Linux, for most of them you need to add ‘sudo’ in front. The only difference is with the format of the PEM file, but I will highlight that later.

1. Stop the MID Server
   ./stop.sh
   Note: command should be run from agent folder.