Оновлений сертифікат VPN: деякі клієнти все ще відхиляють його

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

Одне оновлення, дві поведінки

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

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

Оновлення замінює об’єкт, а не лише дату

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

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

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

Прочитайте, що закріплює клієнт

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

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

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

Порівняйте сертифікат, який надає кожен backend

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

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

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

Змінюйте довіру керованим шляхом

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

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