Коротка версія: Хтось знає, чи повинні сертифікати клієнтів X.509 працювати на iPad для пошти IMAP? Я витрачаю час, намагаючись отримати функцію, яка не працює? Якщо вбудована поштова програма не підтримує IMAP з клієнтськими сертифікатами X.509 (тобто: вони працюють лише з обліковими записами Microsoft Exchange ActiveSync), чи є такі додатки сторонніх розробників?
Представляє інтерес лише iOS 5.1 або новіші; 5.1 - версія, з якою я тестував.
Я адміністратор мережі, яка вимагає політики використання клієнтських сертифікатів X.509 для захисту всіх зовнішніх комунікацій, включаючи наш поштовий сервер IMAP (Cyrus IMAPd) та SMTP-сервер (постфікс). Жодне з них не прийме з'єднання, не представивши клієнту дійсний клієнтський сертифікат X.509. Відключення вимоги клієнтського сертифіката не є для мене варіантом, і нам заборонено тунельний трафік через VPN з подібних причин.
Зараз у нас є користувачі iPad, які хочуть підключитися до нашої мережі і вважають, що iPad є проблемою.
Для користувачів на настільних машинах ми зазвичай встановлюємо Thunderbird, оскільки він має надійний IMAP з відмінною підтримкою сертифікатів клієнта; він "просто працює" і підтримується на всіх платформах. Це не варіант для iPad.
На жаль, вбудований додаток пошти iPad, схоже, не справляється із клієнтськими сертифікатами для IMAP. Я можу встановити кореневий cert нашого org і клієнтський cert користувача за допомогою утиліти настройки iPhone. Обидва відображаються як "перевірені" у Налаштуваннях-> Загальні-> Профілі. Потім iPad приймає наш сервер як довірений та видаляє будь-які попередження про ідентифікацію сервера, що не перевіряються.
Пошта все ще не може надіслати сертифікат клієнта, коли від нього вимагається, щоб сервер припиняв рукостискання. Це не спонукає користувача вибрати його, а також не надсилає автоматично встановлений клієнтом сертифікат для користувача, який відповідає сертифікату CA, представленому сервером.
Вивчення потоку трафіку між клієнтом і сервером показує, що узгодження TLS закінчується невдачею, коли iPad відповідає порожнім набором клієнтських сертифікатів, коли сервер вимагає сертифікати клієнта. Дивіться нижче.
Підключившись до внутрішньої мережі через зашифрований WiFi, де для отримання пошти не потрібен сервер клієнта, пристрій підключається та завантажує пошту просто чудово. Зовнішній доступ (загальнодоступний Wi-Fi або понад 3G) не вдається, чи використовую я порт IMAPs 993 з відміткою "Використовувати SSL" чи порту 143 IMAP + TLS з посиланням "Використовувати SSL" або без нього. Крім очевидної відсутності підтримки клієнтських сертифікатів для переговорів щодо IMAP, він ідеальний.
Посилання на підтримку сертифікатів клієнта в документації на "Підтримка підприємства" від Apple з'являються лише там, де обговорюється Microsoft Exchange ActiveSync, і де обговорюється підтримка VPN Cisco.
На дискусійних форумах Apple є кілька питань, але останніх немає і корисних відповідей. Я б посилався на них, але на даний момент форуми Apple "перебувають на технічному обслуговуванні".
В якості вирішення я, ймовірно, можу налаштувати заблокований VPN, використовуючи підтримку автоматичного VPN-з'єднання iPad, щоб спілкуватися з клієнтом, що підтверджений клієнтом IPSec VPN, який може спілкуватися лише з серверами IMAP та SMTP на відповідних портах плюс DNS, нічого іншого. Це було б дуже жахливим злом, хоча потрібно вчиняти.
До речі, розмова з клієнтом <->:
- C -> S TLSv1 Клієнт Привіт
- S -> C TLSv1 Сервер Привіт
- S -> C TLSv1 сертифікат, запит на сертифікат, сервер привіт виконано (надсилає серт cert, кореневий cert підпису, DN прийнятого підпису cert клієнта, що, як буває, те саме, що і корінь, який підписав cert сервера)
- C -> S TLSv1 сертифікат (порожній набір сертифікатів, нульовий сертифікат включений)
- S -> C TLSv1 Помилка рукостискання
Іншими словами, сервер каже "це я, я очікую, що ви надасте сертифікат, підписаний владою, щоб довести, хто ви", а клієнт відповідає "Гм, мої папери тут у цьому порожньому конверті. Подивіться, казуарій! "
У клієнта встановлений кореневий cert і встановлений клієнтський cert, який має підписувач DN, який вимагає сервер.