Version courte: quelqu'un sait-il si les certificats clients X.509 sont censés fonctionner sur l'iPad pour le courrier IMAP? Suis-je en train de perdre mon temps à essayer d'obtenir une fonctionnalité qui ne fonctionne pas? Si l'application de messagerie intégrée ne prend pas en charge IMAP avec les certificats client X.509 (c'est-à-dire: ils ne fonctionnent qu'avec les comptes Microsoft Exchange ActiveSync), existe-t-il des applications tierces qui le font?
Seul iOS 5.1 ou plus récent est intéressant; 5.1 est la version avec laquelle j'ai testé.
Je suis l'administrateur d'un réseau qui est requis par la politique d'utiliser des certificats clients X.509 pour protéger toutes les communications externes, y compris notre serveur de messagerie IMAP (Cyrus IMAPd) et notre serveur SMTP (postfix). Aucun n'acceptera de connexion sans que le client présente un certificat client X.509 valide. La désactivation de l'exigence de certificat client n'est pas une option pour moi, et nous ne sommes pas autorisés à tunneliser le trafic via VPN pour des raisons similaires.
Nous avons maintenant des utilisateurs d'iPad qui souhaitent se connecter à notre réseau et constatons que l'iPad pose un petit problème.
Pour les utilisateurs sur des ordinateurs de bureau, nous installons généralement Thunderbird, car il possède un IMAP solide comme le roc avec un excellent support de certificat client; il "fonctionne juste" et est le même que celui de chaque plate-forme. Ce n'est pas une option pour iPad.
Malheureusement, l'application Mail intégrée de l'iPad ne semble pas faire face aux certificats clients pour IMAP. Je peux installer le certificat racine de notre organisation et le certificat client de l'utilisateur à l'aide de l'utilitaire de configuration iPhone. Les deux sont affichés comme "vérifiés" dans Paramètres-> Général-> Profils. L'iPad accepte alors notre serveur comme étant de confiance et omet tout avertissement indiquant que l'identité du serveur n'est pas vérifiée.
Mail ne parvient toujours pas à envoyer un certificat client lorsque celui-ci est demandé, le serveur met fin à la négociation. Il n'invite pas l'utilisateur à en sélectionner un et n'envoie pas automatiquement le certificat client qu'il a installé pour l'utilisateur qui correspond au certificat CA présenté par le serveur.
L'examen du flux de trafic entre le client et le serveur montre que la négociation TLS échoue lorsque l'iPad répond avec un ensemble vide de certificats client lorsque des certificats client sont demandés par le serveur. Voir ci-dessous.
Lorsqu'il est connecté au réseau interne via WiFi crypté, où aucun certificat client n'est requis pour recevoir du courrier, l'appareil se connecte et télécharge très bien le courrier. L'accès externe (WiFi public ou 3G) échoue, que j'utilise le port IMAP 993 avec "Utiliser SSL" coché ou le port IMAP + TLS 143 avec ou sans "Utiliser SSL" coché. Outre le manque apparent de support de négociation de certificat client pour IMAP, c'est parfait.
Les références à la prise en charge des certificats client dans la documentation pour la «prise en charge d'entreprise» d'Apple apparaissent uniquement lorsque Microsoft Exchange ActiveSync est abordé et lorsque la prise en charge de Cisco VPN est discutée.
Il y a quelques questions sur les forums de discussion d'Apple, mais aucune récente et aucune réponse utile. Je créerais un lien vers eux, mais les forums d'Apple sont "en panne pour maintenance" pour le moment.
Comme solution de contournement, je peux probablement configurer un VPN verrouillé à l'aide de la prise en charge de la connexion VPN automatique de l'iPad pour parler à un VPN IPSec authentifié client-cert qui ne peut parler qu'aux serveurs IMAP et SMTP sur les ports appropriés plus DNS, rien d'autre. Ce serait un hack assez horrible à devoir perpétrer.
BTW, la conversation client <-> serveur est:
- C -> S TLSv1 Client Bonjour
- S -> C TLSv1 Server Bonjour
- S -> C TLSv1 Certificate, Certificate Request, Server Hello Done (envoie le certificat du serveur, le certificat racine de signature, le DN du signataire du certificat client accepté qui se trouve être le même que la racine qui a signé le certificat du serveur)
- Certificat C -> S TLSv1 (ensemble de certificats vide, zéro certificat inclus)
- S -> C TLSv1 Échec de la prise de contact
En d'autres termes, le serveur dit "c'est moi, je m'attends à ce que vous fournissiez un certificat signé par l'autorité pour prouver qui vous êtes" et le client répond "Um, mes papiers sont dans cette enveloppe vide ici. Regardez, un casoar! "
Le client a le certificat racine installé et un certificat client installé qui a le nom distinctif du signataire demandé par le serveur.