Introduction to Certificate Pinning in AirWatch

What is Certificate Pinning?

The term "certificate pinning" refers to the process of pinning - that is, pre-sharing - the public Secure Sockets Layer (SSL) key of the endpoint server into the application initiating the connection. This ensures that the application will communicate only with explicitly trusted servers with the purpose of preventing Man-in-the-Middle (MITM) attacks. The application could be an Internet browser, commercially available application, video game, or mobile application.

Without certificate pinning, if an attacker gains access to a device or system, it is possible for an attack to create their own SSL certificates signed by an internal Certificate Authority and use it to establish a trusted connection between the device and the certificate they generated.  A similar scenario exists if an attacker successfully compromises one of the global certificate authorities.  Such attacks are not possible with certificate pinning successfully implemented.

More information about certificate pinning, and how certificate pinning is supported by AirWatch, is available in the VMware AirWatch TLS Public Key Pinning White Paper.

 

Certificate Pinning Within AirWatch

Certificate pinning was first implemented in AirWatch in versions 9.0, 8.4.5, and 8.3.10.  This is currently implemented as a “soft fail” methodology, which means that, should the certificate pinning verification fail, the connection will not be terminated.  In these events, the verification failure will be logged in the system but the connection will still be established.  This approach will allow the AirWatch team to validate the pinning implementation over a period of time to ensure stability within environments.

In the future, the product will shift to a “hard fail” methodology, which means that in the event of a certificate pinning verification fail, the connection will be terminated.  This article will be updated as this timeline is confirmed, so subscribe to this article to stay up-to-date on the certificate pinning implementation in AirWatch.

Certificate pinning within AirWatch has been implemented for Transport Layer Security (TLS) communications between enrolled devices and AirWatch services as well as other sites and services for which the organization controls the TLS certificates in use.  There are two distinct types of pins configurable in the AirWatch Console: Device Services pins and Auxiliary Pins. Both are configured via the SSL Pinning page within the AirWatch Console: System > Security > SSL Pinning.

The Device Services certificate contains the primary pinned public key, and is mandatory once SSL Pinning has been enabled. When the SSL Pinning option is enabled a certificate for Device Services must be uploaded via the SSL Pinning Page. This setting cannot be overridden by child group administrators.

It is also possible to pin certificates for any server utilized by AirWatch applications. For example, AirWatch Cloud Connector, Secure Email Gateway, Email Notification Service, AirWatch Tunnel Gateway and other services may all be pinned. In fact, functionality is not limited to AirWatch-exclusive services, but any TLS-enabled service for which the administrator uploads the correct certificate can be pinned. These certificates are not distributed via AirWatch’s Cloud Trust Service, but instead through the Device Services server.

NOTE: AirWatch recommends against pinning sites for which your organization does not control the TLS server certificates. Since certificates may expire or be replaced at any time, and because administrators will not have access to pin the upcoming certificate, this could break pinning functionality and prevent users from connecting to these resources.

SSL Pinning in AirWatch will function through the use of the Trust Service.  All customers will be able to access a Trust Service server hosted by AirWatch in the cloud.  However, closed on-premise environments that do not have access to the AirWatch cloud must have a Trust Service installed locally, typically on the Device Services server but potentially as a separate server.  The on-premise Trust Service essentially replaces the process flows performed by the Cloud Trust Service when SSL Pinning is enabled in AirWatch.  If the Trust Service is not enabled on a closed-environment that is utilizing SSL Pinning, then device enrollment will not be possible.

 

Errors & Notifications

In a future release, the AirWatch console will implement notifications for admins that contain information about errors pertaining certificate pinning connectivity issues. The 2 main types of notifications will be:

  • Static notification: This notification will contain static text explaining what actions or checks customers must carry out to ensure uninterrupted connectivity for their devices. One action item will be to check outbound proxy settings and add an exception for auto discovery URL, and other will be to install an On-Premise Trust Service for a closed network deployment.
  • Device Event based Triggered notification – This notification will be displayed if there are any errors pertaining to device connectivity when using a pinned connection.

 

More information about configuring certificate pinning can be found in the How to Configure SSL Pinning in AirWatch guide.

Have more questions? Submit a request

0 Comments

Article is closed for comments.