---
sourceDocument: Brazil ServiceNow AI Platform Capabilities
sourceDocumentLink: https://www.servicenow.com/docs/r/servicenow-platform

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil ServiceNow AI Platform Capabilities

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# Enable MID Server mutual authentication

# Enable MID Server mutual authentication {#ariaid-title1}

Release version: Brazil  
Updated October 8, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 6 minutes to read  
Configure the MID Server to use a client certificate for authenticating to the
instance. This avoids the need to create a basic authentication credentials in the Key Store
for the MID Server's configuration.

## Before you begin

Role required: admin

|-|
|   |
[ ]

{#install-mid-mutual-auth__table_jjd_jmj_bpb}

## About this task

MID Server mutual authentication removes the MID Server user name and password and
provides a client certificate for authentication. Whenever a server requests
authentication, this certificate is sent instead. To use mutual authentication,
certificate based authentication must be enabled. See [Set up Certificate-based
authentication](https://www.servicenow.com/docs/access?context=set-up-mutual-auth&version=brazil&pubname=brazil-platform-security&ft:locale=en-US) for the
procedure.

If a new MID Server is created with mutual authentication, it does not add
capabilities automatically. An administrator must add capabilities to its record on
the instance. However, existing MID Servers using basic authentication with
capabilities are preserved when switching to mutual authentication.

A MID Server using mutual authentication cannot be re-keyed or validated as a UI
action on the instance.

Self-signed certificates are not supported with mutual authentication. Internally
signed certificates are only supported when signed by a private certificate
authority. Commercially signed certificates are supported when signed by a commonly
trusted certificate authority, such as those trusted by browsers and operating
systems.

The ServiceNow instance must be able to reach the certificate's OCSP and CRL endpoints. Certificate revocation checks
require this access. An internally signed certificate whose OCSP or CRL endpoints are reachable only on an internal network is not supported, and validation fails.
You cannot disable the CRL check selectively or suppress log messages for unreachable CRL endpoints.

In the Quebec release, a MID Server using the Health Log Analytic application cannot
be configured with mutual authentication.

As a general guideline, use a unique mTLS certificate for each MID Server to limit the impact if a single certificate is compromised.  
Note:  
Certificate-based authentication is not supported on On-Prem or edge encryption-enabled instances.

## Procedure

1. Verify that the instance is set up with ADCv2 load balancers.  
   Run the following command and check the response's `Server` header: `curl -I https://<instance>.service-now.com`
   * If the `Server` header value is `snow_adc`, the instance is on ADCv2. Continue to the next step.
   * If the value is anything else, the instance isn't on ADCv2. Contact ServiceNow Support to request migration to ADCv2 load balancers before you continue.

   {#install-mid-mutual-auth__ul-mid-mutual-auth-adcv2-check}

   For additional technical details and troubleshooting information, see [KB1116112](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1116112).
2. Obtain a certificate and private key from the certificate authority.  
   RSA is the only supported key algorithm, and the key length must be 2048 bits. Keys shorter than 2048 bits fail validation with the error Insufficient key length.

   MID Server mutual authentication
   only supports the PEM bundle format and private key in PKCS#8 format. The bundle must have both the private key and certificate. Open the certificate using a text editor and see if it is in text format. The header and
   footer of the PEM syntax is the following:

        -----BEGIN CERTIFICATE----- 

        -----END CERTIFICATE----- 

   You can read the contents of a PEM certificate using the `openssl` command on Linux or Windows as follows: `openssl x509 -in cert.crt -text `. The private key must be in the PKCS#8
   format. The header and footer of the PKCS#8 syntax is the following:

        -----BEGIN PRIVATE KEY----- 

        -----END PRIVATE KEY----- 

    
   You can check the contents of a private key using the `openssl` command on Linux or Windows as follows: ` openssl rsa -in private.key -check `  
   Note:  
   If your certificate is not in PKCS#8 format, you get an error: `- main SEVERE *** ERROR *** Could not find valid private key`
3. Split up the PEM certificate into 3 different PEM files.  
   1. Private key and leaf certificate
   2. Leaf certificate
   3. Intermediate certificates and root certificate
   {#install-mid-mutual-auth__ol_zlk_gzx_dfc}
4. On the instance, upload file containing the intermediate and root certificates to the CA Certificate Chain table: sys_ca_certificate.list.  
   Note:  
   It is preferable to upload the root certificate and intermediate certificates as a single PEM bundle with the type set to CA Cert, rather than uploading them separately. If you choose to upload them individually, start with the root certificate followed by the intermediate certificates, and verify that the type is set to CA Cert for each, not Intermediate, as this is a platform requirement.
5. Check the uploaded CA Cert record on the instance and wait for the Publish Status to change to Exists.  
   Warning:  
   Do not proceed until the publish status is updated to Exists.
6. On the instance, navigate to sys_user_certificate.list.
7. Attach only the leaf certificate to sys_user_certificate.list without including the private key.
8. If the MID Server is validated, invalidate the MID Server before continuing.
9. Create a new record.  
   Note:  
   The record must have the MID Server's name and the User Role must be mid_server.
10. Attach the original, unsplit PEM certificate to the record.  
    Note:  
    Ensure that the attached file contains only the certificate.
11. If the MID Server is running, stop the MID Server.
12. On the MID Server host machine, run the following commands to install and manage the certificate and private key.  
    Run the script from the root of the agent directory because it requires the jar files in the class path. The security directory is then created in the agent root folder and is used by MID Server. For example:
    `bin\scripts\manage-certificates.bat -m.`  
    The manage-certificates has the following functions and the scripts must be run from the agent folder.

    Enable mutual authentication​

    :   For Windows, use the command: `bin\scripts\manage-certificates.bat -m`

        For Linux, use the command: `./bin/scripts/manage-certificates.sh -m`

    Remove mutual authentication and restore back basic authentication

    :   For Windows, use the command: `bin\scripts\manage-certificates.bat -b <myUserName myPassword>`

        For Linux, use the command: `./bin/scripts/manage-certificates.sh -b <myUserName myPassword>`

    Add new certificates and certificate chains with a specified alias​

    :   For Windows, use the command: `bin\scripts\manage-certificates.bat -a <alias> <fileName> `

        For Linux, use the command: `./bin/scripts/manage-certificates.sh -a <alias> <fileName> `

        The `alias` is a unique name given to the certificate being imported. The MID Server requires a custom certificate for mutual authentication, with the default alias name
        `defaultsecuritykeypairhandle`. To configure MTLS communication between the MID Server and instance, the certificate entry must be added to the key store using the alias name
        `defaultsecuritykeypairhandle`.

        The `fileName` is the path to a PEM bundle file that contains one or more certificates and a private key in PKCS#8 format. Include the private key and certificates in the following order:

             -----BEGIN CERTIFICATE-----
            Leaf certificate
            -----END CERTIFICATE-----

             -----BEGIN CERTIFICATE-----
            Intermediate certificate
             -----END CERTIFICATE-----

             -----BEGIN CERTIFICATE-----
             Root certificate
             -----END CERTIFICATE-----

             -----BEGIN PRIVATE KEY-----
             Private key
             -----END PRIVATE KEY----- 

        The private key can go at the top or the bottom of the file. If the file contains multiple certificates, order them as follows: leaf certificate, intermediate certificates, then root certificates. The system throws
        an exception if the certificate chain fails validation.

    Display certificate details for the specified alias

    :   For Windows, use the command: `bin\scripts\manage-certificates.bat -g <alias> ​`

        For Linux, use the command: `./bin/scripts/manage-certificates.sh -g <alias> ​`

        This command displays information such as subject distinguished name, issuer name, and expiry date from the certificate.

    List all existing aliases

    :   For Windows, use the command: `bin\scripts\manage-certificates.bat -l`

        For Linux, use the command: `./bin/scripts/manage-certificates.sh -l`

        This command lists all the alias names available in the agent_keystore.

    Delete certificates using an alias​

    :   For Windows, use the command: `bin\scripts\manage-certificates.bat -d <alias>`

        For Linux, use the command: `./bin/scripts/manage-certificates.sh -d <alias>`

        This command deletes the alias and record from the keystore. The entry for alias DefaultSecurityKeyPairHandle can be deleted using this command.

    Remove all entries from the keystore

    :   For Windows, use the command: `bin\scripts\manage-certificates.bat -r ​`

        For Linux, use the command: `./bin/scripts/manage-certificates.sh -r ​`

        This command deletes the existing entries from the keystore, except alias DefaultSecurityKeyPairHandle. ​
13. Start the MID Server.
**Related concepts**   

* [MID Server certificate check policies](https://www.servicenow.com/docs/kt_UvWhq81MUejjA6BN9Xg "MID Server uses four kinds of security checks to secure external traffic. The security checks use TLS/SSL certificate validation, hostname validation, Certificate Revocation List (CRL), and Online Certificate Status Protocol (OCSP) validation to improve security. Control these security checks with the MID Server certificate check policies table.")
* [MID Server authentication methods comparison](https://www.servicenow.com/docs/PEMk5upii5aIhj3S49hSaQ "The MID Server can authenticate to your instance using basic authentication, mTLS, or IPKI methods. The methods differ in what the MID Server presents, who issues and manages the certificate, and how access is revoked.")
* [MID Server authentication credentials and SOAP requests](https://www.servicenow.com/docs/9wvetsJqs56G~Q~aW0Htdg#mid-authentication-soap-requests "Set basic authentication credentials to update the web service invocation data. For added security, you can enforce basic authentication on each incoming SOAP request to the MID Server.")
* [MID Server unified key store](https://www.servicenow.com/docs/IIggrAjdtsLOp00Maw5dVg#mid-unified-keystore "The MID Server unified key store allows all products on the MID Server to use common certificates and key pairs. This feature allows applications to use the same secure communication channel to the MID Server that the MID Server uses to connect to the instance.")
* [MID Server Azure Key Vault integration](https://www.servicenow.com/docs/M9ieIpTkQhQdg2oNut_JVQ#mid_azure_key_vault_integration "The MID Server supports three authentication methods to retrieve credentials from Azure Key Vault without storing secrets on the instance.")
* [MID Server command audit log](https://www.servicenow.com/docs/EMXPRl6CVActj8Gxjhvhsg#mid-audit-log "The command audit log records the commands run by the MID Server for the Discovery application. Review the commands to verify there are no anomalies or errors.")
* [MID Server FIPS Enforced Mode](https://www.servicenow.com/docs/30QFWCTwwmrY11lS4oxyEA#mid-fips-enforced "The MID Server supports the National Security Cloud (NSC) IL-5 environment, which requires all utilized cryptography to be FIPS validated. The MID server can be run in FIPS Enforced Mode, where only cryptographic algorithms which are FIPS validated are utilized.")
* [MID Server Governance](https://www.servicenow.com/docs/QrJ47mqH2Xt60PORd8wg5g "Improve MID Server security by setting an automatic timeout to invalidate and shut down inactive MID Servers. You can enable this feature and set the inactivity timeout period globally and for each MID Server.")
* [MID Server IPKI authentication](https://www.servicenow.com/docs/1Kxkyuj3fB7eWGYCbyyAyA "Instance PKI (IPKI) lets a MID Server authenticate to its instance using a JSON Web Token (JWT) signed by an instance-issued certificate. Use IPKI when you want to authenticate MID Servers with certificates that the instance issues.")
* [MID Server unified key store](https://www.servicenow.com/docs/IIggrAjdtsLOp00Maw5dVg#mid-unified-keystore "The MID Server unified key store allows all products on the MID Server to use common certificates and key pairs. This feature allows applications to use the same secure communication channel to the MID Server that the MID Server uses to connect to the instance.")  
**Related tasks**   

* [Encrypt or decrypt MID Server configuration file values](https://www.servicenow.com/docs/Qxlwv2sniasrS9J61qYxGw "The value of any MID Server parameter in the config.xml file can be encrypted. The attributes for all encrypted values are managed from within the configuration file, including the security attribute of the login password.")
* [Rekey a MID Server](https://www.servicenow.com/docs/qZQ2XBnDjEoIwy6~F0zOQA "Rekey a MID Server to generate a new private key. Private keys are used to decrypt automation credentials, so that MID Servers can transmit information securely. Key pairs are initially generated when a MID Server is validated, and MID Servers should be rekeyed periodically to meet security requirements.")
* [Add SSL certificates for the MID Server](https://www.servicenow.com/docs/QOsQFUZoAYRrFyr2~2UDOg#add-ssl-certificates "Configure the MID Server to connect to a source over SSL.")
* [Attach a script file to a file synchronized MID Server](https://www.servicenow.com/docs/zB1jO4DdnnKCNeKatnsLTQ#mid-server-script-attach "You can attach a script file to synchronize to a connected MID Server. Windows Internet Explorer enhanced security blocks downloaded files that it determines are potentially dangerous. However synchronizing the files avoids this security problem.")
* [Install custom certificates in the MID Server unified key store](https://www.servicenow.com/docs/IIggrAjdtsLOp00Maw5dVg#mid-unified-keystore-install "Install custom certificates to unify the security channels for various applications.")  
**Related reference**   

* [MID Server configuration file security](https://www.servicenow.com/docs/Ei3fFdVw4e11enuKd53FDA "Sensitive MID Server configuration data can be protected using several different schemes, including internal and external data encryption and external data storage.")
* [MID Server SSH cryptographic algorithms](https://www.servicenow.com/docs/Dhad9OhghZGQbkbrb43rXA "The MID Server utilizes SSH clients to perform many discovery actions. During the SSH handshake, both the client and server first determine which algorithms both parties support, then client picks the highest priority algorithm. For the Host Key Algorithm, the client picks highest priority algorithm which both parties support that matches the key type.")

