Implementation Guide: How to Set Up Outbound Mutual AuthenticationInstructionsBelow are steps that need to be followed to set up Outbound Mutual Authentication in ServiceNow. A. Create a Certificate We are sharing the commands below for informational purposes only. If you encounter any issues while running the commands, please work with your internal teams for assistance. Step 1: Create a Key Store (Certificate pair) using the keytool genkeypair command. The below command creates a key store that will have a public key and a private key. keytool -genkeypair -alias letstestcba -keyalg RSA -keysize 2048 -validity 365 -keypass ServiceNow123 -keystore letstestcba.jks -storepass ServiceNow123 Step 2: Once the Key store is created, we need to generate a CSR and get it signed by an external CA. keytool -certreq -alias letstestcba -file mycsr.pem -keystore letstestcba.jks Step 3: When you create a Certificate Signing Request (CSR) and submit it to a Certificate Authority (CA), you will typically receive the following certificates Server CertificateIntermediate Certificate(s)Root Certificate Step 4: In order to set up the Key store, we need to upload Certificates back to the Key Store. Use the below commands to upload the received certificates back to the key store. Import the Root Certificate: keytool -import -trustcacerts -alias root -file root.pem -keystore letstestcba.jks -storepass ServiceNow123 Import the Intermediate Certificate(s): keytool -import -trustcacerts -alias intermediate -file intermediate.pem -keystore letstestcba.jks -storepass ServiceNow123 Note: If there are multiple intermediate certificates, repeat this step for each, giving each a unique alias (e.g., intermediate1, intermediate2, etc.). Import the Signed Server Certificate: keytool -importcert -alias letstestcba -file SignedServerCert.pem -keystore letstestcba.jks -storepass ServiceNow123 Note: Ensure that the alias used in the above import command (Import the Signed Server Certificate) matches the alias used when you originally created the keystore and generated the CSR(.i.e alias used in Step 1 & Step 2). This binds the server certificate to the corresponding private key within the keystore. Please note that "ServiceNow123" is a sample password used in the above commands. When using these commands, please use your own passwords. The keystore is now ready for use. It needs to be uploaded to the ServiceNow sys_certificate table and mapped with the protocol profile. The detailed steps for this process will be explained in the upcoming sections. The following step is necessary only if you want to use a self-signed certificate. It explains how to export the public certificate from the keystore that was created in Step 1. Step 5: To use a self-signed certificate for this integration for testing purposes, run the following command to export the public certificate from the keystore directly after Step 1 (there is no need to run the commands mentioned in Steps 2, 3, and 4). Please note that it is not recommended to use self-signed certificates. It is always recommended to use CA-signed certificates. keytool -exportcert -alias letstestcba -file ServerCert.pem -keystore letstestcba.jks -storepass ServiceNow123 -rfc Please share the public certificate "ServerCert.pem" with the third-party team so they can add it to their trust store. B. Setting up the Key Store record in ServiceNow. > Navigate to System Definition -> Certificates > Click on New > Configure the Name > Select type "Java Key Store" > Enter the Key store password > Attach the created key store file. > Click on Submit > Click on the "Validate Stores/Certificates" related link to ensure that the file is attached correctly. If it is attached correctly, you will see the message "Valid key_store." C. Create a protocol profile > Navigate to System Security -> Protocol Profiles > Click on New > Configure a unique protocol name to register for this profile. For example: myhttps, mhttps > Select the key store that was selected in the above step > Configure the default port for this protocol profile. > Click on Submit D. Use Mutual authentication in the REST message > Create a REST message. > In the Authentication tab, check the "Use mutual authentication" checkbox. > Select the protocol profile that was created in Step C in the "Mutual authentication profile" field. > Click on the related link "Test" to test the REST message. The setup is complete. When the above REST message is triggered, ServiceNow makes an outbound REST call using 2-way SSL. During this process, the certificates in the specified keystore are used for the SSL handshake. The detailed process will be explained in the upcoming section. Related Links Mutual Authentication, also known as 2-Way SSL, involves ServiceNow acting as a client and a third-party application as the server in an outbound scenario. During mutual authentication, in SSL handshake the server (.i.e. Third-party App) sends a "Certificate Request" message containing a list of Distinguished Names (DNs) that it supports. Upon receiving the "Certificate Request" message, the client application (i.e. ServiceNow) responds with a "Certificate" message that includes the client certificate from the keystore associated with the protocol profile. The server (.i.e. Third-party App) then verifies the client certificate against its trust store before allowing further communication. Here, ServiceNow acts as the client and a third-party application acts as the server. Here's a detailed breakdown of the process: Client Initiates Connection: ServiceNow (acting as the client) initiates a connection to the third-party server.Server Sends Certificate Request: As part of the SSL/TLS handshake, the server sends a "Certificate Request" message to the client. This message includes a list of Distinguished Names (DNs) that the server trusts.Client Responds with Certificate: The client (ServiceNow) responds with a "Certificate" message. This message includes the client's certificate, which is retrieved from the keystore associated with the protocol profile.Server Validates Client Certificate: The server then checks the client's certificate against its own trust store. If the certificate is valid and trusted, the server allows the connection to proceed.SSL/TLS Handshake Continues: Once mutual authentication is successful, the SSL/TLS handshake continues, establishing a secure connection between the client and the server. This process ensures that both parties are authenticated and can trust each other before any data is exchanged, thereby providing a higher level of security. Below is the 2-way SSL handshake diagram.