В профиле OpenVPN три блока сертификатов: какой из них секретный?

Вы открываете файл .ovpn, чтобы изменить одну строку, и находите три блока base64, которые все выглядят как учётные данные. Один безопасно публиковать, второй так же чувствителен, как пароль, а третий — открытый ключ, который ничего не значит, пока что-то другое не подписано его парой. Люди вставляют весь файл в ветку поддержки, потому что блоки кажутся взаимозаменяемыми, и именно так клиентский ключ оказывается в публичном архиве. Разобраться, что делает каждый блок, объясняет большую часть путаницы вокруг этих профилей и подсказывает, какие сбои исправлять вам самим.

Один файл, три блока, разные задачи

Обычный профиль встраивает блок ca, блок cert и блок key между маркерами BEGIN и END либо указывает на те же три как на отдельные файлы. Некоторые профили добавляют четвёртый блок для ключа tls-auth или tls-crypt, который является общим секретом, а не сертификатом. Клиент читает каждый блок согласно директиве, которая его называет, поэтому метки важнее порядка появления.

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

Директивы вокруг блоков определяют, как они используются. Измените ca — и клиент доверяет другому удостоверяющему центру; измените cert, не меняя key, — и рукопожатие срывается из-за несоответствия, не имеющего отношения к доверию.

Блок CA открыт, ключ CA — никогда

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

То, что никогда не должно появляться в клиентском профиле, — закрытый ключ подписи центра. Клиенту он не нужен ни для какой проверки, а его наличие означает, что любой, у кого есть профиль, может создать новые идентичности для всего развёртывания.

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

Серверный и клиентский сертификаты направлены в противоположные стороны

Серверный сертификат — это то, что клиент проверяет, чтобы убедиться, что попал на нужную конечную точку. Ваш клиентский сертификат работает наоборот: сервер использует его, чтобы решить, что это устройство или пользователь — из числа зарегистрированных им. Тот же формат, противоположное направление доверия.

Адрес — не идентичность. Достижение нужного IP ничего не доказывает о том, кто ответил, поэтому проверка имени хоста или имени сертификата всё ещё относится к профилю. Пароль учётной записи тоже не подменяет тихо требуемый клиентский сертификат, потому что оба проверяются на разных этапах, и развёртывание может требовать оба.

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

Два запроса, которые выглядят одинаково и таковыми не являются

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

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

Когда сертификат действительно истёк, замена должна прийти от того, кто его выдал. Ключ, принадлежащий кому-то другому, — не путь обновления, как и заимствованный рабочий профиль у коллеги.

Что доказывает чистое рукопожатие и чего не доказывает

Достижение завершённого TLS-рукопожатия означает, что настроенное отношение идентичностей выдержало: серверный сертификат выстроился к вашему CA, а ваш сертификат был принят. Это ничего не говорит о политике журналирования оператора и ничего о том, будут ли работать ваши приложения после подъёма туннеля.

Маршруты и DNS — более поздние этапы соединения, поэтому недоступный хост интрасети после успешного входа — это проблема связи, а не сертификата. Работайте с этим уровнем вместо подмены учётных данных и держите вместе происхождение профиля, его закрытый материал и его проверки идентичности, когда передаёте его кому-либо.