Setting up mutual authentication Mutual authentication establishes trust by exchanging secure sockets layer (SSL) certificates. Before connecting to a server, the client requests an SSL certificate. The server responds by requesting that the client send its own certificate. Both respond by validating the certificates and sending acknowledgments before initiating an HTTPS connection. Administrators do the preliminary work of setting up a keystore and generating certificates before certification requests are fulfilled. Warning: This feature only enables mutual authentication on outbound https connections. The instance does not support mutual authentication on inbound requests. Creating the Key Store The instance currently supports uploading a Java keystore file to contain the private key, public certificate pair, and its signed certificates. The following steps use commands that allow you to generate a new Java Keytool keystore file, create a certificate signing request (CSR), and import certificates. Any root or intermediate certificates need to be imported before importing the primary certificate for your domain. Type these commands in a command line interface. Generate a Java keystore and key pair.keytool -genkey -alias mydomain -keyalg RSA -keystore my.keystore Generate a CSR for an existing Java keystore.keytool -certreq -alias mydomain -keystore my.keystore -file mydomain.csr Import a root or intermediate certificate authority CA certificate to an existing Java keystore.keytool -import -trustcacerts -alias root -file Thawte.crt -keystore my.keystore Import a signed primary certificate to an existing Java keystore.keytool -import -trustcacerts -alias mydomain -file mydomain.crt -keystore my.keystore Setting up the Key Store Now that the key store has been created, it can be uploaded to the Certificates table. On the System Definition > Certificates page, click New and set the following fields: Enter a certificate Name. Store the key store as Active. Set Type = Java Key Store. Provide a Key store password. This is the password that was used to create the keystore. Click Submit to create the Java Key Store entry.Figure 1. Keystore Specifying a Trusted Server Certificate During an outbound SSL connection, which is an HTTPS Web Service call, it is possible to specify a certificate provided by the service provider that ensures the validity of the service provider during the SSL connection. For example, a browser attempting to connect to a secure service which identifies itself by a certificate. By uploading the trusted server certificate, ServiceNow ensures that the service it is connecting to is valid and secure. Create a new Certificate entry with the type of "Trust Store Cert" and attach a DER formatted certificate, or copy and paste its PEM format into the PEM Certificate field. Processing Mutual Authentication Requests Figure 2. Certificate Exchange When a client requests the server certificate for authentication, a certificate signing request (CSR) is generated. To respond to a CSR, the server generates two unique cryptographic keys: A public key, which is used to encrypt messages to the server and a private key, which is used to decrypt messages. Both keys are kept in the Key Store. Keys are used to decrypt the client secure messages so they can be read by the server. Any outgoing connection that is going to be HTTPS verifies the certification by checking the Key Store, offering its public certification, and uses the trust store certificates to verify mutual trust back. To complete the secure link between the client and the server, the server matches the certificate to the corresponding private key. Because only the server has access to the private key, the server can decrypt the data from the client. Here is an example of a command that registers MYHTTPS with the com.glide.certificates.DBKeyStoreSocketFactory socket factory on port 443. The database key store factory is used during the SSL exchange process to offer a client certificate for mutual authentication.glide.httpclient.protocol.myhttps.class = "com.glide.certificates.DBKeyStoreSocketFactory" glide.httpclient.protocol.myhttps.port = "4433" Having the above configuration affects any outbound myhttps://host.domain.com/target URL to use the custom socket factory and exchange certificates during SSL.Note: Overriding the default HTTPS protocol socket factory affects every outbound HTTPS connection. This is usually undesirable. The server responds by sending a certificate. Is this a certificate that the client accepts? If yes, a message is sent to the server accepting the certificate and a secure channel is initiated. If the certificate is not accepted, it may mean that the root authority is needed for certification.