How to configure inbound Certificate Based Authentication (mutual authentication) in ServiceNowSummaryHow to enable "Mutual authentication establishes trust by exchanging Secure Sockets Layer (SSL) certificates" through API including detailed explanations of each step. This article is meant only for inbound mutual authentication, known officially as Certificate-Based Authentication (CBA). For outbound mutual authentication, please refer to KB0696002. ReleaseQuebec and newerInstructionsNote: Certificate Based Authentication (CBA) for Inbound https connections is only supported starting with Quebec. Please also note that self-signed certificates are not supported for certificate based authentication. While the platform itself does support self-signed certificates, they are by default blocked by the system. Setting up Certificate-Based Authentication (CBA) Prerequisites: The instance should be on ADCv2, please check : Set up Certificate-based authentication and from there KB0952875 where the command line curl -I https://<instance>.service-now.com should show server: snow_adc if the instance is ADCv2 enabled.The instance needs to have mTLS enabled between ADCv2 and the ServiceNow instance (see Additional Information section). Enabling ADC-to-App mTLS requires a rolling restart of the application nodes, but does not cause any impact, since not all nodes are restarted at the same time. To check if Check ifADC-to-APP mTLS is enabled for your instance(s) access https://<instance_fqdn>/adcv2/supports_tls. A return value of "true" means the instance is configured for ADCv2-to-APP mTLS. If it returns false check with your support engineer to request that ADC-to-APP mTLS is enabled for your instance(s).The Certificate-based authentication plugin (com.glide.auth.mutual) for Now Platform has to be activated in the instanceThe owner/administrator of the 3rd party endpoint integrating with ServiceNow will need to be provide you with the client PKI key pair, containing the client certificate as a jks or pkcs12 file (for example) and all intermediate and root CA certificates for this client certificate (x.509 certificates in DER-encoded PEM format). These certificates are used for the SSL handshake between the two Web Services Endpoints that the "other" endpoint (not ServiceNow) is sending. Please note the certificates in PEM format all have to be enclosed in -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----. The client certificate that is mapped to the user will need to be the public certificate that matches the private certificate of the 3rd party endpoint that is talking to ServiceNow. Considerations: Enabling CBA for an instance does introduce some risk and should be tested in a sub-production environment first. When ServiceNow first started rolling out the CBA feature in early 2021, our initial approach was to enable optional client-to-ADC mTLS for all instances by default, while only advertising our own internal PKI CAs in the trusted certificate bundle during the TLS handshake. Customers could then add to this bundle by enabling CBA and uploading CA certificates to their instance. The philosophy being: since no customer clients will have client certificates issued by ServiceNow CAs, we should not receive any client certificates until customer CAs certificates are uploaded. Instead, we found that there are certain clients that will ignore the trusted CAs presented by the server, and will send their client certificate anyway. This can cause certificate validation errors at the ADC and result in HTTP 400 errors.Uploaded certificates must be in PEM format.Enabling mTLS requires rebooting the nodes. Since not all nodes are rebooted simultaneously, it is generally assumed that there will be no major impact. However, to prepare for any unforeseen circumstances, it is recommended to ensure a period during the update when access is restricted. Steps: Activate Certificate-based authentication, Set up Certificate-based authenticationRegister CA certificate Follow further steps on: Set up Certificate-based authenticationImportant: Import the root CA certificate for the SSL handshake's client certificate first, then the intermediate CA certificates in order from the root certificate to the lower level certificatesCertificates must be in PEM format. Other formats will fail to install on ADCv2 Map PEM certificate to user: This step will link the integration user for the mutual authentication that provides access to the data via roles and ACLs to the client certificate that is sent to the ADCv2 as part of the SSL handshake of the https protocol. The PEM certificate to load here is the public client certificate in PEM format, that usually is provided by the integration endpoint administrator.Overview of the entire setup - Set up Certificate-based authenticationRelated LinksHow Certificate Based Authentication (CBA) works When CBA is enabled and trusted CA certificates are added to an instance, they get deployed to the Application Delivery Controller (ADC) which is then configured for optional Client-to-ADC mTLS for that instance. This means that during the TLS handshake, the ADC will solicit for a client certificate along with a list of the CAs that it trusts. Because it is optional, existing authentication mechanisms will continue to work if no client certificate is presented. If a valid client certificate is presented and verified, the ADC will then encode the client certificate into the request metadata that is relayed to the application servers, which in turn consume the client certificate and perform further validation, authentication, and authorization. To ensure that the certificate being received has been properly validated by the ADC and not tampered with, mTLS must be implemented from ADC-to-APP. If the application receives client certificate metadata over a non-mTLS authenticated connection, it will not honor the certificate.