MID Server certificate check policies
Summarize
Summary of MID Server certificate check policies
MID Server enhances security for all HTTPS traffic it initiates by performing three key certificate checks: TLS/SSL certificate validation, hostname validation, and OCSP (Online Certificate Status Protocol) validation. These checks ensure encrypted communication with trusted servers and prevent man-in-the-middle attacks. The MID Server certificate check policies table allows administrators to configure and control these security checks across different endpoint categories.
Show less
Key Features
- TLS/SSL Certificate Validation: MID Server verifies the authenticity of the web server's TLS/SSL certificate using asymmetric encryption before establishing an encrypted session.
- Hostname Validation: This confirms that the DNS name on the certificate matches the requested URL to ensure the MID Server communicates with the intended server. It requires TLS/SSL validation to succeed first.
- OCSP Validation: MID Server queries the certificate authority's OCSP responder to confirm that a certificate is valid and not revoked, enhancing protection against compromised certificates.
- Security Policy Categories: MID Server applies certificate checks based on four policies:
- ServiceNow Endpoint Policy: Default for ServiceNow URLs, controlled by bootstrap properties initially and later synchronized with the instance policy.
- Internet Policy: Covers HTTPS connections to external internet endpoints.
- Intranet Policy: Applies to internal network IP ranges, disabled by default on upgrades but recommended to enable for stronger internal security.
- Overridden Policy: Takes precedence for specific endpoints or URLs to customize certificate checks.
- Configuration and Management: Policies are editable to include/exclude IP ranges and define which certificate checks to enforce. The mid.ssl.use.instance.security.policy parameter controls whether the MID Server uses instance-defined policies or local bootstrap settings.
- Handling Self-Signed Certificates: Internal endpoints with self-signed certificates require importing certificates into the MID Server’s trust store or disabling relevant policy checks to maintain connectivity.
- Bootstrap Parameters: Initial default settings provide a balance between security and operational flexibility, especially during setup, with parameters controlling hostname, chain, and revocation checks.
- Upgrade Considerations: After upgrading to the Quebec release, customers should review and adjust policy settings to align with their security requirements.
Practical Implications for ServiceNow Customers
- Enforcing all certificate validation checks maximizes security for MID Server communications.
- Configuring intranet policies strengthens internal network security, but requires valid CA-signed certificates or trust store updates for self-signed certificates.
- Using the instance security policy (by setting mid.ssl.use.instance.security.policy to true) enables centralized control of MID Server certificate policies, which can streamline policy enforcement across multiple MID Servers.
- Disabling or adjusting policies may be necessary in environments where OCSP responders are unreachable or during initial MID Server setup to prevent connection disruptions.
- Administrators should regularly update and manage certificates and trust stores to avoid connection failures and maintain secure communications.
MID Server uses three kinds of security checks to secure external traffic. The security checks use TLS/SSL certificate validation, hostname validation, and OCSP validation to improve security. Control these security checks with the MID Server certificate check policies table.
TLS/SSL certificate validation
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.
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
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.
Online Certificate Status Protocol (OCSP)
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.
MID Server security policy
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 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.
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
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.
<parameter name="mid.ssl.bootstrap.default.check_cert_hostname" value="true"/><parameter name="mid.ssl.bootstrap.default.check_cert_chain" value="true"/><parameter name="mid.ssl.bootstrap.default.check_cert_revocation" value="false"/><parameter name="mid.ssl.use.instance.security.policy" value="false"/>
Self-hosted or on-prem instances must add the following parameter for the
config.xml: <parameter
name="mid.ssl.bootstrap.default.target_endpoint"
value="FQDN_OF_THE_INSTANCE"/>