iPad Mail-Client - IMAP mit X.509-Client-Zertifikaten?

Kurzfassung: Weiß jemand, ob X.509-Client-Zertifikate auf dem iPad für IMAP-Mail funktionieren sollen ? Verschwende ich meine Zeit damit, eine Funktion zum Laufen zu bringen, die nicht funktioniert? Wenn die integrierte E-Mail-App IMAP mit X.509-Client-Zertifikaten nicht unterstützt (dh sie funktionieren nur mit Microsoft Exchange ActiveSync-Konten), gibt es Apps von Drittanbietern, die dies tun?

Nur iOS 5.1 oder neuer ist von Interesse; 5.1 ist die Version, mit der ich getestet habe.

Ich bin der Administrator eines Netzwerks, das per Richtlinie verpflichtet ist, X.509-Client-Zertifikate zu verwenden, um die gesamte externe Kommunikation zu schützen, einschließlich unseres IMAP-Mailservers (Cyrus IMAPd) und unseres SMTP-Servers (Postfix). Keiner akzeptiert eine Verbindung, ohne dass der Client ein gültiges X.509-Client-Zertifikat vorlegt. Das Deaktivieren der Client-Zertifikatsanforderung ist für mich keine Option, und wir dürfen aus ähnlichen Gründen keinen Datenverkehr über VPN tunneln.

Wir haben jetzt iPad-Benutzer, die sich mit unserem Netzwerk verbinden möchten und feststellen, dass das iPad ein kleines Problem darstellt.

Für Benutzer auf Desktop-Rechnern installieren wir normalerweise Thunderbird, da es über ein grundsolides IMAP mit ausgezeichneter Unterstützung für Client-Zertifikate verfügt; es "funktioniert einfach" und ist auf jeder Plattform gleich zu unterstützen. Dies ist keine Option für das iPad.

Leider scheint die eingebaute Mail-App des iPads nicht mit Client-Zertifikaten für IMAP zurechtzukommen. Ich kann das Root-Zertifikat unserer Organisation und das Client-Zertifikat des Benutzers mithilfe des iPhone-Konfigurationsdienstprogramms installieren. Beide werden unter Einstellungen->Allgemein->Profile als "verifiziert" angezeigt. Das iPad akzeptiert dann unseren Server als vertrauenswürdig und lässt alle Warnungen aus, dass die Identität des Servers nicht verifiziert wird.

Mail kann immer noch kein Client-Zertifikat senden, wenn eines angefordert wird, sodass der Server den Handshake beendet. Es fordert den Benutzer weder auf, eines auszuwählen, noch sendet es automatisch das Client-Zertifikat, das es für den Benutzer installiert hat und das mit dem vom Server vorgelegten CA-Zertifikat übereinstimmt.

Die Untersuchung des Verkehrsflusses zwischen Client und Server zeigt, dass die TLS-Aushandlung fehlschlägt, wenn das iPad mit einem leeren Satz von Client-Zertifikaten antwortet, wenn Client-Zertifikate vom Server angefordert werden. Siehe unten.

Wenn es über verschlüsseltes WLAN mit dem internen Netzwerk verbunden ist, wo kein Client-Zertifikat zum Abrufen von E-Mails erforderlich ist, stellt das Gerät eine Verbindung her und lädt E-Mails problemlos herunter. Der externe Zugriff (öffentliches WLAN oder über 3G) schlägt fehl, egal ob ich den IMAPs-Port 993 mit aktiviertem "SSL verwenden" oder den IMAP+TLS-Port 143 mit oder ohne aktiviertem "SSL verwenden" verwende. Abgesehen von dem offensichtlichen Mangel an Unterstützung für die Aushandlung von Client-Zertifikaten für IMAP ist es perfekt.

Verweise auf die Unterstützung von Client-Zertifikaten in der Dokumentation für Apples „Enterprise Support“ erscheinen nur dort, wo Microsoft Exchange ActiveSync besprochen wird, und wo Cisco VPN-Unterstützung besprochen wird.

Es gibt ein paar Fragen in den Diskussionsforen von Apple, aber keine aktuellen und keine nützlichen Antworten. Ich würde auf sie verlinken, aber die Foren von Apple sind im Moment "wegen Wartungsarbeiten nicht verfügbar".

Als Problemumgehung kann ich wahrscheinlich ein gesperrtes VPN einrichten, indem ich die automatische VPN-Verbindungsunterstützung des iPad verwende, um mit einem vom Client zertifizierten authentifizierten IPSec-VPN zu sprechen, das nur mit den IMAP- und SMTP-Servern an den entsprechenden Ports plus DNS kommunizieren kann, sonst nichts. Es wäre jedoch ein ziemlich grausamer Hack, ihn ausführen zu müssen.

Übrigens, die Client <-> Server-Konversation lautet:

• C -> S TLSv1-Client Hallo
• S -> C TLSv1-Server Hallo
• S -> C TLSv1-Zertifikat, Zertifikatanforderung, Server-Hello-Done (Sendet ein Serverzertifikat, signiert das Stammzertifikat, den DN des akzeptierten Unterzeichners des Client-Zertifikats, der zufällig mit dem Stamm identisch ist, der das Serverzertifikat signiert hat)
• C -> S TLSv1-Zertifikat (leerer Satz von Zertifikaten, null Zertifikate enthalten)
• S -> C TLSv1-Handshake-Fehler

Mit anderen Worten, der Server sagt: „Das bin ich, ich erwarte von Ihnen, dass Sie ein von einer Behörde unterschriebenes Zertifikat vorlegen, um zu beweisen, wer Sie sind“ und der Client antwortet mit „Ähm, meine Papiere sind in diesem leeren Umschlag hier. Schau, ein Kasuar! "

Auf dem Client ist das Root-Zertifikat installiert und es ist ein Client-Zertifikat installiert, das den vom Server angeforderten Unterzeichner-DN enthält.