Самоподписанный или публичный 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, когда каждый клиент получает профиль, который контролируете вы. Ни один из ответов не зашифрован сильнее другого.