Thank you for your feedback.
Form temporarily unavailable. Please try again or contact docfeedback@servicenow.com to submit your comments.
Versions
  • London
  • Kingston
  • Jakarta
  • Istanbul
  • Helsinki
  • Geneva
  • Store
Close

MID Server security and encryption

MID Server security and encryption

Several options are available for you to enhance security on MID Servers, including credential and encryption security, the authorization of SOAP requests, and the establishment of secure socket layer (SSL) connections.

How MID Server encryption works

The MID Server login credentials appear in the config.xml file in clear text by default, but you can encrypt them. While the username and password are initially set in a config.xml configuration file on the MID server, once the MID server retrieves the credentials, it can replace the clear-text password with an encrypted password. For the encryption of the local MID server service account, the password is encrypted using an AES128 encryption algorithm. The MID server also maintains an encryption key that is generated each time it starts and remains in memory and not on the hard disk. When credentials need to be sent from the instance to the MID server, the following process takes place:
  1. The instance retrieves the encrypted password and the unencrypted username from the instance database table.
  2. The instance decrypts the encrypted password, and then re-encrypts it using the MID server encryption key. 

  3. The username and re-encrypted password are sent to the MID Server through the encrypted TLS session was already established between the MID server and the instance. 

  4. The MID server receives the credentials and decrypts the password in memory before using the credentials for remote operations. At no point is the credential password stored on the disk in an unencrypted format.

To enable this encryption, see Encrypt MID Server login credentials.

MID Server encryption keypairs

Automation credentials are secured by encrypting them in the instance with the MID Server’s trusted public key prior to transmission. When the MID Server is created, it generates a keypair, consisting of a public and private key. After the MID Server is validated, it can use the private key to decrypt automation credentials. You should occasionally rekey the MID Server to meet your organizations security requirements. See Rekey a MID Server for instructions.

SSL certificates

You can add certificates to the MID Server if you want communication to occur over SSL. You can add these certificates to the cacerts keystore file:
  • Signing Certificate Authority (CA) certificate
  • MID Server certificate

See Add SSL certificates for the MID Server for instructions.

Basic authentication credentials and SOAP requests

You can enforce basic authentication on each request. The MID Server is not able to communicate through a proxy server if the proxy server supports only NTLM authentication. You can use basic authentication with a proxy server or create an exception for the MID server host.

Supplying basic authentication information, regardless of whether it is required, has an added advantage. The web service invocation creates or updates data using the supplied credentials. For example, when you create an incident record, the journal fields have the user id of the basic authenticated user instead of the default Guest user. This behavior allows you to identify data added by a specific MID Server.

You can set basic authentication credentials for SOAP requests. See Use basic authentication credentials for a MID Server for instructions. Each SOAP request contains an Authorization header as specified in the Basic Authentication protocol.

Note: The setting for enforcing strict security controls how the instance uses the credentials you provide for the MID Server. When the setting is enabled, you must provide a user ID with access to the tables the MID Server is trying to access. When the setting is disabled, any valid user ID allows the MID Server to access to all tables.