Server Certificate Validation

Updated: July 8, 2026

Want to summarize with AI?

Learn when to validate server certificates for secure forward proxy traffic and where to configure validation actions for TLS-decrypted connections.

When the gateway acts as a forward proxy, server certificate validation is automatically included in traffic processing. A designated server certificate validation action is not required in order to process traffic but it can improve the general security. By default, server certificate validation is not enabled and traffic going to servers that may have an invalid server certificate passes. Enable a server certificate validation action to prioritize rules for traffic that should not be allowed, or for specific traffic that should be trusted even regardless of its server certificate validations state.

Note

This validation process is only applicable for forward proxy environments and when decryption is enabled.

We recommend that you enable server certificate validation actions primarily in the TLS decrpytion profile for general rule actions. You can modify FQDN service objects to enable validation actions if you need to override the TLS decryption selection. You can include and enable a server certificate validation in two methods:

Server Certificate Validation in the TLS Decryption Profile

When you select an action for server certificate validation within a TLS decryption profile, this action is used in all the rule sets that use this decryption profile. By default the validation action is configured to allow all traffic regardless of whether the server certificate is valid or not, and Multicloud Defense does not generate an alert within the HTTPs logs.

Note

If you enable the validation check to Log, locate the logs in Policies > Profiles > Decryption.

Use the following procedure to enable the server certificate validation in the TLS decrpytion profile:

Procedure

	1.	From the Multicloud Defense Controller, navigate to Policies > Profiles > Decryption.
	2.	Select the TLS decryption profile you want add the server certificate validation to. If you do not have a profile ready, create one here. See Decryption Profile for more information.
	3.	Edit the decryption profile.
	4.	Under the Profile Properties section, expand the Invalid Server Certificate Action drop-down.
	5.	Select one of the following options: Deny Log - This option automatically drops connections that do not provide a validated server certificate and logs the incident. Deny No Log - This option automatically drops connections that do not provide a validated server certificate and does not log the incident. Allow Log - This option allows connections that do not provide a validated server certificate to pass and logs the incident. Allow No Log - This option allows connections that do not provide a validated server certificate to pass and does not log the incident. This is the default action selection.
	6.	Click Save.

What to do next

Ensure the TLS decryption profile is correctly associated with a forward proxy service object. See Forward Proxy Service Object (Egress / East-West) for more information.

Once the TLS decrpytion profile is included in a service object, confirm that the rule order within the policy is ordered in a way that supports how you want traffic processed.

Server Certificate Validation in the FQDN Service Object

Invalid server certificate validation within the FQDN service object is optional. If specified it will override the behavior designated in the TLS decryption profile. If you do not specify a selection here, no additional action or override action is taken. You can use the invalid server certificate validation within the FQDN service object to block or allow traffic for a specific server that may otherwise be blocked or allowed by the TLS decryption profile.

Note that when you enable the validation check to Log, these logs are located in Investigate > Flow Analytics > HTTPS Logs.

Use the following procedure to include a server certificate validation action in a FQDN service object:

Procedure

	1.	From the Multicloud Defense Controller, navigate to Policies > Security Policies > FQDN.
	2.	Select the FQDN service object you want to modify.
	3.	Edit the selected FQDN service object.
	4.	In the list of FQDN service objects included in the ruleset, expand the Invalid Server Certificate Action drop-down menu and select one of the following options: Deny Log - Automatically drop connections that do not provide a validated server certificate and logs the incident. Deny No Log - Automatically drop connections that do not provide a validated server certificate and does not log the incident. Allow Log - Allow connections that do not provide a validated server certificate to pass and logs the incident. Allow No Log - Allow connections that do not provide a validated server certificate to pass and does not log the incident.
	5.	Click Save.

What to do next

Ensure the FQDN service object is correctly associated with a rule or rule set. See Rule Sets and Rule Set Groups for more information.

Once the FQDN service object is successfully assocaited with a rule or rule set in your policy, confirm that the rule order within the policy is ordered in a way that supports how you want traffic processed.

Certificate for Custom Root CA

The Custom Root Certificate Authorities (CAs) store is a repository or storage location used in computing environments, such as operating systems or network devices, to store custom root CA. This allows organizations to add their own root certificates or third-party root certificates that are not included by default in the standard CA store provided by operating systems or browsers.

When you have a decryption profile enabled in your tenant, the Multicloud Defense Controller automatically initiates the validation of certificates for a custom root CA. The decryption profile relyies on it to enable secure traffic inspection, necessitating careful management and trust establishment across the network.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.