Certificate Pinning

Last updated
Save as PDF

For supported software information, click here.

Certificate pinning enhances the security of SSL and Transport Layer Security (TLS) connections in desktop and mobile applications. The primary purpose of SSL/TLS is to establish a secure and encrypted communication channel between a client, such as a desktop or a mobile app, and a server.

In a typical SSL/TLS connection, the server presents a digital certificate to prove its identity to the client. The client, in turn, verifies the authenticity of the certificate by checking its signature against a trusted certificate authority (CA). If the verification is successful, the client proceeds with the secure communication.

Certificate pinning takes this process a step further by directly associating the digital certificate or public key for a specific server with the client application. Instead of relying solely on the default trust provided by a CA, the client "pins" the certificate or public key for the server it intends to communicate with. This helps prevent man-in-the-middle attacks where an attacker could present a different, malicious certificate that the client might mistakenly trust.

Interference with TLS Decryption and Inspection

Certificate pinning can interfere with TLS decryption and inspection because it restricts which certificates are considered valid for a particular application or website. Since the application expects a specific certificate, it rejects any certificate that does not match the pinned one. When the Versa SSE platform presents its own certificate, the application detects the mismatch and terminates the connection, resulting in a failed validation.

TLS decryption is essential for many security services, such as intrusion prevention system (IPS), advanced threat protection (ATP), cloud access security broker (CASB), data loss prevention (DLP), and remote browser isolation (RBI), to gain visibility into encrypted traffic. TLS decryption allows these security services to inspect and control data exchanges with cloud applications, ensuring compliance, preventing data leaks, and safeguarding against malware. Without TLS decryption, these security services would not be able to detect potential threats or data exfiltration effectively.

Versa SSE provides layered threat defense, which includes security services that do not require TLS decryption and inspection, such as URL, IP and DNS filtering. These services offer an additional layer of protection to others that rely on TLS decryption, as shown below.

Certificate Pinning Security Solutions

You can use the following solutions to mitigate the impacts of certificate pinning on other security services.

Implicit Certificate-Pinned URL Bypass

Versa Networks offers a predefined list of applications that are excluded from TLS decryption. The URLs on the exclusion list are implicitly bypassed for TLS decryption and inspection due to certificate pinning. These URLs are continuously updated through the security package updates. No specific configuration is needed.

By bypassing these URLs, the applications remain functional. Although TLS decryption is not performed, other security policies, such as URL filtering, DNS filtering, and IP filtering are still applied to the traffic.

For more information, and to view the list of URLs, see Certificate Pinning and SSL Decryption Exclusions.

Dynamic Certificate-Pinned Traffic Bypass

SaaS applications such as Microsoft 365, Salesforce and Google Workspace share many common URLs. These URLs are too broad to bypass implicitly, and doing so could create security lapses. Examples include:

Authentication services—accounts.google.com, login.salesforce.com
API and CDN services—googleapis.com, officecdn.microsoft.com
Other common services—graph.microsoft.com

To overcome this, there is an option to bypass certificate-pinned traffic when you configure a TLS decryption policy. The option is available in the Decryption Enforcement screen, shown below (Bypass Certificate-Pinned Traffic). When this option is enabled, Versa dynamically detects traffic that matches the specified criteria and determines if it is certificate-pinned. This option is enabled by default in Concerto Releases 12.2.1 and later. Note that this bypass is done on a per-user basis and is temporary, to minimize the chance of exploitation.

Match Criteria in TLS Decryption Policies

Administrators can create a TLS decryption rule specifying the following match criteria:

Application
Endpoint posture
URL category
URL reputation

For a given set of CASB applications and activities specified in a CASB profile, an administrator must create the corresponding TLS decryption rules, as shown in the following examples:

The screenshot below shows the CASB profile rules:
The screenshot below shows the corresponding TLS decryption rules:

Note that the match criteria in the CASB profile and the match criteria in the TLS decryption policy should match.
You can use an endpoint profile in the TLS decryption rule to match specific operating systems. The screenshot below shows a TLS decryption rule to bypass traffic for certificate-pinned applications when it is initiated from Android or IOS endpoints.

For more information, see Associate an EIP Profile with a TLS Decryption Rule.

Solutions for Microsoft Office 365 Applications

You can use one of the following solutions for Microsoft Office 365 applications:

Default TLS inspection with Versa content inspection - This is recommended by Versa Networks.
Limited TLS inspection and content security inspection - This is recommended by Microsoft, but Versa Networks does not recommend this option because it breaks Versa CASB, DLP, ATP, and other security services that use TLS inspection.

Option 1: Default TLS inspection with Versa content inspection

This is recommended by Versa Networks, because Microsoft's recommended solution breaks CASB, DLP, ATP, and other Versa Networks security services that use TLS inspection. If you require CASB for M365 applications, use the Office365-Apps application group in a CASB policy:

Then, add Office365-Apps in the TLS decryption policies. You can add this to a policy in the same way that you would add applications such as Twitch, YouTube, or Dropbox. For examples of a CASB policy and corresponding TLS decryption policy, see Match Criteria in TLS Decryption Policies, above.

Option 2: Limited TLS inspection and content security inspection

According to Microsoft's Connectivity principles, M365 applications that are categorized as Optimize should not be TLS-inspected. Those that are categorized as Allow and Default can be inspected. If you want to implement this recommendation, use the applications and URL definitions provided below:

Microsoft Connectivity Principles at https://learn.microsoft.com/en-us/mi...ity-principles.
Managing Office 365 Endpoints at https://learn.microsoft.com/en-us/mi...-365-endpoints.
Dynamically-updated list of Microsoft 365 URLs at https://learn.microsoft.com/en-us/mi...address-ranges.

You can create the following M365 rules. These are not enabled by default.

Mitigate the Limitations of Inline CASB with API-Based Data Protection

API-based data protection mitigates the limitations of inline CASB because it can inspect certificate-pinned SaaS applications closer to the application. This must be authorized for each SaaS application.

The table below shows a comparison of the two solutions, and when each solution should be used. For further information on configuration and use, see Configure CASB Profiles and Configure Offline CASB Profiles.

Inline CASB	API-Based Data Protection (CASB)
~80 SaaS applications, with more applications and activities continuously added through security package updates.	30+ SaaS/IaaS application connectors, with more applications and activities developed as feature additions.
Complements API-based data protection.	Complements inline CASB.
Deployed through the Versa Operating System^TM (VOS^TM) software.	Deployed offline, closer to the SaaS application.
Granular actions, such as login, upload, download, video, and chat.	Very granular app-specific actions, such as file download in a Slack channel, and actions based on a sender/receiver list or groups in Gmail, Outlook.
No additional authorization needed because this is a proxy.	Needs explicit authorization by an application administrator.
Operates at the network layer using a reverse proxy mechanism.	Operates at the application layer—Uses webhooks, application connectors, and works directly as an authorized connector of the SaaS/IaaS application.
Risk classification on a scale of 1–5, from extremely low to extremely high risk.	Risk classification does not apply.
Use where it is possible to decrypt TLS.	Use when the SaaS/IaaS application is certificate-pinned.
Works through the Versa Cloud Gateway (VCG) or an appliance running the VOS software, typically through a corporate network.	Works for users who bring their own device (BYOD) and connect from outside the corporate network.

Best Practices for Certificate Pinning

We recommend the following best practices for certificate pinning implementations:

Understand which security services require TLS decryption, and configure the corresponding TLS decrypt and inspect policies for the same match criteria.
Use a combination of match criteria—users & groups, applications & URLs, endpoint posture including OS platforms, network layer criteria—to specifically define which traffic needs to be decrypted and inspected.
Keep the Microsoft Office365 built-in recommendations as they are.
Understand implicit and dynamic TLS bypasses due to certificate pinning.
Use API-based data protection for supported SaaS applications to overcome certificate pinning issues.

Supported Software Information

Releases 12.2.1 and later support all content described in this article.

Additional Information

Configure SASE TLS Decryption
Configure Offline CASB Profiles