Проверка сертификата VPN без раскрытия ключа
Читайте открытые поля, даты и отпечатки, не выводя материал ключа. Безопасность команды зависит от того, что лежит в файле и кто увидит вывод.
Чтение открытых полей сертификата никогда не требует показывать парный закрытый ключ, а инструменты для этого входят в каждую систему, которая завершает соединение VPN. Риск возникает на шаг раньше: файл, который вам передали, может вообще не быть сертификатом. Сертификат PEM, двоичный объект DER, пакет PKCS#12 и профиль OpenVPN могут прийти под одним и тем же именем и содержать совершенно разный материал, поэтому сначала определите контейнер, а потом выбирайте команду.
Три факта решают, какая команда безопасна: что лежит в файле, что нужно из него прочитать и кто увидит вывод. Ошибка хотя бы в одном превращает саму проверку в инцидент.
Какой из трёх файлов вам передали
Сертификат PEM — это текст с видимыми маркерами BEGIN и END, файл DER — двоичные данные, для которых нужен флаг формата ввода, а пакет — это контейнер, который может содержать ключ рядом с сертификатом. file server.crt за секунду отделяет текст от двоичных данных, а взгляд на первую строку отличает голый сертификат от профиля, в который он встроен. Именно догадки превращают проверку в инцидент.
Если файл — это профиль, а не сертификат, считайте его учётными данными, пока не доказано обратное. Такое допущение ничего не стоит и предотвращает самую частую ошибку во всей этой задаче.
Чтение открытых полей сертификата PEM
Для сертификата, который вам разрешено проверять, подкоманда x509 с -noout выводит только выбранные поля и ничего больше. Подавление тела сводит вывод к метаданным, и именно поэтому его безопасно вставлять в заявку. Селекторы ниже — открытые, а документация openssl x509 перечисляет остальные.
openssl x509 -in server.crt -noout -subject -issuer -dates -fingerprint -sha256
На локально созданном тестовом сертификате эта команда выводит строки subject и issuer, пару notBefore и notAfter и один отпечаток SHA-256. Эти поля идентифицируют объект; они не устанавливают действительный путь доверия, а это отдельная задача проверки со своей командой и своим ответом. Файл цепочки может вывести только первый сертификат, если вы сами не пройдёте по файлу. Сравнение двух файлов таким способом стоит одной команды и решает, какой из них на самом деле предъявляет другая сторона.
Пакеты, в которых ключ лежит рядом с сертификатом
Файл .p12 или .pfx может содержать закрытый ключ, и команда разбора выведет его, если не подавить эту часть вывода. С -nokeys та же команда по-прежнему сообщает структуру контейнера, включая зашифрованный контейнер ключа, не выводя никакого материала ключа; уберите этот флаг, и блок ключа появится в терминале и в истории оболочки.
openssl pkcs12 -in bundle.p12 -nokeys -info -passin env:P12PASS
Профиль OpenVPN содержит тот же материал в виде текста, поэтому граница видна, если знать, куда смотреть. Открытый материал находится между BEGIN CERTIFICATE и END CERTIFICATE, а всё между BEGIN PRIVATE KEY и соответствующей строкой END — это ключ, и он не должен покидать хост. Копирование профиля целиком публикует и то и другое.
Откуда взять эталонное значение
Отпечаток, прочитанный из соединения, которое вы пытаетесь проверить, ничего не доказывает, потому что его предоставила сторона, которой вы не доверяете. Это не аргумент против отпечатков; это аргумент о происхождении. Сравнивайте значение с тем, что получено по каналу, в который другая сторона не может писать, например с сертификатом, опубликованным во внутреннем репозитории, или с хешем, напечатанным в подписанной записи об изменении.
Там, где проверку выполняет хранилище доверия, дайте ему это сделать и прочитайте возникшую ошибку, вместо того чтобы подменять её собственным сравнением. Важно, кто предоставил эталон, а не то, какая хеш-функция использовалась.
Как поделиться результатом и что делать после промаха
Отправьте точный текст ошибки проверки, нужные даты и только те идентификационные данные, которые нужны получателю. Внутренние имена хостов и идентификаторы учётных записей остаются чувствительными, даже когда ключа рядом нет, а публичный сервис вставки — неподходящее место для всего этого. Вставляйте в заявку, а не в общий временный буфер.
Если материал ключа всё-таки появился на экране или в файле, считайте его скомпрометированным и замените, а не надейтесь, что никто не смотрел. Затем запишите, какой файл проверяли, какую команду использовали и куда ушёл вывод, потому что эта запись превращает испуг в процедуру. Замена ключа дешева по сравнению с ценой предположения, что никто не сохранил снимок экрана, и та же запись подскажет следующему инженеру, какие файлы вообще были затронуты. Сделайте и то и другое до закрытия заявки.