Що відбувається, коли ви замінюєте центр сертифікації VPN

Заміна центру сертифікації VPN — це не підміна файлу. У ту мить, коли новий ЦС підписує свій перший сертифікат, кожен валідатор, який досі довіряє лише старому, мусить ухвалити рішення, а вузли, які так і не отримують новий якір, продовжують відхиляти сумлінних партнерів. Я бачив, як це ламається в обидва боки: шлюз вивчив новий ЦС, а клієнти ні, тож нові з'єднання падали, тоді як уже підняті тунелі залишалися й робили збій схожим на проблему маршрутизації. Ось що змінюється, у тому порядку, у якому з'являються відмови.

Одна заміна, дві окремі зміни

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

Більшість розгортань VPN перевіряють в обидва боки. Клієнт автентифікує сертифікат шлюзу, а шлюз — сертифікат клієнта. Ротація, яка оновлює лише клієнтський пакет, залишає сервер таким, що відхиляє кожного клієнта, який досі подає ідентичність старого ЦС, і зворотне так само поширене. Спершу перелічіть точки застосування: сховища довіри клієнтів, файл ca шлюзу, будь-який проксі, що завершує TLS перед ним, і щуп, який перевіряє кінцеву точку ззовні.

Що перевіряє валідатор, по порядку

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

Щоб повторити цей прохід офлайн, скеруйте -CAfile на той самий пакет, який розгортатимете, а не на системне сховище. Інакше ви перевіряєте вузол, а не зміну:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Ця команда працює лише проти звичайного TLS-слухача, як-от сторінка адміністрування HTTPS на шлюзі; керівний канал OpenVPN іде перед TLS, тож s_client не може зазирнути в рукостискання тунелю.

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

Чому старий тунель продовжує працювати

TLS і OpenVPN обидва тримають встановлений сеанс живим після завершення рукостискання. Ніщо не переперевіряє сертифікат партнера на кожен пакет, тож клієнт, під'єднаний до зміни, продовжує пропускати трафік, доки не переузгодить, не перепід'єднається або тунель не впаде. Саме ця прогалина дозволяє заміні ЦС годину виглядати добре, а потім відмовити в найгірший момент: ноутбук прокидається зі сну, зіставлення NAT спливає, шлюз перезавантажується.

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

Тримайте шар статичного ключа окремо від цього. tls-auth додає HMAC до керівного каналу, tls-crypt шифрує й автентифікує його, і жоден не несе матеріалу сертифіката, тож ротація будь-якого з них — окрема зміна з власним режимом відмови. Розгортання, які змішують обидва, отримують клієнта, у якого статичний ключ гаразд, сертифікат застарілий, а повідомлення про помилку не згадує жодного.

Пастка повторного використання імені суб'єкта

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

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

Ротація, яка не валить мережу

Для планової заміни приймайте обидва якорі протягом обмеженого часу, а не перемикайтеся одним кроком. Видайте новий ЦС і його проміжні сертифікати, покладіть новий якір у пакет кожного валідатора поряд зі старим, і лише потім почніть видавати з нього сертифікати партнерів. Партнери зі старими ідентичностями перевіряються за старим якорем; нові працюють за новим.

Зроблене в такому порядку, кожен крок можна відкотити. Відмова, якої ви уникаєте, — це одночасне перемикання: клієнт, що пропустив оновлення пакета, натрапляє на шлюз, який уже вивів старий якір з експлуатації, рукостискання вмирає, і жоден журнал не каже, яка сторона застаріла.

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

Перевіряйте результат, а не список файлів

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

Підтвердьте, що свіже з'єднання з новою ідентичністю вдається, а потім підтвердьте, що ідентичність, видана виведеним ЦС, відхиляється. Саме другий тест люди пропускають, і лише він показує, що стара установа більше не дає доступу. Там, де розгортання спирається на CRL або OCSP, перевірте, що точки розповсюдження в нових сертифікатах розв'язуються і що партнери, які запитують, досягають відповідача.

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