Exchange und Android: ActiveSync via WAP funktioniert nicht

Wenn man ActiveSync über den Windows WAP (Web Application Proxy) veröffentlichen möchte, sollte man beachten, dass der WAP SNI verwendet. Bei einem unserer Kunden fiel uns dann auf, dass einige Android Versionen diese Erweiterung des TLS SSL Protokolls (SNI) nicht unterstützen.

ActiveSync Mails: iPhones ja, Android Geräte nein

Wir standen also vor dem spannenden Problem, dass iPhones über ActiveSync E-Mails erhalten konnten – bei Android Geräten funktionierte ActiveSync via WAP hingegen nicht. Daraufhin gingen wir auf Spurensuche, woran dies denn liegen könnte. Nach unzähligen Support Calls und ein wenig Glück entdeckten wir die SNI Thematik. Diese wiederum führte uns dann zur Lösung unseres Problems.

Was ist SNI?

SNI steht für „Server Name Indication“ und ist eine Erweiterung des TLS SSL Protokolls. Dieses Protokoll kommt zum Einsatz, wenn hinter einer IP mehrere Hostnamen zu finden sind. Hierbei sendet der Client ein „ClientHello“ Paket. In diesem Paket ist unter dem Feld „ClientHelloExtension“ der entsprechende Servername enthalten. Dieser taucht dann erst wieder auf, sobald der verschlüsselte Tunnel aufgebaut wurde.  

Genau hier setzte auch unser Problem an, da die Android Devices unseres Kunden nicht SNI sprechen konnten.

Lösung: http.sys Fallback Zertifikat

Um die Einschränkung aufzuheben, mussten wir ein http.sys Fallback Zertifikat erstellen. Auf diese Weise kann die Konnektivität der Geräte wiederhergestellt werden. Also erstellten wir ein http.sys Zertifikat mit einem Binding für 0.0.0.0:443 mittels folgendem Befehl

Der appid Parameter ist die GUID der Anwendung, die man an das Binding anlegen möchte. In unserem Fall wäre es WAP.

 Für ADFS und Web Application Proxy existieren folgende fest definierte IDs:

Certhash

Den certhash vom WAP kann über folgenden PowerShell Befehl erhalten. Bitte beachten Sie, dass dieser Befehl nur auf einem Server ausgeführt werden kann, der die Remote Access Command Tools installiert hat.

Die Ausgabe sieht dann in etwa so aus:

Installierte Zertifikate prüfen

Mit folgenden Befehl können Sie in der PowerShell die bereits auf dem Server installierten Zertifikate sehen und überprüfen.

Vollständiger Befehl

So könnte dann z. B. der vollständige Befehl aussehen:

Für einen tieferen Einblick hat Ian Parramore noch einen sehr guten Artikel geschrieben. Diesen finden Sie hier:
http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx