Сопоставитель сертификатов и ключей

Положите любую смесь сертификатов, закрытых ключей и CSR — PEM или DER — и эта рабочая среда докажет, какой ключ соответствует какому сертификату, упорядочит сертификаты в цепочку, сконвертирует форматы и создаст CSR. Закрытые ключи никогда не покидают ваш браузер: всё разбирается локально в этой вкладке, ключи хранятся только в памяти и никогда не загружаются, не записываются в журнал и не сохраняются, а эта страница не делает ни одного сетевого запроса. Чтобы декодировать один сертификат в глубину, используйте парсер SSL-сертификатов; для быстрого самоподписанного сертификата — генератор самоподписанных сертификатов.

Добавить сертификаты, ключи и CSR

Вердикт сопоставления

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

Конструктор цепочек

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

Создать CSR

Запрос на подпись сертификата для ключа, созданного здесь, в вашем браузере: заполните субъект, выберите тип ключа и скачайте CSR, чтобы отправить его в ваш ЦС — плюс закрытый ключ, который вы должны хранить в безопасности сами. Ключ показывается только здесь; эта страница его не сохраняет.

Как сопоставление работает на самом деле

Сертификат и закрытый ключ — не две половины одного файла; это два файла, которые разделяют один математический объект. Когда создаётся пара ключей, открытая половина помещается внутрь сертификата (и внутрь любого CSR, сделанного из этого ключа), а закрытая половина остаётся в файле ключа. Два элемента совпадают ровно тогда, когда они несут один и тот же открытый ключ — для RSA один и тот же модуль и показатель; для EC одну и ту же точку на одной и той же кривой. Эта страница кодирует этот открытый ключ в его стандартной обёртке (SubjectPublicKeyInfo), хэширует кодировку с помощью SHA-256 и группирует каждый загруженный элемент по этому хэшу. Хэш, показанный на каждой карточке, — это поэтому доказательство, а не сводка: идентичные хэши не могут возникнуть случайно, а несовпадение столь же достоверно, и потому вердикт можно произнести прямо — этот ключ соответствует этому сертификату, или ни один загруженный ключ не соответствует. Классический сбой, который это ловит, описан в когда ваш ключ не соответствует вашему сертификату: перезагрузка в 2 часа ночи, при которой обновлённый сертификат на диске принадлежит другому ключу, а не тому, что сервер загрузил.

Имена файлов ничего не доказывают. Каталог, полный server.crt, server.key, final-v2.pem и CSR из прошлогодней попытки обновления, — это нормальное состояние унаследованной инфраструктуры, а имена — археология, а не документация. Совпадающее расширение файла или совпадающая дата тоже ничего не доказывают. А традиционная проверка openssl — сравнение хэша модуля сертификата с хэшем модуля ключа? Это ровно проверка этой страницы, ограниченная RSA и одной парой за раз, и она полностью пропускает ключи EC, потому что у ключей EC нет модуля. Отпечаток открытого ключа равномерно покрывает каждый алгоритм, и потому именно он является здесь ключом группировки.

Цепочки, порядок и что значит «проверено»

От серверов ожидается, что они предъявляют сначала листовой сертификат, затем каждый промежуточный по порядку, чтобы клиент мог пройти по звеньям от издателя к субъекту до корня, которому он уже доверяет. Предъявление тех же сертификатов в неправильном порядке — или с отсутствующим промежуточным — производит классическое семейство ошибок «unable to get local issuer certificate» у клиентов, которые не могут сами получить недостающее звено. Конструктор выше восстанавливает порядок только по именам, что всегда возможно, а затем идёт на шаг дальше: для подписей RSA и ECDSA он импортирует открытый ключ издателя и проверяет подпись поверх подписанных байтов сертификата. Звено с меткой подпись проверена доказано криптографически. Звено с меткой только совпадение имени — нет: имена сцепляются, но подпись использует алгоритм, который эта платформа не проверяет (RSA-PSS — обычный случай), и страница говорит об этом, а не выдаёт совпадение имени за доказательство. Если проверка подписи не проходит, имена были совпадением или подделкой, и конструктор показывает сбой красным вместо того, чтобы тихо собрать набор.

Форматы: PEM, DER и вопрос о .pfx

PEM — это байты DER, обёрнутые в Base64 с помеченным заголовком; DER — это сырая кодировка. Преобразование между ними ничего не теряет и ничего не доказывает — это тот же объект в другом конверте, — и потому каждая карточка предлагает обе загрузки. Windows и некоторые инструменты Java предпочитают DER или PKCS#12; большинство инструментов Unix хотят PEM. PKCS#12 (.pfx/.p12) — другое дело: это зашифрованный контейнер с собственным MAC целостности, и создать такой, который примет каждый потребитель, — с защитой, достойной этого имени, — не то, что следует делать вручную на веб-странице. Этот инструмент сознательно его не предлагает. Чтобы упаковать подобранную пару самостоятельно, выполните openssl там, где живут файлы: openssl pkcs12 -export -inkey key.pem -in cert.pem -certfile chain.pem -out bundle.pfx — после того, как эта страница сказала вам, какой ключ, сертификат и цепочка действительно принадлежат друг другу.

Разбор и построение цепочек — это вручную написанный код DER для этого сайта (в стиле BSD, без стороннего парсера); хэширование, проверка подписи и создание ключей используют WebCrypto браузера. Никакая часть этого инструмента не делает сетевых запросов.

Часто задаваемые вопросы

Как сопоставитель доказывает, что ключ и сертификат принадлежат друг другу?

Сравнивая открытый ключ, а не файлы. Каждый сертификат, CSR и закрытый ключ даёт один и тот же закодированный открытый ключ (SubjectPublicKeyInfo); эта страница хэширует его с помощью SHA-256 и группирует элементы, чьи хэши совпадают. Идентичный открытый ключ означает, что закрытый ключ математически является тем самым, для которого был выдан сертификат, — та же проверка, которую openssl выполняет сравнением модулей, сделанная для каждого файла сразу и для ключей EC, как и для RSA.

Безопасно ли загружать настоящий закрытый ключ в веб-страницу?

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

Что означает «только совпадение имени» в конструкторе цепочек?

Конструктор цепочек упорядочивает сертификаты, сопоставляя имя издателя каждого сертификата с именем субъекта следующего, а затем пытается проверить фактическую подпись открытым ключом издателя. Когда алгоритм подписи — один из тех, что WebCrypto браузера может проверить (на практике RSA и ECDSA), звено помечается как «подпись проверена» или, если проверка не проходит, «подпись НЕ ПРОШЛА». Всё остальное — RSA-PSS — обычный случай — честно помечается как «только совпадение имени»: имена совпадают, но эта страница не доказала звено криптографически.

Почему нет экспорта в PKCS#12 (.pfx)?

Файл PKCS#12 оборачивает ключ и сертификат в шифрование на основе пароля с целостностью MAC — формат, которому нужна аккуратная, хорошо протестированная кодировка. Вместо того чтобы поставлять вручную собранную версию, которая могла бы создавать файлы, отвергаемые другим программным обеспечением (или, что хуже, слабо защищённые ключи), эта страница конвертирует между PEM и DER и оставляет упаковку .pfx для openssl: команда показана на странице, чтобы вы могли выполнить её там, где ключ уже живёт.

Может ли эта страница прочитать зашифрованный закрытый ключ?

Она может опознать такой ключ и сказать об этом, но не может его использовать: зашифрованный (защищённый паролем) ключ не раскрывает свой открытый ключ, пока не будет расшифрован, а сопоставление выполняется по открытому ключу. Расшифруйте копию локально с помощью openssl (pkcs8 -topk8 -nocrypt, или rsa/ec) и загрузите расшифрованную копию — на машине, которой вы доверяете, и удалите копию после этого.