Самопідписаний чи публічний CA для VPN: що насправді змінюється

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

Сертифікат виконує дві задачі, які плутають

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

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

Міцність отриманої сесії походить від розміру ключа й набору шифрів, а не від підписувача. Тому називати самопідписаний сертифікат "менш зашифрованим" просто неправильно; він менш широко гарантований, а це інша властивість.

Де публічний CA виправдовує свою плату

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

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

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

Де приватний CA підходить для VPN

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

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

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

Приватний ключ CA вирішує, що ви зможете робити пізніше

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

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

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

Перевірте, що ви успадкували

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

$ openssl x509 -in server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.net
issuer=CN = vpn.example.net
notAfter=Nov  3 09:00:00 2027 GMT
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK

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

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