Копирование сертификата VPN не копирует ключ

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

Два щелчка, два совершенно разных артефакта.

Читайте диалог экспорта, а не расширение файла

Экспорт сертификата DER или PEM содержит открытый ключ и подписанные утверждения о личности, то есть то, что нужно серверу, чтобы доверять вам, и то, что нужно клиенту, чтобы проверять сервер. Пакет PKCS#12 — это контейнер, который может хранить сертификат, его цепочку и соответствующий закрытый ключ, защищённый паролем, хотя его можно создать и без ключа.

PEM — это только текстовая кодировка, а не обещание о содержимом. Одно и то же расширение может описывать один сертификат или файл с несколькими помеченными блоками, и что именно — решают параметры экспорта.

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

Изучите, что вы действительно получили

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

grep -E 'BEGIN (CERTIFICATE|PRIVATE KEY|ENCRYPTED PRIVATE KEY)' bundle.pem
openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -text | head -5
openssl pkcs12 -info -in client.p12 -noout

Экспорт только с блоком сертификата — это публичный объект, и он не может пройти аутентификацию. Блок ключа без сертификата оставляет вас без цепочки, которую ожидает сервер. Вывод сведений PKCS#12 также сообщает, присутствует ли ключ, и это решает вопрос для данного формата. Он называет и алгоритм, и размер ключа, и полностью завершается ошибкой, когда ключа нет.

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

Ключ может находиться там, откуда его нельзя скопировать

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

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

Зарегистрируйте новую личность вместо копирования

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

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

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