Самоподписанный сертификат VPN: что он значит и чему доверяет

Здесь больше всего вреда приносят два убеждения: что самоподписанный сертификат VPN означает, что туннель не шифруется, и что установка того, что попросил клиент VPN, влияет только на VPN. Ни одно не выдерживает столкновения с реальным развёртыванием. Самоподписанный сертификат описывает отношение подписи, а не приговор безопасности, и охват добавляемого вами доверия зависит от того, в какое хранилище он попадёт. Я видел, как служба поддержки импортировала корень провайдера в машину с Windows, чтобы заглушить одно предупреждение, а потом провела полдня, объясняя, почему браузер перестал жаловаться на посторонний портал. Две половины этого вопроса принадлежат друг другу, поэтому рассматривайте их как одно.

Сертификат — не хранилище доверия

Файл, который представляет сервер, несёт открытый ключ, имя субъекта, имя издателя, даты действия и расширения. Самоподписанный означает, что субъект и издатель — одна и та же сущность, а подпись проверяется собственным ключом сертификата. Ничто в этом определении не говорит, что соединение слабое, и ничто не говорит, что клиент его примет.

Принятие приходит откуда-то ещё: файл CA, на который вы указываете клиенту, отпечаток, который вы сверяете вручную, или корень, который уже лежит в хранилище, читаемом клиентом. Развёртывание может быть совершенно исправным, хотя его сертификат провалил бы любой публичный тест. openssl verify против системного набора сообщит о неизвестном издателе, и это сообщение верно, а не является дефектом.

Опция ca OpenVPN — самый ясный случай доверия, ограниченного приложением. Этот файл называет якоря, которые клиент примет, и может содержать один частный CA или в небольшом развёртывании собственный самоподписанный сертификат сервера. Версия 2.6 также принимает --peer-fingerprint для закрепления отпечатка SHA-256 вместо распространения файла CA. WireGuard стоит ещё дальше: в нём вообще нет сертификатов, только статический открытый ключ для каждого партнёра, поэтому вопрос о самоподписи к нему не относится.

Где вы устанавливаете доверие, решает, кто его унаследует

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

В Debian или Ubuntu помещение файла в /usr/local/share/ca-certificates/ и запуск update-ca-certificates меняют общесистемный набор. В Windows certutil -addstore -f Root пишет в хранилище машины и требует повышенной командной строки, тогда как добавление -user нацелено на хранилище текущего пользователя; эти два не взаимозаменяемы. Firefox держит собственную базу NSS, поэтому импорт на уровне ОС может там никогда не появиться.

Охват важен из-за того, что может сделать удостоверяющий орган. Издающий CA может подписывать имена, с которыми у него нет никакой связи, поэтому всё, что доверяет этому хранилищу, примет такие подписи. Один закреплённый лист так не может; он удостоверяет ровно одну идентичность партнёра. Если цель — заставить один VPN подключаться, CA, ограниченный приложением, или закреплённый лист этого достигают, а корень на уровне всей машины — гораздо большая уступка, чем требует симптом.

Вы всё ещё шифруете без публичного CA

Рукопожатие TLS выводит ключи сеанса независимо от того, связывается ли сертификат партнёра в цепочку с чем-то, чему вы уже доверяете. Самоподписанный не означает открытый текст и не означает, что трафик читается в полёте. Он означает, что у клиента нет априорной причины верить, что ключ принадлежит тому серверу, который он запросил.

Именно в этом промежутке живут настоящие атаки. Клиент, настроенный принимать любой сертификат, будь то через отключённую проверку или через кнопку «всё равно доверять», нажатую один раз и забытую, будет с радостью шифровать тому, кто ответит. Перехват происходит на этапе аутентификации, до того как двинутся данные приложения. Шифрование без проверки идентичности держит пассивного наблюдателя снаружи и делает мало что ещё.

Доверие издателю не пропускает проверку имени

Проверка цепочки, совпадение имени и назначение сертификата — отдельные решения. Цепочка может быть действительной, пока имя неверно, и имя может совпадать, пока сертификат выдан для другой роли. RFC 5280 определяет поля, которые несут эти ограничения, а то, насколько строго клиент их применяет, — вопрос каждого приложения.

OpenVPN делает разделение видимым. verify-x509-name закрепляет ожидаемый субъект через совпадение name, name-prefix или subject. remote-cert-tls server требует, чтобы сертификат партнёра был пригоден как серверный сертификат, что отвергает сертификат только клиента даже при доверенном издателе. Ни одна из настроек не заменяется отправкой файла CA.

Осмотрите сертификат, прежде чем что-либо решать:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName показывает, кто его выдал, для каких имён и до какого срока.
• openssl verify -CAfile ca.crt server.crt проверяет, действительно ли цепочка, которую вы собираетесь отправить, подтверждает лист.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error работает для конечных точек TLS, например веб-портала; протокол OpenVPN на порту 1194 не является обычным потоком TLS, поэтому этот тест там не применяется.

Сертификат с истёкшей датой, без subjectAltName для имени, к которому вы подключаетесь, или без использования serverAuth не проходит независимо от того, насколько аккуратно установлен якорь.

Пять проверок, прежде чем принять один

Сравните отпечаток по каналу, который не является соединением, которое вы пытаетесь починить: консоль, уже имеющийся установщик, подписанный файл конфигурации. openssl x509 -in server.crt -noout -fingerprint -sha256 на сервере и то же значение в журнале клиента достаточно, чтобы знать, что вы смотрите на один объект.

Затем решите, что вы устанавливаете: один лист или орган, который может отчеканить больше. Потом решите, куда это идёт, и назовите приложения, которые читают это хранилище. Запишите путь удаления, пока ещё помните его, потому что «доверься и иди дальше» — это способ, которым временный импорт становится постоянным.

Наконец, спланируйте изменение. Закреплённый сертификат или отпечаток нужно обновлять через тот же доверенный канал, когда сертификат меняется, а у частного CA свой жизненный цикл выпуска и отзыва. Если закрытый ключ утёк, повторное доверие копии того же сертификата ничего не исправляет; идентичность нужно заменить.

Если предупреждение переживает все пять проверок, полезный вопрос не в том, какая кнопка его заглушает, а в том, какое хранилище клиент на самом деле читает и откуда взялся этот корень. Ответьте на это, и импорт, который вы собираетесь сделать, станет решением, а не рефлексом.