Как посмотреть цепочку сертификатов
Установка SSL-сертификата является важным этапом при переходе на протокол безопасного соединения HTTPS — он обеспечивает сохранность персональных данных. Такой сайт вызывает больше доверия у пользователей. Также защищенность веб-ресурса может влиять на его позиции в поисковой выдаче.
Как правило для шифрования информации, пересылаемой между браузером посетителя и сервером, достаточно одного сертификата. Однако некоторые ресурсы требуют большей надежности и многоуровневой защиты. Например, банковский ресурс предполагает проведение крупных финансовых операций. В этом случае необходим SSL-сертификат, который содержит не только сертификат для домена, но цепочку сертификатов (CA Bundle).
Цепочка сертификатов SSL включает в себя сертификаты поручителей, подтверждающие валидность документа в целом.
Как посмотреть цепочку сертификатов
Примечание: данный материал публикуется как обязательный для знания IT-специалистами, которые занимаются или только собираются заниматься темой PKI (Public Key Infrastructure).
Введение
На самом деле эта тема тесно переплетается с фундаментальными основами PKI, как доверие сертификатов, защита от подделки цифровых подписей сертификатов, отзыв сертификатов и т.д. Иными словами, сама модель PKI лежит на Certificate Chaining Engine (механизм построения цепочек сертификатов). Миллионы людей в мире видят результат работы этого механизма ежедневно, но не знают, как он работает. Им это, в принципе, и не надо, а вот IT-специалистам по PKI это знать просто необходимо.
Одной из основ PKI является модель доверия центрам сертификации (Certification Authority или просто CA). Прежде чем мы начнём доверять сертификату мы должны явно доверять корневому сертификату CA и так же явно или косвенно (по правилу одностороннего транзитивного доверия) доверять всем промежуточным CA в цепочке. Корневые сертификаты устанавливаются в систему вручную путём добавляения сертификата CA в секцию Trusted Root CAs. Если корневой сертификат CA есть в этом списке, то мы доверяем всем сертификатам, которые выдал этот CA и любые подчинённые CA (Intermediate CA).
В качестве наиболее доступного и понятного примера можно рассмотреть SSL веб-сайт. Если мы зайдём на https://www.dreamspark.com, то мы увидим что с SSL сертификатом этого сайта всё в порядке. Если же мы зайдём на https://cert.startcom.org, то мы наоборот увидим грозное предупреждение, что с SSL сертификатом этого сайта что-то не так. Это как раз и есть результат работы Chaining Engine. А вот что он сделал на самом деле — вот об этом мы сейчас и поговорим.
Постройка цепочки сертификатов
Давайте сначала посмотрим на путь сертификатов (цепочки сертификатов) обоих веб-сайтов:
В первом случае цепочка сертификатов заканчивается на сертификате VeriSign, которому мы доверяем явно. Вы можете убедиться в этом нажав кнопку View Certificate, чтобы посмотреть его внутренности и найти этот же сертификат в оснастке certmgr.msc –> Trusted Root CAs . Однако, вы видите, что не корневой CA выдал сертификат сайту, а подчинённый (Intermediate CA). Это доказывает то, что если мы доверяем корню, то и явно или косвенно доверяем всем сертификатам этого CA или любым его прямым или косвенным промежуточным CA. Если говорить простым языком, то в сертификатах используется одностороннее транзитивное доверие сертификатам CA. Чуть позже будет рассказано как строится эта цепочка. Во втором случае мы видим, что корневой сертификат CA не находится у нас в Trusted Root CAs и, следовательно, мы не доверяем ни одному сертификату, который издал этот CA или любой другой его подчинённый CA. И, так же как и в первом случае, сертификат самому веб-сайту выдал подчинённый CA. На самом деле этот момент является одной из наиболее частых ошибок системных администраторов, которые организовывают доступ к ресурсам с использованием цифровых сертификатов.
Но нас теперь интересует другой вопрос — а откуда же взялись все эти сертификаты в цепочке? Chaining engine как правило использует только 3 метода построения цепочки:
- по полю AIA (Authority Information Access) каждого сертификата
- с использованием файла цепочки сертификатов в формате pkcs7
- поиск подходящих сертификатов в локальном хранилище (с использованием exact, key, name matches, о которых будет рассказно ниже)
Примечание: в сертификате любое поле содержащее слово Authority будет означать какие-то сведения о сертификате вышестоящего CA. Например, Authority Key Identifier — комбинация серийного номера, поля Subject или хеша открытого ключа вышестоящего CA. А любое поле содержащее слово Subject — означает то же самое, но применительно к конкретно этому сертификату.
Давайте посмотрим поле AIA первого сертификата:
[1]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL= http://www.microsoft.com/pki/mscorp/Microsoft%20Secure%20Server%20Authority(5).crt
В этом поле содержится ссылка на сертификат того CA, который непосредственно издал и подписал этот сертификат. Если нажать по этой ссылке, то вы скачаете сертификат центра сертификации Microsoft Secure Server Authority. В этом сертификате тоже будет поле AIA, по ссылке из которого скачается сертификат вышестоящего CA — Microsoft Internet Authority. И так проверка проводится далее до тех пор, пока цепочка не оборвётся или не закончится каким-либо корневым CA (корневой CA характеризуется самоподписанным сертификатом, т.е. сертификат выдан самому себе). Если вы посмотрите сертификат Microsoft Internet Authority, то вы в нём не обнаружите поля AIA. И вот здесь мы сталкиваемся со вторым методом добычи сертификатов в цепочке – файл сертификатов формата pkcs7.
Бывают случаи, когда цепочка сертификатов не может быть построена и она обрывается на пути. Типичный пример такого обрыва (когда цепочка не может быть построена до корня с использованием любого вышеуказанного метода) можно посмотреть на сайте БиЛайна: https://trust.beeline.ru
если посмотреть поле AIA этого сертификата, то мы увидим там 2 пути до CA, который издал этот сертификат. Но оба эти пути нерабочие совсем (кстати говоря, пути в CDP там тоже нерабочие. Причём, во всех сертификатах! Вот такой он БиЛайн 🙂 ). Но цепочка сертификатов в этом случае всё равно построилась за счёт сертификатов в pkcs7 формате. Хотя корневой сертификат в этом pkcs7 просто отсутствует, поэтому мы даже не можем собрать корневой сертификат. Неработающие CDP/AIA — ещё одна из наиболее частых ошибок реализации инфраструктуры PKI, в результате которой по сути PKI является неработоспособной.
Оффтоп: если на этой странице нажать Продолжить, то на новой странице будет ссылка на корневой сертификат, а так же на CRL. CRL БиЛайна доставил очень сильно. Вы посмотрите срок годности этого CRL 🙂
Проверка соответствия сертификатов внутри построенной цепочки
Однако, это только половина дела. Мы просто построили цепочку сертификатов, но не более того. Поскольку сертификаты могут быть скачаны в pkcs7 формате, а по ссылкам AIA просто подменить сертификаты, chaining engine делает полнуюю проверку доверия каждого сертификата в цепочке, чтобы исключить возможность подмены сертификатов, а так же достраивает цепочку (если этого не удалось сделать с помощью AIA и pkcs7 используя локальное хранилище сертификатов). Соответствие сертификатов внутри цепочки может происходить по нескольким правилам (в порядке приоритета):
- Exact Match
- Key Match
- Name MAtch
Для этого chaining engine использует следующие поля сертификатов:
- Authority Key Identfier (AKI) — может содержать комбинацию поля Subject и Serial Number сертификата вышестоящего CA или хеш открытого ключа вышестоящего CA (но бывает, что это поле совсем отсутствует).
- Issuer – данное поле используется только если AKI отсутствует в сертификате и это поле должно быть эквивалентно полю Subject вышестоящего CA. По этому полю определяется имя CA, котороый издал этот сертификат.
- Subject в сертификате вышестоящего CA. Данное поле должно быть эквивалентно полю Issuer в издаваемых сертификатах.
- Serial Number сертификата вышестоящего CA.
- Subject Key Identifier (SKI) — может содержать комбинацию поля Subject и Serial Number текущего сертификата или хеш открытого ключа текущего сертификата.
Exact match
Данный метод определения правильности построения цепочки является наиболее точным и такая цепочка почти никогда не будет заканчиваться более чем одним корневым сертификатом, поскольку требует совпадения 2-х полей вышестоящего сертификата – Subject и серийного номера с полем AKI проверяемого сертификата. Давайте посмотрим пример такой проверки в сертификате сайта https://cert.startcom.org. Поле AKI содержит следующую информацию:
KeyID=a1 e1 9e 45 25 79 4d 06 d9 02 17 92 82 d5 30 89 72 25 14 a0
Certificate Issuer:
Directory Address:
CN=StartCom Certification Authority
OU=Secure Digital Certificate Signing
O=StartCom Ltd.
C=IL
Certificate SerialNumber=17
Поле KeyID не используется. Здесь мы видим сведения о поле Subject и серийный номер вышестоящего CA. Если посмотреть сертификат этого CA, то его серийный номер и поле Subject будут идентичными тем, которые записаны в поле AKI издаваемых ими сертификатов. Используя эти данные chaining engine может найти нужный сертификат в локальном хранилище (если такой сертификат там есть), для восполнения недостающих звеньев цепочки. Если же будет обнаружено хоть одно несоответствие между этими полями, то цепочка мгновенно обрывается и любому сертификату в этой цепочке (начиная от сертификата с несоответствующими полями и вниз до конечного сертификата выданного потребителю) будет отказано в доверии.
Key Match
Это наиболее распространённый тип проверки цепочки, т.к. зачастую поле AKI у сертификатов содержит только KeyID, который является лишь хешом открытого ключа вышестоящего CA. Например сертификат с https://www.dreamspark.com:
KeyID=14 55 c4 39 e0 3d 2e d1 55 2e 48 96 b0 d8 7e 14 22 06 93 bc
Этот хеш должен быть идентичным хешу, который записан в поле Subject Key Identifier вышестоящего CA. В этом вы можете убедиться просмотрев сертификат CA, который выдал сертификат для dreamspark.com. В случае несоответствия этого поля, любому сертификату вниз по цепочке будет отказано.
Заметка: при этом, возможна достаточно интересная ситуация, когда цепочка может заканчиваться несколькими корнями. Это может происходить если корневой сертификат CA был обновлён с использованием текущей пары открытого и закрытого ключа. Поскольку KeyID — всего лишь хеш открытого ключа, то при смене корневого сертификата CA, хеш не изменится и, следовательно, chaining engine может рандомно строить цепочку до старого или до нового корневого сертификата CA.
Name match
Но поле AKI не обязательно должно присутствовать в сертификате. Его может не быть совсем и тогда остаётся только один способ проверки целостности цепочки — сравнение поля Issuer текущего сертификата и поля Subject вышестоящего сертификата. Это самый крайний и наименее надёжный (хотя это достаточно относительно) метод проверки цепочки. Так же, как и предыдущий пример, данный метод может заканчиваться несколькими корневыми сертификатами, если сертификат CA был обновлён с использованием текущей пары открытого и закрытого ключей. Но этого не произойдёт, если при обновлении сертификата CA будут использоваться новая пара ключей. Хоть хеши и серийные номера издающих CA не проверяются, то подделка сертификатов в вашем случае закончится провалом. А об этом читайте заключительный раздел.
Не забываем про подписи
На самом деле может показаться, что обмануть chaining engine достаточно легко — надо лишь подсунуть нужные поддельные сертификаты. Но в действительности это не так. Помимо всего прочего следует помнить, что каждый сертификат подписан цифровой подписью издающего CA. Если вы ещё не знаете, что такое цифровая подпись, то пора бы и узнать. Когда CA составляет сертификат, то он высчитывает конечный хеш (с использованием алгоритма указанного в поле Signature algorithm) этого сертификата и шифрует его своим закрытым ключом и пристыковывает подпись к сертификату. При проверке сертификата chaining engine удаляет цифровую подпись из сертификата и подсчитывает сам хеш файла сертификата. Далее берёт открытый ключ у издающего CA и сравнивает полученный хеш с тем, что содержится в подписи. Следовательно, если вам удастся обмануть все 3 метода проверки цепочки путём подмены сертификатов, то вы сломаетесь на проверке цифровой подписи, т.к. здесь уже задействуется закрытый ключ легального CA. Вот как это может выглядеть:
На картинке слева вы видите, что chaining engine построил цепочку до доверенного корня, поскольку мой сертификат содержал нужные поля для работы метода Name match. Но сертификат был выдан не тем CA, который виден в цепочке, а поддельным CA. Хоть мой поддельный CA внешне не отличим от легитимного CA, но у него нету самого важного — правильного закрытого ключа, чтобы подписать сертификат. Ведь при проверке подписи используется открытый ключ легитимного CA и, следовательно, подпись не может быть проверена.
Написал очень много страшных букв даже без надежды, что кто-то с первого раза поймёт о чём тут шёл разговор. Но поверьте, это достаточно полезное знание, чтобы уметь отыскивать и разрешать проблемы с построением цепочек сертификатов.
Проверка цепочки сертификатов эцп на linux
К моменту написания статьи, была использована сертифицированная версия ПО «КриптоПро» «4.0 R3».
1) Загрузка архива с сертифицированной версией ПО «КриптоПро» «4.0 R3»:
2) Открыть «Терминал Fly» (alt+T)
tar -zxf linux-amd64_deb.tgz
cd /linux-amd64_deb
sudo ./install_gui.sh
- 1 Описание необходимых пакетов КриптоПро
- 2 Прописывание путей к исполняемым файлам
- 3 Установка дополнительных пакетов с модулем поддержки для токена
- 3.1 Браузер Chrome
- 3.2 Альтернативный метод получения тестового сертификата
- 4.1 Проверка работы контейнера
- 4.2 Копирование контейнера
- 4.3 4 категории сертификатов
- 4.4 Установка
- 4.5 Просмотр
- 4.6 Удаление
- 4.7 Экспорт сертификатов на другую машину
- 4.8 Проверка цепочки сертификатов
- 4.9 Подпись файлов (присоединённая)
- 6.1 Установка и настройка
Описание необходимых пакетов КриптоПро
dpkg -l | grep cprocsp
Прописывание путей к исполняемым файлам
Установка дополнительных пакетов с модулем поддержки для токена
библиотека libccid, libgost-astra , пакеты pcscd, libpcsclite1
После установки пакетов с модулем поддержки токена следует перезагрузить службу pcscd:
Проверить срок истечения лицензии можно командой:
Для установки другой лицензии следует выполнить команду :
a)Установить пакет alien , необходимый для конвертации rpm-пакетов в deb-формат
б) Загрузить архив cades_linux_amd64.zip
в) Распаковать архив cades_linux_amd64.zip перейти в каталог с распакованными файлами и выполнить команды:
alien -dc cprocsp-pki-2.0.0-amd64-plugin.rpm
dpkg -i cprocsp-pki-cades_2.0.0-2_amd64.deb cprocsp-pki-plugin_2.0.0-2_amd64.deb
Браузер Chrome
д) Тестовый сайт предложит Вам подписать документ и выбрать нужный Вам сертификат.
Открываем эмулятор терминала и выполняем от root`а:
Альтернативный метод получения тестового сертификата
2) Для получение сертификата, перейдите в раздел Сформировать ключи и отправить запрос на сертификат
6) Тестовый УЦ КриптоПро уведомит нас о том, что сертификат выдан
7) Пройти по ссылке и установить сертификат, введя пароль контейнера.
Для запроса, получения и установки сертификата с тестового УЦ «КриптоПро» — можно, воспользоваться одной командой:cryptcp -creatcert -rdn ’E=email@astralinux.ru, CN=имя_сертификата’ -cont ’\\.\HDIMAGE\имя_контейнера’ -hashalg 1.2.643.7.1.1.2.2
Чтобы узнать модель подключенного токена, следует ввести команду:
После чего система выдаст информацию о подключенном устройстве:
Проверить наличие носителей с контейнерами можно с помощью команды:/opt/cprocsp/bin/amd64/csptest -keyset -verifycontext -enum -unique
В этом случае будет выведен список носителей с контейнерами в следующем формате:
Где \\.\HDIMAGE — локальный носитель, \\.\HDIMAGE\TestCont123 — название контейнера, \\.\Aktiv Rutoken ECP 00 00 — название носителя (токена).
Создание локального носителя
sudo /opt/cprocsp/sbin/amd64/cpconfig -hardware reader -add HDIMAGE store
Для создания контейнера в носителе HDIMAGE следует воспользоваться командой:
Для добавления контейнера в носитель токена следует воспользоваться командой:
В 5-ой версии КриптоПРО CSP v.5.0, для создания контейнера, имя носителя можно не указывать, а выбрать в интерактивном gtk-диалоге:
Для просмотра подробной информации о контейнерах воспользуйтесь командой:
Проверка работы контейнера
/opt/cprocsp/bin/amd64/csptestf -keyset -container ИМЯ -check
Для удаления контейнера следует воспользоваться командой:
Копирование контейнера
csptestf -keycopy -contsrc ’\\.\HDIMAGE\Контейнер_оригинал’ -contdest ’\\.\Aktiv Rutoken ECP 00 00\Контейнер_копия’
Для создания запроса на получение сертификата для контейнера ’\\.\Aktiv Rutoken ECP 00 00\Shuhrat’ , воспользуемся командой:
Для примера можно воспользоваться тестовым удостоверяющим центром КриптоПро. Нам нужен пункт « Отправить готовый запрос PKCS#10 или PKCS#7 в кодировке Base64 « . На следующей странице в поле «Сохраненный запрос» вставляем содержимое файла cert.req и нажимаем кнопку «Выдать».
/opt/cprocsp/bin/amd64/certmgr -inst -file имя_полученного_сертификата.cer -cont ’\\.\Aktiv Rutoken ECP 00 00\Shuhrat’
/opt/cprocsp/bin/amd64/csptest -keys -cont ’\\.\Aktiv Rutoken ECP 00 00\Shuhrat’ -keyt exchange -impcert имя_полученного_сертификата.cer
4 категории сертификатов
* личные сертификаты (ставятся в хранилище umy, где u = User, my — имя хранилища) — как правило для них есть закрытый ключ (и они требуют особой установки, чтобы в хранилище появилась ссылка на этот закрытый ключ). В результате с их использованием можно, например, подписать файл.
* промежуточные сертификаты — появляются, когда есть промежуточные УЦ (головной -> промежуточный -> пользовательский). Прямое доверие к ним не требуется (ставятся в uca, также администратор может поставить их в mca). В это же хранилище ставятся CRL-и. Обычно точки получения промежуточных сертификатов и CRL-ей правильно указаны в пользовательских сертификатах, поэтому они автоматом выкачиваются и попадают в хранилище ucache. В общем про них можно ничего особо не знать и ничего не делать.
Установка
Просмотр
Удаление
certmgr -delete 1 (номер сертификата)
Экспорт сертификатов на другую машину
Поэтому эти ключи переносятся просто: создаем архив и переносим на нужную машину в тот же каталог.
/opt/cprocsp/bin/amd64/certmgr -export -dest cert.cer
И как обычно, связываем сертификат и закрытый ключ:
Если закрытый ключ и сертификат не подходят друг к другу, будет выведена ошибка:
Проверка цепочки сертификатов
/opt/cprocsp/bin/amd64/cryptcp -copycert -dn CN=Имя_вашего_сертификата -df /temp/сертификат.cer
В нашем примере, из логов можно сделать вывод, что нам надо установить сертификат УЦ МО с CN=Министерство обороны Российской Федерации:
Для того, чтобы убедиться в устранении ошибки, можно повторно в режиме отладки запустить команду. При правильно установленной цепочке сертификатов, статус у сертификата будет = CERT_TRUST_NO_ERROR
* attached (присоединённая), тогда результирующий файл — это CMS-сообщение, внутрь которого упакованы данные и атрубуты (типа подписи). Формат сообщения соответствует международному стандарту, поэтому извлекать данные оттуда можно любыми утилитами, типа cryptcp / csptest / openssl / certutil (на windows).
Подпись файлов (присоединённая)
Проверка подписи в файле
Для проверки прикрепленной подписи выполните:
использовать ключ -verall — он понимает, что надо найти всех подписавших и ищет в том числе в сообщении:
указать в качестве хранилища сертификатов само сообщение (ключ -f):
Чтобы извлечь файл, необходимо указать его имя в конце команды проверки подписи:
её можно запустить из консоли:
Для доступа к Госуслугам был использован Рутокен ЭЦП 2, «КриптоПро 4.0 R3», IFCP-plugin 3.0.3
Список сайтов ЕСИА использующий IFCP-plugin
Установка и настройка
1) Скачать Рутокен плагин с оффициального сайта: https://www.rutoken.ru/support/download/rutoken-plugin/
2) Скачать IFCP-плагин с сайта ГосУслуг в формате «deb» — файл IFCPlugin-x86_64.deb ; https://ds-plugin.gosuslugi.ru/plugin/upload/Index.spr
3) Установить плагин:
Для браузера Chromium :sudo ln -s /etc/opt/chrome/native-messaging-hosts/ru.rtlabs.ifcplugin.json /etc/chromium/native-messaging-hosts
sudo ln -s /opt/cprocsp/lib/amd64/libcppkcs11.so.4.0.4 /usr/lib/mozilla/plugins/lib/libcppkcs11.so
4) Добавить в конфигурационный файл IFCplugin /etc/ifc.cfg :
Для этого в конфигурационный файл /etc/opt/cprocsp/config64.ini следует в разделе PKCS11 добавить:
tail -f /var/log/ifc/engine_logs/engine.log
Перейдя на сайт zakupki.gov.ru, следует кликнуть мышкой по иконке «Личного кабинета» и выбрать необходимый метод входа:
После чего система уведомит Вас, о том что для работы необходимо установить и настроить ПО «КриптоПро CSP»:
Нажав кнопку «Продолжить работу с сайтом», система предложит выбрать нужный сертификат:
Выбрать сертификат и ввести pin-код.
1) Для авторизации на сайте Минфина России, следует перейти на страницу авторизации
2) Скачать и установить корнейвой сертификат УЦ «Минфина России:
3) Кликнуть по ссылке Вход по сертификату и выбрать нужный сертификат:
4) После чего система попросит Вас ввести пароль:
В соответствии с принятым в 2014 году порядком перехода на ГОСТ Р 34.10-2012 до 1 января 2019 года попытка использования ГОСТ Р 34.10-2001 (кроме проверки подписи) на всех выпущенных к настоящему моменту сертифицированных версиях КриптоПро CSP 3.9, 4.0 и КриптоПро JCP 2.0 с 1 января 2019 года вызовет ошибку/предупреждение (в зависимости от продукта и режима работы), которые могут привести к неработоспособности автоматических/автоматизированных систем при использовании ими ключей ГОСТ Р 34.10-2001. В случае если ваша система использует ключи ГОСТ Р 34.10-2001, просим принять во внимание инструкцию.
[Parameters]
warning_time_gen_2001=ll:9223372036854775807
Таблица поддерживаемых устройств Крипто-Про CSP
Диагностический архив для обращения в тех. поддержку
Для создания диагностического архива, можно воспользоваться следующей командой:
Как просмотреть содержимое ключей и сертификатов SSL
Мы можем подробно изучить содержимое всех созданных в OpenSSL файлов, а также при необходимости конвертировать их в другие форматы.
В следующих командах используются тестовые файлы со следующими именами:
- rootCA.key — ключ CA
- rootCA.crt — сертификат CA
- mydomain.com.key — ключ сервера
- mydomain.com.csr — запрос за подпись сертификата сайта
- mydomain.com.crt — сертификат сайта
Обратите внимание на расширения файлов — они могут отличаться от тех, которые используются в других инструкциях. Например, вместо .key и .crt может использоваться расширение .pem. Расширение файла не имеет особого значения кроме как служить подсказкой пользователю, что именно находится в этом файле. Это же самое касается и имён файлов — вы можете выбирать любые имена.
Все эти файлы являются текстовыми:
Там мы увидим примерно следующее:
Если вам эти строки кажутся знакомыми на кодировку Base64, то вы совершенно правы — это она и есть. (Смотрите также «Как быстро узнать и преобразовать кодировку»).
Этот формат, называемый форматом PEM, расшифровывается как Privacy Enhanced Mail.
PEM — это текстовое представление реального двоичного ключа или сертификата в формате DER. Представляет собой двоичного формата DER в кодировке base64 и с дополнительными строками «——BEGIN PRIVATE KEY——», «——BEGIN CERTIFICATE——» и другими в начале файла и строками «——END PRIVATE KEY——», «——END CERTIFICATE——» в конце файла.
Мы можем хранить двоичную версию файла только с кодировкой DER, но наиболее распространенным способом является версия PEM.
Вы можете увидеть структуру приватного следующей командой:
Опция -in ИМЯ_ФАЙЛА указывает имя файла ввода для чтения ключа или стандартный ввод, если эта опция не указана. Если ключ зашифрован, будет запрошен пароль.
Опция -text печатает различные компоненты открытого или закрытого ключа в виде простого текста в дополнение к закодированной версии.
Любой формат ключа на самом деле является контейнером для набора длинных чисел. Все остальные данные можно считать «шумом».
Закрытый ключ содержит: модуль (modulus), частный показатель (privateExponent), открытый показатель (publicExponent), простое число 1 (prime1), простое число 2 (prime2), показатель степени 1 (exponent1), показатель степени 2 (exponent2) и коэффициент (coefficient).
Открытый ключ содержит только модуль (modulus) и открытый показатель (publicExponent).
Вы можете из влечь из файла ключей публичный ключ:
По умолчанию выводится закрытый ключ: с опцией -pubout вместо него будет выведен открытый ключ. Эта опция устанавливается автоматически, если ввод является открытым ключом.
Следующая команда покажет информацию о публичном ключе:
По умолчанию из входного файла считывается закрытый ключ. Используемая в предыдущей команде опция -pubin делает так, что вместо приватного ключа читается открытый ключ.
Можно также добавить опцию -noout — с ней будет выведена та же самая информация, но не будет показана кодированная версия ключа.
С такими же опциями, но уже используя команду req, можно изучить содержимое запроса на подпись сертификата:
При создании SSL сертификата мы создали две пары ключей (корневые и для домена), то есть это файлы rootCA.key и mydomain.com.key, но по своей технической сути они идентичны.
Что касается сертификатов, которых у нас тоже два (rootCA.crt и mydomain.com.crt), то по своей природе они не являются одинаковыми: корневой сертификат является самоподписанным, а сертификат домена подписан приватным корневым ключом.
Информацию о содержимом сертификатов можно посмотреть командой x509 (остальные опции нам уже знакомы):
Самоподписанные сертификаты обычно содержат только самые основные данные сертификатов, как показано в предыдущем примере. Для сравнения, сертификаты, выданные общедоступными центрами сертификации, гораздо интереснее, поскольку они содержат ряд дополнительных полей (с помощью механизма расширений X.509).
Сертификат (цепочку сертификатов) любого сайта вы можете получить следующей командой (замените w-e-b.site на интересующий вас сайт):
Вы увидите сертификаты (один или несколько), найдите по полю CN тот, который вас интересует, например, сертификат домена w-e-b.site:
И скопируйте содержимое начиная с ——BEGIN CERTIFICATE—— и заканчивая ——END CERTIFICATE——. Затем сохраните это в файл.
Вы также можете сохранить сертификат центра сертификации и изучить его:
К примеру, сертификат сайта w-e-b.site я сохранил в файл w-e-b.site.crt, для просмотра информации о нём:
Issuer указывает на организацию, которая выдала (подписала) сертификат:
Validity — срок действия сертификата:
Subject: CN — домен (IP адрес) для которого предназначен сертификат:
Поддомены в группе X509v3 extensions → X509v3 Subject Alternative Name (подробности чуть позже):
Теперь бегло рассмотрим расширения X.509.
Расширение Basic Constraints используется для маркировки сертификатов как принадлежащих ЦС, давая им возможность подписывать другие сертификаты. В сертификатах, отличных от CA, это расширение будет либо пропущено, либо будет установлено значение CA, равное FALSE. Это расширение является критическим, что означает, что все программные сертификаты должны понимать его значение.
Расширения Key Usage (KU) и Extended Key Usage (EKU) ограничивают возможности использования сертификата. Если эти расширения присутствуют, то разрешены только перечисленные варианты использования. Если расширения отсутствуют, ограничений на использование нет. То, что вы видите в этом примере, типично для сертификата веб-сервера, который, например, не позволяет подписывать код:
Расширение CRL Distribution Points перечисляет адреса, по которым можно найти информацию о списке отзыва сертификатов (CRL) ЦС. Эта информация важна в случаях, когда сертификаты необходимо отозвать. CRL — это подписанные CA списки отозванных сертификатов, публикуемые через регулярные промежутки времени (например, семь дней).
Примечание: возможно, вы заметили, что местоположение CRL не использует защищённый сервер, и вам может быть интересно, является ли ссылка небезопасной. Не является. Поскольку каждый CRL подписан центром сертификации, который его выпустил, браузеры могут проверить его целостность. В том же случае, если бы CRL были доступны по TLS (адрес включал бы в себя протокол HTTPS), то браузеры могут столкнуться с проблемой «курицы и яйца», в которой они хотят проверить статус отзыва сертификата, используемого сервером, доставляющим сам CRL!
Расширение Certificate Policies используется для указания политики, в соответствии с которой был выпущен сертификат. Например, именно здесь можно найти индикаторы расширенной проверки (EV). Индикаторы представлены в форме уникальных идентификаторов объектов (OID) и являются уникальными для выдающего ЦС. Кроме того, это расширение часто содержит один или несколько пунктов CPS, которые обычно являются веб-страницами или документами PDF.
Расширение Authority Information Access (AIA) обычно содержит две важные части информации. Во-первых, он перечисляет адрес ответчика CA OCSP, который можно использовать для проверки отзыва сертификатов в режиме реального времени. Расширение также может содержать ссылку, где находится сертификат эмитента (следующий сертификат в цепочке). В наши дни серверные сертификаты редко подписываются непосредственно доверенными корневыми сертификатами, а это означает, что пользователи должны включать в свою конфигурацию один или несколько промежуточных сертификатов. Ошибки легко сделать, и сертификаты будут признаны недействительными. Некоторые клиенты (например, Internet Explorer) будут использовать информацию, представленную в этом расширении для исправления неполной цепочки сертификатов, но многие клиенты этого не сделают.
Расширения Subject Key Identifier и Authority Key Identifier устанавливают уникальные идентификаторы ключа субъекта и ключа авторизации соответственно. Значение, указанное в расширении Authority Key Identifier сертификата, должно соответствовать значению, указанному в расширении Subject Key Identifier в выдающем сертификате. Эта информация очень полезна в процессе построения пути сертификации, когда клиент пытается найти все возможные пути от конечного (серверного) сертификата до доверенного корня. Центры сертификации часто используют один закрытый ключ с несколькими сертификатами, и это поле позволяет программному обеспечению надёжно определять, какой сертификат может быть сопоставлен с каким ключом. В реальном мире многие цепочки сертификатов, предоставляемые серверами, недействительны, но этот факт часто остаётся незамеченным, поскольку браузеры могут находить альтернативные пути доверия.
Наконец, расширение Subject Alternative Name используется для перечисления всех имен хостов, для которых действителен сертификат. Это расширение раньше было необязательным; если его нет, клиенты возвращаются к использованию информации, представленной в Common Name (CN), которое является частью поля «Subject». Если расширение присутствует, то содержимое поля CN игнорируется во время проверки.
Рассмотрим опции команды x509, которые позволяют извлечь разнообразную информацию из сертификатов.
Чтобы показать издателя сертификата используйте опцию -issuer:
Опция -fingerprint вычисляет и выводит дайджест DER-кодированной версии всего сертификата. Это обычно называют «отпечатком». Из-за характера дайджестов сообщений, отпечаток сертификата является уникальным для этого сертификата, и два сертификата с одинаковым отпечатком могут считаться одинаковыми. Для сертификатов обычно не нужно сверять сертификаты по отпечаткам, но это имеет смысл при использовании самоподписанных сертификатов (например, получении сертификата для VNC сессии, когда нет другого способа проверить, что сертификат не был подменён при пересылке). В этом случае можно сверить отпечаток сертификата, например, по телефону или электронной почте.
Для показа отпечатка сертификата:
Чтобы вывести сертификат в виде строки символов в стиле C — char, используйте опцию -C:
Чтобы вывести расширения сертификата в текстовой форме, используйте опцию -ext. Несколько расширений можно перечислить через запятую, например "subjectAltName,subjectKeyIdentifier". Чтобы посмотреть весь список расширений:
Пример команды для вывода альтернативных имён в домене:
Пример информации об альтернативных именах домена:
Для вывода почтовых адресов, содержащихся в сертификате, используйте опцию -email. Адреса электронной почты могут отсутствовать в сертификате.
Для вывода адресов респондентов OCSP, если они присутствуют в сертификате, укажите опцию -ocsp_uri:
Для показа дат из сертификата имеются следующие опции:
- -startdate: Распечатывает дату начала сертификата, то есть дату notBefore (не ранее).
- -enddate: Распечатывает дату истечения срока действия сертификата, то есть дату notAfter (не позднее).
- -dates: Распечатывает даты начала и окончания срока действия сертификата.
Для вывода имени subject укажите опцию -subject:
Чтобы показать имя subject сертификата в форме RFC2253 используйте сочетание опций -subject -nameopt RFC2253:
Пример вывода имени subject сертификата в форме схемы на терминале, поддерживающем UTF8:
Опция -serial выводит серийный номер:
Чтобы извлечь публичный ключ из сертификата используйте опцию -pubkey:
Для глубокого понимания OpenSSL смотрите также полное руководство: «OpenSSL: принципы работы, создание сертификатов, аудит».