Configure Secure TLS Communication Between SCP and Cloud Proxy
You can enable server certificate validation at the Client Proxy for the TLS layer. This setup introduces two levels of authentication.
Layer Authentication (TLS connection between Client Proxy and Proxy)
The TLS termination at the Point of Presence (PoP)—using HAProxy or SWG—can be configured in two ways:
Common Server Certificate
Configure a shared server certificate for all tenants, for example, secure-mcp.example.cf.com. Skyhigh servers use predefined certificates that are trusted by major Certificate Authorities (CAs). This configuration simplifies setup and removes the need for tenant-specific certificate management. If any changes are required to certificate attributes, update them in the Unified Cloud Edge (UCE) portal.
Tenant Specific Server certificate
Configure your own certificate and private key signed by a trusted CA—for example, c123456.secure-mcp.example.cf.com.
This option gives you complete control over certificate and key management for the TLS layer. The TLS termination identifies your tenant through the Server Name Indication (SNI) extension sent by the Client Proxy.
This setup requires additional UI and back-end logic to replicate certificate access for TLS termination across all PoP clusters. If you prefer to manage your own certificates, submit the configuration as a Feature Modification Request (FMR).
Client Proxy - Server Certificate Verification and Actions
The Client Proxy validates the server certificate it receives during the TLS handshake.
To maintain compatibility with SSL inspection devices and captive portal environments, the Client Proxy supports the following validation methods:
Validation Trust Chain (Skyhigh-issued certificates)
The Client Proxy verifies the certificate using Skyhigh ’s predefined trust chain. This option provides strong data security but may cause interoperability issues in complex network environments.
Validation Against Trusted CA List
The Client Proxy validates certificates against trusted CAs in the device’s trust store, which includes common root CAs. You can use either public or private CA-signed certificates to manage traffic between devices and enterprise-managed trust stores. This approach provides a balanced and interoperable trust model that works reliably in most environments.
NOTE: Admins must ensure that the latest Sectigo root CAs are installed for the Secure Channel to function correctly.
Handling Validation Failures
When certificate validation fails, it may indicate that an intermediate proxy is intercepting the traffic. You can configure how the Client Proxy responds:
- Allow – Establish a secure channel and continue traffic.
- Block – Prevent the secure channel from being created until the user connects.
Configure these options in the Client Proxy Management UI to define how the system responds to certificate validation failures.
