Оновлення сертифіката VPN без зміни його ідентичності

Оновлення сертифіката, яке змінює ідентичність, — це не оновлення, а міграція в квитку на обслуговування. Клієнт перевіряє ім'я, ланцюжок і іноді конкретний ключ, і всі три можуть змінитися без зміни дати завершення. Перед запитом заміни запишіть, що клієнт справді перевіряє: ім'я хоста або ідентичність партнера, призначення сертифіката, політику ключів і ланцюжок видавця. Оновлення є рутинним або узгодженим залежно від того, що з цього змінює заміна.

Три умови визначають форму оновлення

Три умови такі: чи щось закріплює листок, чи змінюється ланцюжок і хто ще перевіряє ім'я. Відповідайте з боку клієнта, а не з міркувань зручності CA, бо саме клієнт відмовляє о третій годині ночі.

Почніть з огляду наявного сертифіката. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName виводить суб'єкта, видавця, вікно дії та імена, для яких сертифікат справді дійсний. Останнє поле найважливіше і найчастіше припускається: запит на оновлення, у якому пропущено SAN, на який покладається клієнт, дає сертифікат, технічно дійсний, але функціонально неправильний. Скопіюйте список SAN зі старого сертифіката в запит, а не набирайте його заново з пам'яті.

Умова перша: чи щось закріплює листок

Якщо клієнти довіряють підтримуваному CA і перевіряють ім'я, оновлення листка з новим ключем для них непомітне. Якщо будь-який клієнт закріплює листковий сертифікат, його відбиток або його відкритий ключ, заміна є узгодженою зміною з жорстким переходом, бо старе закріплення не може перевірити новий сертифікат.

З'ясуйте, у якому ви випадку, перш ніж щось замовляти. Закріплення, яке ніхто не задокументував, залишається закріпленням, коли ламається.

Умова друга: порівняйте закріплення та ланцюжок

Відбитки роблять закріплення перевірюваним: openssl x509 -noout -fingerprint -sha256 -in server.crt на старому й новому сертифікаті та openssl x509 -noout -pubkey для порівняння відкритих ключів. Якщо конфігурація клієнта, мобільний профіль або сховище довіри пристрою містить будь-яке зі значень, у вас є закріплення. Мобільні профілі VPN — часте сховище, бо профіль поширюється один раз і більше ніколи не переглядається.

Якщо заміна походить від того самого проміжного і клієнт уже має його або може отримати, на боці довіри нічого не змінюється. Новий проміжний, інший видавець або ланцюжок, доставлений у неправильному порядку, перетворюють оновлення на зміну довіри, і збій виглядає як невідомий видавець, а не як прострочений сертифікат.

Перевірте ланцюжок, який сервер справді надсилає, за допомогою openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts і підтвердьте його локально за допомогою openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Якщо зробити це до зміни, ви матимете базову лінію для подальшого порівняння.

Умова третя: хто ще перевіряє ім'я

Концентратор VPN, балансувальник навантаження, зонд моніторингу, інтеграція RADIUS або SAML і мобільний профіль можуть кожен зберігати власну копію очікуваного імені або якоря довіри. Оновлення — це момент, коли ці копії розходяться, бо сертифікат змінюється, а копії ні.

Перелічіть кожного споживача до зміни та вирішіть для кожного, чи потрібне оновлення. Той, кого ви забудете, і зателефонує вам.

Є й пастка часу. Перевірте початок дії, а також завершення, бо сертифікат, підготовлений для пізнішої активації, відхиляється, якщо встановлений надто рано, і помилка виглядає як проблема з годинником, а не як проблема підготовки. openssl x509 -noout -dates на новому файлі перед розгортанням — перевірка на дві секунди. Зберігайте також підтримуваний шлях відновлення та відому добру конфігурацію, щоб невдале оновлення можна було відкотити, відновивши попередній сертифікат і ключ.

Розгорніть, перевірте новою автентифікацією, потім виведіть з експлуатації

Усталений тунель відображає перевірку, що відбулася під час його побудови, тож може виглядати здоровим, поки кожне нове з'єднання зазнає невдачі. Перевірте новою автентифікацією, використовуючи фактичну назву служби, яку використовують клієнти.

Завершіть перевірку на рівні застосунку, яка важлива користувачеві, і підтвердьте доставку ланцюжка з погляду клієнта, а не сервера. Не придушуйте перевірки імені чи сертифіката, щоб перехід був тихим; це перетворює тимчасову проблему сумісності на постійну.

Виводьте застарілий матеріал з експлуатації лише після перевірки розгортання, а скомпрометований ключ розглядайте як цілком окремий випадок: саме оновлення нічого не відкликає, тому постраждалій ідентичності потрібен процес відкликання та керування сеансами цього розгортання. RFC 5280 визначає правила сертифікатів і перевірки шляху, на яких усе це тримається. Тримайте рутинне оновлення листка окремо від заміни CA, щоб клієнтів не просили довіряти новому видавцю без причини.