--- sourceDocument: Australia ServiceNow AI Platform Capabilities sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/de-DE/servicenow-platform Release : - australia ft:locale : - de-DE ft:publication_title : - Australia ServiceNow AI Platform Capabilities ft:clusterId : - platcap bundleId : - platcap workflow : - Platform --- # MID Server certificate check policies # MID Server certificate check policies {#ariaid-title1} * Freigeben Version: Australia * * Aktualisiert 12. März 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 6 Minuten Lesedauer 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-security-checks__table_m2t_cv4_nhb} ## TLS/SSL certificate validation {#mid-security-checks__section_w5g_d2n_mnb} TLS/SSL encryption security uses asymmetric encryption, also called public-key encryption. This encryption uses two cryptographic keys: the public key and the private key. The public key is used for encryption of data and is publicly visible. The private key is used for decryption of data and its security is essential to verifying authenticity. For more information about preparing your network, see [MID Server TLS/SSL certificate check policy Quebec upgrade information \[KB0867397\]](https://support.servicenow.com/kb_view.do?sysparm_article=KB0867397). In TLS/SSL certificate validation, the MID Server attempts to connect to a web server secured with a TLS or SSL certificate. The web server sends a copy of its TLS/SSL certificate to the MID Server. The MID Server checks the authenticity of the certificate and sends a message to the webserver. The webserver responds with a digitally signed acceptance for initiating an TLS/SSL encrypted session. After which the MID Server can begin encrypted communication with the web server. ## Hostname validation {#mid-security-checks__section_kdd_12n_mnb} Hostname verification is a part of HTTPS that involves a server identity check to ensure that the client is talking to the correct server. This check prevents sending information to a server after being redirected by a man in the middle attack. The check involves verifying that the `dnsName` of the certificate sent by the server matches the URL used to make the request. According to RFC 6125, hostname verification should be done against the certificate's subjectAlternativeName's dNSName field. In some legacy implementations, the check is done against the certificate's commonName field. If the names don't match, the connection is terminated. Hinweis: Hostname validation derives the hostname from the validated certificate presented by the server. Therefore, TLS certificate validation is a pre-requisite for hostname validation. ## Online Certificate Status Protocol (OCSP) {#mid-security-checks__section_zht_c2n_mnb} OCSP involves contacting the remote certificate authority server and verifying the certificate before the MID Server communicates further with the target server. Compromised certificates can be a security vulnerability, especially if those certificates have the ability to sign other certificates. If certificates have been broken or forged, then a certificate authority can inform a client which certificates are invalid and should not be used. An OCSP responder (a server typically run by the certificate issuer) returns a signed response that the certificate is 'good', 'revoked', or 'unknown'. If it cannot process the request, it may return an error code. The certificate's issuer may delegate another authority to be the OCSP responder. This creates a chain of certificates that must be verified. The responder's certificate must be issued by the issuer of the certificate in question. The responder's certificate must include a certain extension that marks it as an OCSP signing authority. Hinweis: OCSP checks are secondary HTTP calls made to an OCSP responder. The primary call may discontinue the connection based on the response from the OCSP responder. ## Certificate Revocation List (CRL) {#mid-security-checks__section_gjh_p3c_l3c} CRL checking provides an alternative to OCSP for verifying certificate revocation status. Rather than querying a live OCSP responder, the MID Server downloads and caches Certificate Revocation Lists (CRLs) from URLs provided by the Certificate Authority (CA). The MID Server then checks the revocation status of certificates against the locally cached CRL during the SSL/TLS handshake. If a certificate appears on the CRL, the MID Server rejects the connection and logs the event. CRLs are cached locally and updated periodically based on the CA's update schedule. If a CRL download fails, the system retries according to a configurable retry policy. Hinweis: As of May 7, 2025, Let's Encrypt no longer includes OCSP URLs in issued certificates and has deprecated its OCSP responders in favor of CRLs, following the CA/Browser Forum ballot SC-063, which made OCSP optional for Certificate Authorities and mandated CRL support. CRL checking ensures continued certificate revocation validation for certificates issued by CAs that no longer support OCSP. ## MID Server security policy {#mid-security-checks__section_q4l_qws_snb} MID Server security policies control all HTTPS traffic originating from the MID Server. This includes HTTPS connections from the MID Server to an internet endpoint, ServiceNow URLs, intranet endpoints, as well as cloud endpoints. These connections can be further classified into 4 security policies: ServiceNow endpoint policy : This policy is the system default exclusively for ServiceNow URLs. On the MID Server config.xml, there are bootstrap properties which are only used to make first connection to the instance and will get updated with the system_default policy. Internet policy : These policies cover all HTTPS connections initiated from MID Server to any endpoint on the internet. Intranet policy : These policies cover the reserved IP subnets, such as self-hosted networks. Overridden policy : You can override specific endpoints or URLs with this policy definition. Overridden policies take the highest order of precedence during operation. Both tables are editable to include or exclude IP ranges, as well as control what kind of certificate validation checks need to be done. Enable all certificate validation checks to maximize security. The Quebec version has all policies and checks turned on by default for fresh installations. For upgrading customers, the intranet policy has the certificate validation checks disabled by default. To improve security, configure and enable the policy for endpoints within the internal network. Hinweis: Internal endpoints or URLs need to possess a valid CA signed certificate for a successful connection. For endpoints that host a self-signed certificate, either import the certificate to the MID Server trust store or disable the policy checks which validate that host. For more information about adding certificates, see [Add SSL certificates for the MID Server](https://servicenow-prod.fluidtopics.net/Wze_LuvGY3XWJMv9a~ORjg#add-ssl-certificates "Configure the MID Server to connect to a source over SSL."). After upgrading to Quebec, go to the certificate check policies table and make changes to policy configuration if necessary. Once the MID Server starts up and connects to the instance, any subsequent HTTPS connection originating from the MID server will start applying these certificate checks at runtime. Insecure connections are broken with appropriate error messages. ## Use Instance Security Policy {#mid-security-checks__section_vgp_nps_dwb} The MID Server configuration parameter mid.ssl.use.instance.security.policy controls whether the MID Server uses its bootstrap parameters rather than the security policy from the instance. By default, mid.ssl.use.instance.security.policy is set to false in the config.xml so the bootstrap policies are not overwritten by the instance's. This default setting can prevent some problems during MID Server setup. For example if the host is unable to reach the OCSP responder, then a new MID Server installation is not disrupted by an instance's policy of requiring OCSP connection. The configuration parameter mid.ssl.use.instance.security.policy can be set for each MID Server. When set to true, the MID Server syncs all policies with the instance and the bootstrap configuration parameters are overwritten by the \*.servicenow.com policy on the instance mid_cert_check_policy table. The final policies update the policy map in the MID Server memory as well as the config.xml. The default parameters in the config.xml are: * `` * `` * `` * `` {#mid-security-checks__ul_wv5_1zx_2wb} Self-hosted or on-prem instances must add the following parameter for the config.xml: `` **Zugehörige Konzepte** * [MID Server authentication credentials and SOAP requests](https://servicenow-prod.fluidtopics.net/80f2cul5Bjz0opflAxzxPg#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://servicenow-prod.fluidtopics.net/zWbtuI59iqjA5LfLDw8VPA#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 command audit log](https://servicenow-prod.fluidtopics.net/hMnNVhNJPmpY4gLr76lWAg "The command audit log records the commands run by the MID Server for the Discovery application. Review the commands to check for anomalies or errors.") * [MID Server FIPS Enforced Mode](https://servicenow-prod.fluidtopics.net/dqBc9MICWmUraTd809_RJw#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://servicenow-prod.fluidtopics.net/aFXIuu3zlxcmFMjRZPM1Ug "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.") **Zugehörige Tasks** * [Encrypt or decrypt MID Server configuration file values](https://servicenow-prod.fluidtopics.net/iCgc9bn4JQYK9vgd1wAC6w "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.") * [Enable MID Server mutual authentication](https://servicenow-prod.fluidtopics.net/UdSuWRmz6ZGA~Y6dkWvyeQ "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.") * [MID Server Azure Key Vault integration](https://servicenow-prod.fluidtopics.net/q98R6SSVMU1wN5ZSqPpYrw#mid_azure_key_vault_integration "The MID Server integration with the Azure Key vault enables Orchestration, Discovery, and Service Mapping to run without storing any credentials on the instance.") * [Rekey a MID Server](https://servicenow-prod.fluidtopics.net/pL97YclPNbf5hsjR6JhaEA "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://servicenow-prod.fluidtopics.net/Wze_LuvGY3XWJMv9a~ORjg#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://servicenow-prod.fluidtopics.net/vu1Hjk_D3VmPooctXzxerQ#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.") **Zugehörige Verweise** * [MID Server configuration file security](https://servicenow-prod.fluidtopics.net/pExtHd2xoAcm8Vh~FXV9oQ "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://servicenow-prod.fluidtopics.net/6XDl6hCCpG2wR7zHUqkWng "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.")