Kurzversion: Weiß jemand, ob X.509-Client-Zertifikate auf dem iPad für IMAP-Mail funktionieren sollen ? Verschwende ich meine Zeit damit, eine Funktion zu finden, 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 höher ist von Interesse. 5.1 ist die Version, mit der ich getestet habe.
Ich bin der Administrator eines Netzwerks, das laut Richtlinie zur Verwendung von X.509-Clientzertifikaten zum Schutz der gesamten externen Kommunikation erforderlich ist, einschließlich unseres IMAP-Mailservers (Cyrus IMAPd) und SMTP-Servers (Postfix). Keiner von beiden akzeptiert eine Verbindung, ohne dass der Client ein gültiges X.509-Clientzertifikat vorlegt. Das Deaktivieren der Clientzertifikatsanforderung ist für mich keine Option, und aus ähnlichen Gründen ist es uns nicht gestattet, Datenverkehr über VPN zu tunneln.
Wir haben jetzt iPad-Benutzer, die eine Verbindung zu unserem Netzwerk herstellen möchten, und stellen fest, dass das iPad ein Problem darstellt.
Für Benutzer auf Desktop-Computern installieren wir normalerweise Thunderbird, da es über eine solide IMAP mit hervorragender 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 integrierte Mail-App des iPad nicht mit Client-Zertifikaten für IMAP fertig zu werden. Ich kann das Stammzertifikat unserer Organisation und das Clientzertifikat 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 überprüft wurde.
Mail kann immer noch kein Client-Zertifikat senden, wenn eines angefordert wird, sodass der Server den Handshake beendet. Der Benutzer wird weder aufgefordert, eines auszuwählen, noch wird automatisch das von ihm installierte Client-Zertifikat für den Benutzer gesendet, 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 Clientzertifikaten antwortet, wenn Clientzertifikate vom Server angefordert werden. Siehe unten.
Wenn das Gerät über verschlüsseltes WLAN mit dem internen Netzwerk verbunden ist und kein Client-Zertifikat erforderlich ist, um E-Mails abzurufen, stellt das Gerät eine Verbindung her und lädt E-Mails einwandfrei herunter. Der externe Zugriff (öffentliches WLAN oder über 3G) schlägt fehl, unabhängig davon, 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 Clientzertifikaten für IMAP ist es perfekt.
Verweise auf die Unterstützung von Clientzertifikaten in der Dokumentation zur "Enterprise-Unterstützung" von Apple werden nur dort angezeigt, wo Microsoft Exchange ActiveSync und die Unterstützung von Cisco VPN erläutert werden.
In den Diskussionsforen von Apple gibt es einige Fragen, aber keine aktuellen und keine nützlichen Antworten. Ich würde auf sie verlinken, aber Apples Foren sind derzeit "wegen Wartungsarbeiten nicht verfügbar".
Als Problemumgehung kann ich wahrscheinlich ein gesperrtes VPN mithilfe der automatischen VPN-Verbindungsunterstützung des iPad einrichten, um mit einem von einem Client zertifizierten IPSec-VPN zu kommunizieren, das nur mit den IMAP- und SMTP-Servern an den entsprechenden Ports plus DNS kommunizieren kann , sonst nichts. Es wäre allerdings ein ziemlich grausamer Hack, ihn verüben zu müssen.
Übrigens lautet die Client <-> Server-Konversation:
- C -> S TLSv1-Client Hallo
- S -> C TLSv1 Server Hallo
- S -> C TLSv1-Zertifikat, Zertifikatanforderung, Server Hello Done (Sendet Serverzertifikat, signierendes Stammzertifikat, DN des akzeptierten Clientzertifikatsignierers, der zufällig mit dem Stamm identisch ist, der das Serverzertifikat signiert hat)
- C -> S TLSv1-Zertifikat (leerer Satz von Zertifikaten, keine Zertifikate enthalten)
- S -> C TLSv1-Handshake-Fehler
Mit anderen Worten, der Server sagt "das bin ich, ich erwarte, dass Sie ein von der Behörde unterschriebenes Zertifikat vorlegen, um zu beweisen, wer Sie sind", und der Kunde antwortet mit "Ähm, meine Papiere befinden sich hier in diesem leeren Umschlag. Schauen Sie, ein Kasuar! ""
Auf dem Client ist das Stammzertifikat installiert, und auf dem Client ist ein Clientzertifikat installiert, dessen Unterzeichner-DN vom Server angefordert wird.