Самоподписанный сертификат клиента? VPN-сервер всё равно его отклоняет

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

Доверие живёт на сервере, а не в вашем профиле

Аутентификация по сертификату — это сравнение. Клиент предъявляет сертификат; шлюз проверяет, подписан ли он одной из CA в его конфигурации.

Ваш профиль указывает файл CA, который клиент должен использовать для проверки сервера. Он не может указать CA, которую сервер должен использовать, чтобы проверить вас. Эта половина конфигурации не ваша.

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

Почему самоподписанный сертификат не может его заменить

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

Шлюз не спрашивает, согласован ли сертификат внутренне. Он спрашивает, подписал ли его доверенный издатель.

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

Путь через CSR сохраняет ваш закрытый ключ

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

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

Оператор подписывает запрос своей CA и возвращает сертификат. Ваш закрытый ключ никуда не путешествовал, а результат выстраивает цепочку до якоря, которому доверяет шлюз.

Управляемые сервисы часто пропускают CSR и выдают весь пакет. Это разумный обмен, когда тот же провайдер уже завершает туннель и владеет CA. Хранение ключа не улучшается от того, что вы его держите, потому что провайдер может в любой момент создать новый.

Пакеты импортируются, а не устанавливаются

Пакеты поставщиков с безопасно звучащими именами часто являются профилями OpenVPN. Они содержат конфигурацию и иногда сертификаты и ничего не устанавливают. Импортируйте файл в клиент, который говорит на этом протоколе, и соединение будет настроено.

Правило обращения следует из содержимого. Если профиль содержит закрытый ключ, это удостоверение, и оно заслуживает такой же заботы, как пароль: никакой почты, никакого хранилища, никакой общей папки загрузок. Когда оператор поставляет ca.crt, client.crt и client.key отдельно, храните их вместе с ограничительными правами и укажите на них в профиле.

Добавьте проверки, которые оператор мог пропустить

В профиле, созданном маршрутизатором, иногда нет проверки партнёра. remote-cert-tls server требует, чтобы сертификат партнёра нёс назначение аутентификации сервера, поэтому сертификат клиента нельзя воспроизвести как сервер. Эта одна строка — небольшое изменение с ясным обоснованием.

verify-x509-name идёт дальше, когда оператор может указать ожидаемый субъект или SAN. Оба — небольшие дополнения к профилю, и оба оправданы. Проверьте, что вы получили, прежде чем импортировать.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

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

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