TLS 1.2 protocol not enabled by default for AirWatch Windows Server applications

Background:

AirWatch services are typically configured to provide connectivity over SSL/TLS. In some cases – for example, when an AirWatch server component such as the Admin Console connects to a third-party cloud service provider – AirWatch also acts as an SSL/TLS client.

SSL/TLS clients and servers must support a matching set of protocols and cipher suites in order to establish secure communication. The SSL/TLS client sends the server a list of algorithms and cipher suites it will accept, and the server should attempt to find a matching set of parameters to use. In addition, the integrity qualities provided by the PKI chain of trust must be validated by the SSL/TLS client. 

AirWatch components using the .Net framework (e.g., Admin console, Device Services, ACC, SEG, etc.) are configured to negotiate the most secure SSL/TLS protocols and cipher suites by default; in this case, TLS 1.2 is the default protocol negotiated if the third-party service or component also supports negotiation at TLS 1.2.  If TLS 1.2 is not supported, the negotiation will typically fallback to use TLS 1.1 or TLS 1.0 instead.

Issue

In many versions of the Windows Server platform .Net will not recognize otherwise valid certificates whose chain of trust (e.g., a root CA certificate or signing certificate) uses an MD5 signing algorithm. In this case, no fallback to TLS 1.1 or 1.0 is attempted since both the client and server support the TLS 1.2 protocol; instead, the validation of the server certificate fails even though the .Net client has indicated it does not support MD5 signing algorithms in the initial exchange of parameters.  Essentially, in some cases AirWatch may be unable to connect to 3rd party services through TLS 1.2 even when the configuration is correct.  If you receive a connection error due to this issue you will see the error message:

          Could not create SSL/TLS secure channel.

This behavior is ultimately due to a violation on Windows Server of the TLS 1.2 negotiation parameters specified in one of the TLS extensions as defined by RFC5246.

Resolution:

Due to this behavior, support for TLS 1.2 in SaaS environments is not currently available.  However, the following option is available for On-Premise environments:

The default preferred protocols for AirWatch will be temporarily changed to TLS 1.0 and TLS 1.1, with an option to enable support for TLS 1.2 if compatibility with third-party services is not needed or if the certificate chains of any services can be confirmed as compatible. Once a fix from Microsoft is available, the default will be changed back to TLS 1.2 support, which will continue to fallback to TLS 1.1 or 1.0 if necessary.  

Note: By default most servers accepting SSL/TLS connections will accept TLS 1.1 or TLS 1.0 connections, so connection issues should be limited in scope.

These changes will be first implemented in the following versions:

  • 8.3
  • 8.2 FP04
  • 8.1 FP09

Note: Although TLS 1.2 is the preferred transport layer security protocol, there are no known practical attacks against the TLS 1.1 protocol. Additionally, customers have the option of re-enabling TLS 1.2 manually if there is no concern about functional impact. Instructions for manually enabling TLS 1.2 are below.

How to override:

The default TLS settings can be overridden for each AirWatch application and service by updating each configuration file to explicitly indicate the use of a particular setting.  These files will be either:

  • app.config - For non-web applications (SEG, ACC, etc.)
  • web.config – For web applications (Admin console, Device Services, etc.) 

In the configuration file, add a new entry to the <appSettings> section as follows:

 

For TLS 1.2 only:

<add key=”OutboundTlsProtocols” value=”Tls12” />

 

For TLS 1.0, 1.2:

<add key=”OutboundTlsProtocols” value=”Tls, Tls12” />

 

For TLS 1.0, 1.1, 1.2:

<add key=”OutboundTlsProtocols” value=”Tls, Tls11, Tls12” />

 

After the changes are made, any updated AirWatch services must be restarted.

Note: These changes must be made for the app.config/web.config file of all Windows-based components within AirWatch that require this network protocol.  For example, the following components all interact with the Content Gateway, and may require this update if the networking requirements specify it.

  • Console: ..\Canonical\Console\Web\src\WebSln\WanderingWiFi.AirWatch.Console.Web\web.config
  • Device Services: ..\Canonical\DeviceServices\Service\src\DeviceServicesSln\WanderingWiFi.AirWatch.DeviceServices\web.config
  • MCM API: ..\Canonical\AirWatch API\AW.Mcm.Api\AW.Mcm.Api\web.config
  • Self Service Portal: ..\Canonical\Console\Web\src\MobileSln\AW.Console.Web.Mobile.SelfServicePortal\web.config
  • AirWatch Scheduler Service: ..\Canonical\Services\AirWatch Scheduler\Service\src\ServiceSln\AW.Service.Scheduler.Service\app.config
  • Content Gateway: ..\Canonical\MobileAccessGateway\MobileAccessGateway\web.config

 

Have more questions? Submit a request

0 Comments

Article is closed for comments.