---
sourceDocument: Brazil Platform security
sourceDocumentLink: https://www.servicenow.com/docs/r/platform-security

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Platform security

ft:clusterId :

    - psec

bundleId :

    - psec

workflow :

    - Platform


---

# Outbound certificate policies

# Outbound certificate policies {#ariaid-title1}

Release version: Brazil  
Updated October 19, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Outbound certificate policies

Outbound certificate policies in ServiceNow allow you to control how the instance validates SSL/TLS certificates for specific domains (FQDNs) on outbound connections.
Instead of applying global validation settings to all hosts, you can tailor certificate validation for individual domains.
This enables you to bypass or enforce particular validation checks for domains with known certificate issues, while maintaining strict validation for others.
Show full answer Show less  
These policies are opt-in and inactive by default, requiring the **com.glide.communications.httpclient.outboundcertpolicy.enabled** property to be set to true and the **outboundhttprequestadmin** role to manage them.

## Key Features

* **Domain-specific validation:** Control three certificate validation checks per domain:
  * Hostname verification
  * Certificate chain validation
  * Revocation checking (OCSP/CRL)
  All checks are enabled by default, ensuring secure policies unless explicitly relaxed.
* **Policy matching:** Uses a prioritized three-tier lookup when making outbound connections:
  * Exact domain match has highest priority (e.g., www.api.partner.com)
  * Wildcard domain match applies if no exact match (e.g., .partner.com)
  * Global fallback to instance global validation if no policy matches
* **Scope and uniqueness:** Only one active outbound certificate policy is allowed per domain on the instance. If a policy exists, update it rather than creating duplicates.
* **Wildcard restrictions:** Wildcard patterns must be specific enough (e.g., .partner.com) and cannot be overly broad (e.g., or .com) to prevent weakening validation across many domains.
* **Integration impact:** A policy affects every outbound connection to the domain across REST messages, SOAP messages, Flow Designer steps, and synchronous/asynchronous HTTP client calls, except:
  * REST/SOAP calls with mutual TLS (mTLS)
  * Internal HTTP client calls
  * Calls via MID server

## Security Considerations

* Disabling validation checks reduces SSL/TLS protection; minimize risk by disabling only necessary checks.
* Prefer exact domain matches over wildcards to limit scope.
* Treat relaxed policies as temporary fixes while the domain's certificate issues are resolved.
* Restrict policy creation and modification to authorized roles only.

## Known Limitation

When using the UI, multiple policies for the same host can be created across different scopes, but only the first created policy is applied. To avoid confusion, update existing policies instead of creating new ones for the same domain.  
Outbound certificate policies let you control how the instance validates a specific domain's (FQDN)) SSL/TLS certificate on outbound connections. Use these policies instead of applying global validation settings to every
host.

By default, the instance validates a domain's SSL/TLS certificate the same way for every outbound connection, using global validation settings. An outbound certificate policy lets you change that behavior for a single domain. For
example, you can skip a specific validation check for a domain with a known certificate issue while every other domain keeps the global settings.

Each policy controls three validation checks for the domain it applies to:

* Hostname verification
* Certificate chain validation
* Revocation checking (OCSP/CRL)

{#outbound-certificate-policies__ul_mm2_tgx_fkc}  
Note:  
* All three are enabled by default, so a policy is secure by default.
* Outbound certificate policies are opt-in Feature and is inactive by default. The REST/SOAP calls with mTLS functionality aren't affected.
* Each endpoint/host can have only one active Outbound certificate policy on the instance. If a policy already exists for the host, update it as needed instead of creating a duplicate policy in a different scope.
{#outbound-certificate-policies__ul_igs_gk5_jkc}

Managing policies requires the `outbound_http_request_admin` role, and policies take effect only when the `com.glide.communications.httpclient.outbound_cert_policy.enabled` property is set to
<kbd class="ph userinput">true</kbd>.

## How a policy is matched to a domain {#outbound-certificate-policies__outbound-certificate-policies-matching}

When the instance makes an outbound connection, it resolves the certificate policy for the domain using a three-tier, fallback-aware lookup. Here are the matching scenarios:
{#outbound-certificate-policies__table_q3j_1hx_fkc__entry__2}

| Scenario | Behavior |
|-|-|
| Exact match | A policy whose pattern exactly matches the domain (for example, `www.api.partner.com`) takes priority. |
| Wildcard match | If no exact match exists, a wildcard policy (for example, `*.partner.com`) applies. Selects the most specific matching. |
| Global fallback | If no policy matches the domain, the instance uses the global validation settings. |
[Table 1. Policy match to a domain]

{#outbound-certificate-policies__table_q3j_1hx_fkc}

Because domains without a matching policy fall back to the global settings, existing connections are unaffected until you add a policy for a domain.

## Integrations affected by a policy {#outbound-certificate-policies__outbound-certificate-policies-coverage}

An outbound certificate policy changes certificate validation for every outbound connection the instance makes to the matching domain --- not only the integration you created the policy for. When a policy relaxes a check, all of the
following outbound connection types to that domain use the relaxed validation. When a policy enforces a check, they all enforce it:

* REST messages --- the policy applies to the outbound HTTP and HTTPS requests the message makes.
* SOAP messages --- the policy applies to the SOAP endpoint's certificate validation.
* REST and SOAP steps in Flow Designer.
* Synchronous and asynchronous HTTP client calls.

Note:  
* The REST/SOAP calls with mTLS aren't affected - Synchronous and asynchronous calls via internal HTTP client aren't affected.
* Any calls via mid server aren't affected.
{#outbound-certificate-policies__ul_uzk_3lc_lkc}

Before you create or change a policy, review the integrations that connect to the domain so that the change in validation behavior is expected across all of them.

## Wild card patterns {#outbound-certificate-policies__outbound-certificate-policies-wildcards}

A policy pattern can use a wildcard to apply to all sub-domains of a domain --- for example, `*.partner.com`. To prevent a single policy from weakening validation across too many domains, the instance rejects overly
broad wildcard patterns when you save a policy:

* A bare wildcard (`*`) and a top-level wildcard (`*.com`) are rejected.
* A wildcard pattern must contain at least two domain components --- for example, `*.partner.com`.

These constraints prevent an instance-wide validation bypass through a single overly broad pattern.

## Security considerations {#outbound-certificate-policies__outbound-certificate-policies-security}

Turning off a validation check for a domain reduces the protection that SSL/TLS validation provides for connections to that domain. Use outbound certificate policies deliberately:

* Turn off only the specific checks a domain requires, and leave the others enabled. A policy is secure by default --- every check starts enabled.
* Use the most specific pattern that solves the problem. Prefer an exact domain over a wildcard.
* Treat a relaxed check as a temporary measure while a domain's certificate issue is resolved, and review your policies regularly.
* Restrict who can create and change policies --- requires the `outbound_http_request_admin` or `admin` role.

## Known limitation {#outbound-certificate-policies__section_dcy_mk5_jkc}

When creating an Outbound certificate policy for a host in the UI, you can create multiple policies for the same host across different scopes. However, the system applies only the first policy created for that domain. To avoid
confusion, update the existing policy if changes are needed instead of creating a new one.