Как посмотреть содержимое jks linux

Обновлено: 07.07.2024

Гибкий keytool и openssl для генерации сертификатов, применения tomcat и nginx

Справочник статей

Вообще говоря, основное программное обеспечение Web-сервисов обычно основано на двух основных криптографических библиотеках: OpenSSL и Java.

Подписание (шифрование) данных - наша самая распространенная операция безопасности в сети. Подпись имеет двойную функцию: первая функция - обеспечить целостность данных, доказать, что данные не подделаны, и что они не были подделаны во время передачи. Вторая функция - не дать издателю данных отрицать, что он или она опубликовали данные.

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

Итак, как определить, что открытый ключ должен принадлежать издателю? Для этого требуется сертификат. Сертификат выдается органом, содержание которого содержит личность владельца сертификата и его открытый ключ, и подписывается органом с использованием его закрытого ключа. Издатель информации раскрывает свой открытый ключ, выдавая сертификат в сети. Сертификат подписан уполномоченным органом по сертификации. Центр сертификации также раскрывает свой открытый ключ, выдав свой сертификат. Сертификат органа по сертификации выдается более авторитетным Центр сертификации подписывает сертификат, образуя цепочку сертификатов. Сертификат в верхней части цепочки сертификатов называется корневым сертификатом, а корневой сертификат является только самоподписанным. Короче говоря, для подписи и аутентификации контента, распространяемого в Интернете, обязательно будет использоваться сертификат. Что касается стандартов, то сертификат следует, самым популярным является X.509

Преобразование формата сертификата происходит следующим образом:

Примечание. Служба сертификатов Alibaba Cloud Shield равномерно использует файлы цифровых сертификатов в формате PEM.

воли JKS Форматировать сертификат в PFX Формат ( jks->pfx )

Вы можете использовать встроенный JDK Keytool Инструмент для преобразования файла сертификата формата JKS в формат PFX.
Например, вы можете выполнить следующую команду, чтобы преобразовать файл сертификата server.jks в файл сертификата server.pfx:

Вы можете использовать встроенный JDK Keytool Инструмент, PFX Формат файла сертификата в JKS Формат.
Например, вы можете выполнить следующую команду для server.pfx Преобразовать файл сертификата в s erver.jks Файл сертификата:

воли PEM/KEY/CRT Формат сертификата для PFX формат

Вы можете использовать инструменты OpenSSL для KEY Формат файла ключа и CRT Отформатировать файл открытого ключа в PFX Формат файла сертификата.
Например, скопируйте файл ключа формата KEY (server.key) и файл открытого ключа формата CRT (server.crt) в каталог установки инструмента OpenSSL и используйте инструмент OpenSSL, чтобы выполнить следующую команду для Преобразуйте сертификат в файл сертификата server.pfx:

Можно использовать OpenSSL Инструмент, PFX Формат файла сертификата в KEY Формат файла ключа и CRT Формат файла открытого ключа.
Например, скопируйте PFX Скопируйте файл сертификата формата в OpenSSL Установочный каталог, используйте инструмент OpenSSL, чтобы выполнить следующую команду для преобразования сертификата в server.pem Файл сертификата, файл ключа формата KEY ( server.key ) И файл открытого ключа в формате CRT ( server.crt ）：

Формат сертификата

Вы можете просто отличить файл сертификата с расширением суффикса, используя следующие методы:

*.DER или *.CER Файл: такой файл сертификата находится в двоичном формате и содержит только информацию о сертификате, а не закрытый ключ.
*.CRT Файл: такой файл сертификата может быть в двоичном формате или в текстовом формате, как правило, в текстовом формате. *.DER и *.CER Файл сертификата такой же.
*.PEM Файлы. Такие файлы сертификатов обычно имеют текстовый формат и могут содержать сертификаты, закрытые ключи или оба. *.PEM Если файл содержит только закрытый ключ, он обычно заменяется файлом * .KEY.
*.PFX или *.P12 Файл: такой файл сертификата находится в двоичном формате и содержит как сертификат, так и закрытый ключ, и обычно защищен паролем.
Вы также можете использовать Блокнот для непосредственного открытия файла сертификата. Если отображаются обычные буквенно-цифровые символы, например:

Затем файл сертификата в текстовом формате.

Если это существует ——BEGIN CERTIFICATE—— Тогда это файл сертификата.
, если он существует —–BEGIN RSA PRIVATE KEY—– , То это файл с закрытым ключом.

Он в основном делится на две категории: одна - это формат файла хранилища ключей, а другая - формат файла сертификата;

Формат файла хранилища ключей Keystore 】

Формат файла сертификата [ Certificate 】

jks - это формат закрытого ключа сертификата, поддерживаемый инструментом сертификатов keytools JAVA.
pfx - это формат закрытого ключа, поддерживаемый Microsoft.
cer - это открытый ключ сертификата.
Если вы хотите сделать резервную копию сертификата лично, не забудьте создать резервную копию в формате jks или pfx, иначе вы не сможете восстановить его.
Проще говоря, cer - это адрес вашего домашнего адреса электронной почты. Вы можете дать этот адрес многим людям и разрешить им отправлять почту на него.
pfx или jks - это ключ к вашему почтовому ящику. У других это есть и они могут притвориться, что идут в ваш почтовый ящик, чтобы прочитать письмо. Вы не сможете открыть почтовый ящик, если потеряете его.

Keytool Является инструментом управления сертификатами данных Java, Keytool Ключ (ключ) и сертификат ( certificates ) Существует в файле с именем keystore keystore Есть два вида данных:
Ключевой объект, секретный ключ или закрытый ключ и парный открытый ключ (с использованием асимметричного шифрования)
записи доверенных сертификатов - содержит только открытый ключ
Сертификат, который мы часто называем, является открытым ключом, упомянутым выше, и открытый ключ является общедоступным для других. Это часто называют сертификатом передачи.

команда справки keytool

Результат выглядит следующим образом

Просмотр справки команды

Основной формат

keytool использует файл хранилища ключей для хранения ключей и сертификатов, которые могут включать закрытые ключи и доверенные сертификаты;
Файл хранилища ключей в основном используется JKS Формат (также может поддерживать другие форматы), с хранилищем ключей; Хранение закрытого ключа также имеет независимый пароль;
пройдено keytool -genkeypair -storetype format обозначение

Другие включают jceks, jks, dks, pkcs11, pkcs12.

Разница между test.keystore и test.jks

Это эквивалентно следующему и оба являются файлами ключей формата jks.

Tomcat поддерживает сертификаты формата JKS. Начиная с Tomcat7, он также поддерживает сертификаты формата PFX. Один из двух форматов сертификатов является необязательным.

Генерация закрытого ключа и сертификата

storepass : пароль хранилища файлов пароль хранилища
keypass : Пароль шифрования закрытого ключа
alias : Псевдоним объекта (включая закрытый ключ сертификата)
keyalt : Использовать алгоритм открытого ключа, по умолчанию используется DSA и необязательный алгоритм RSA
keysize: длина ключа (алгоритм по умолчанию, соответствующий алгоритму DSA, это sha1withDSA, который не поддерживает длину 2048, и в это время должен быть указан RSA)
validity : Срок действия (не менее одного года, вы не хотите часто обновлять сертификат)
keystore : Укажите файл хранилища ключей

распространение
Если вы хотите создать файл ключей формата pkcs12

Посмотреть детали сертификата

Результат выглядит следующим образом

плюс -v Вариант для более подробной информации keytool -list -v -keystore dongli.jks -storepass 123456

JKS конвертировать в формат pkcs12 сертификат

На самом деле, приведенная выше командная строка уже предлагает

Экспортный сертификат

Экспорт сертификата предназначен для экспорта файла открытого ключа.

Примечание: -alias dongli Почему псевдоним? Поскольку Dongli.jks может хранить несколько пар файлов открытого и закрытого ключей, они различаются псевдонимами, поэтому вот экспорт по обозначению псевдонима Псевдоним файла ключа является сертификатом открытого ключа dongli 。
Экспортируемый в данный момент сертификат имеет формат кодирования DER. -rfc Вариант, вывод pem Сертификат в закодированном формате

Импортный сертификат

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

Двойной клик dongli.cer Завершите операцию импорта
keytool -importcert -keystore client_trust.keystore -file dongli.cer -alias client_trust_server -storepass 123456 , Результат выглядит следующим образом

Установка сертификата

Установка сертификата PFX

Найдите файл server.xml в каталоге установки Tomcat. Обычно путь по умолчанию находится в папке conf. Найдите тег <Connection port = "8443" и добавьте следующие атрибуты:

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

Установка сертификата JKS

Если можно использовать только файлы формата pfx, используйте java jdk для преобразования сертификатов формата PFX в сертификаты формата JKS (обратите внимание, что среда Windows выполняется в каталоге% JAVA_HOME% / jdk / bin)

Найдите файл Server.xml в каталоге установки Tomcat. Обычно путь по умолчанию находится в папке conf. Найдите тег <Connection port = "8443" и добавьте следующие атрибуты:

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

Установка сертификата nginx до тех пор, пока файлы ключей и pem

Создайте каталог cert в каталоге установки Nginx и скопируйте все загруженные файлы в каталог cert. Если вы создали файл CSR при подаче заявки на сертификат, поместите соответствующий файл закрытого ключа в каталог cert и назовите его test.key
Откройте файл nginx.conf в каталоге conf в каталоге установки Nginx и найдите:

Изменено на ( Среди следующих атрибутов атрибуты, начинающиеся с ssl, напрямую связаны с конфигурацией сертификата. Пожалуйста, скопируйте или настройте другие атрибуты в соответствии с вашей реальной ситуацией. ) :

Защита данных в приложениях имеет важное значение, защита конфиденциальной информации — первостепенное. Одним из самых распространённых способов защиты информации во все времена является шифрование данных. Криптография, симметричное и асимметричное шифрование, ключи и сертификаты непосредственно связаны с данной задачей. Используемые для защиты информации ключи и сертификаты также нужно надежно защитить. Для этих целей используется keystore — хранилище сертификатов и ключей.

Java поддерживает несколько форматов хранилищ keystore :

• jks	— стандартный тип хранилища в виде файла с расширением jks ("java key storage"); устанавливается по умолчанию и, поэтому, применяется наиболее часто.
• jceks	— альтернативная реализация хранилища, которая использует более сильное шифрование на основе triple DES; можно обновить имеющееся jks-хранилище до jceks соответствующей командой утилиты keytool.
• pkcs12	— тип хранилища, предназначенный прежде всего для хранения или переноса закрытых ключей пользователя, сертификатов и пр.

Каждая запись в keystore имеет уникальный псевдоним (alias). Рекомендуется в keystore не использовать alias'ы, отличающиеся только регистром. В стандартной реализации каждый ключ в хранилище защищается паролем; кроме того, всё хранилище целиком может быть защищено отдельным паролем.

Стандартное хранилище доверенных CA-сертификатов (Certificate Authority) для Java приложений располагается в директории jre/lib/security/cacerts (пароль - changeit).

Информацию в хранилище можно разделить на две категории: ключевые записи (пары ключей private/public) и доверенные сертификаты. Ключевая запись, используемая для криптографических целей, включает идентификационные данные объекта и его закрытый ключ. Доверенный сертификат содержит идентификационные данные объекта и открытый ключ. Запись с доверенным сертификатом не может использоваться в тех случаях, где требуется закрытый ключ.

Чтобы отделить ключевые записи от сертификатов целесообразно использовать различные хранилища : один для собственных ключей, а другой — для доверенных сертификатов, включая сертификаты Центров сертификации (CA). Такой подход позволит реализовать разделение между собственными сертификатами и соответствующими закрытыми ключами, и доверенными сертификатами. Дополнительно можно обеспечить более высокую защиту для закрытых ключей в отдельном keystore с ограниченным доступом, а доверенные сертификаты оставить в более свободном доступе.

В конце статьи представлен Java пример просмотра содерживого хранилища ключей и сертификатов CertificateReader.

Утилита keytool

Для управления парами ключей (private/public), сертификатами и хранилищем keystore Java включает утилиту keytool, располагаемую в директории bin. Для запуска keytool можно использовать командную строку. Опции утилиты позволяют выполнять различные операции и получать определенные сведения. Так, чтобы получить информацию об утилите, можно просто выполнить команду keytool без опций :

Чтобы получить дополнительную справку о команде необходимо указать ее наименование и волшебное слово help. Не забывайте о дефисе '-' перед опциями :

Создание самоподписанного сертификата

Если заданного хранилища ключей (keystore.jks) не существует, то keytool создаст его. При выполнении команды keytool будет запрашивать некоторые необходимые данные : пароль хранилища, Distinguished Name и пароль закрытого ключа. Многие параметры используются со значениями по умолчанию. Так, например, алиас - mykey, хранилище - .keystore в домашней директории пользователя (HOMEPATH), алгоритм шифрвания - SHA1withDSA и пр.

Distinquished Name

Сертификат создается в формате X.509. В этом формате в качестве идентификатора владельца используется Distinquished Name или просто DN в формате X.500. Этот же формат идентификации объектов используется в LDAP-протоколе или в SNMP. Distinquished Name задается в виде разделенных через запятую атрибутов :

CN — common name (имя владельца);
OU — organizational unit or department/division (департамент/отдел);
O — organization name (наименование организации);
L — locality or city (город/местоположение);
ST — state or province;
C — country, two chars (страна).

Часть из атрибутов могут быть пропущены; в этом случае им будет присвоено значение Unknown.

Одним из важных атрибутов сертификата являются альтернативные имена SAN (SubjectAlternativeName). Подробности и пример внесения SAN в самоподписанный сертификат представлены на странице настройки конфигурации сервера Tomcat.

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

Новое хранилище было размещено в той же директории, где и располагается keytool.

Создание пары ключей

Для создания пары ключей необходимо использовать команду "-genkeypair". Следующая команда создаст пару ключей "keypair" в хранилище keystore.jks, где размещен созданный ранее сертификат.

Сертификат и закрытый ключ сохранены в виде новой keystore записи, идентифицированной псевдонимом "keypair". Открытый ключ обертывается в формат X.509 — это самоподписанный сертификат, который сохранен как одноэлементная цепочка сертификата.

Опции команды genkeypair

[-storepass storepass]
[-keypass keypass] — является паролем, используемым для защиты закрытого ключа
[-dname dname] — определяет отличительное имя в формате X.500, связанное с псевдонимом и используемое в качестве issuer и subject поля в самоподписанном сертификате
— определяет алгоритм, который будет использоваться, чтобы генерировать пару ключей
— определяет размер каждого ключа, который будет сгенерирован
— определяет алгоритм, который должен использоваться, чтобы подписать самоподписанный сертификат; алгоритм должен быть совместимым с keyalg
*
>

Создадим еще две пары ключей с псевдонимами "keypair1" и "keypair2", чтобы при просмотре содержимого хранилища (ниже) был небольшой список пар ключей :

Экспорт сертификата

Сертификат можно экспортировать из хранилища и предоставить его пользователям Вашей «подписанной» программы. Тогда пользователи могут занести Ваш сертификат в свое хранилище доверенных сертификатов. Для экспорта сертификата используется команда "exportcert". Следующий пример извлекает из хранилища сертификат в файл "parent.cer" :

Импорт сертификата

Чтобы импортировать сертификат в хранилище, нужно его сначала получить каким-либо образом. Не будем мудрить и извлечем сертификат с псевдонимом veriSignclass1g3ca из хранилища доверенных сертификатов jre\lib\security\cacerts (пароль хранилища changeit). То есть выполним команду экспорта сертификата с указанием соответствующего хранилища :

Экспорт сертификата из хранилища cacerts

Импорт сертификата в хранилище

Чтобы импортировать сертификат в хранилище keystore.jks необходимо использовать команду "importcert". Если в качестве опции указать "-trustcacerts", то сертификат импортируется в хранилище доверенных сертификатов, т.е. в jre\lib\security\cacerts. При выполнении команды импорта утилита keytool попросит ввести пароль хранилища :

Просмотр хранилища

Для чтения содержимого хранилища необходимо использовать команду "-list". В качестве опции "-keystore" можно указать путь к хранилищу. По умолчанию команда "-list" отображает цифровой отпечаток SHA1 сертификата. Следующий код позволяет просмотреть содержимое созданного хранилища, включающего сертификат и три пары ключей :

Опции команды list

Если при просмотре хранилища использовать опцию "-v", то информация о сертификате выводится с дополнительной информацией, включающей владельца, порядковый номер и т.д. При использовании опции "-rfc" содержание сертификата печатается согласно интернет-стандарта RFC-1421.

На странице описания SSL сертификата представлен результат выполнения команды просмотра хранилища keytool -list для опций '-v' и '-rfc'.

Полную англоязычную версию документации на keytool можно найти здесь.

Пример просмотра хранилища и сертификата

На скриншоте представлен пример CertificateReader, позволяющий просматривать хранилище ключей и сертификаты, а также извлекать информацию о сертификате.

Внутри сертификата хранится пара значений Distinqueshed Names. Один DN принадлежит владельцу сертификата, а второй DN указывает идентификатор цента сертификации (CA), подписавшего сертификат. В случае с самоподписанным (self-signed) сертификатом, оба эти DN указывают на владельца сертификата.

Листинг примера

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

В листинге примера представлены два метода : loadKeyStore, showCertificate. Первый метод позволяет выбрать хранилище сертификатов. Второй метод выполняет чтение сертификата и представление его параметров в интерфейсе. После листинга представлен скриншот, на котором выполнено чтение созданного сертификата.

Примечание : класс CertificateReader используется в качестве примера на странице цифровой подписи jar файлов

Рассмотренный на странице пример просмотра хранилища ключей и сертификатов можно скачать здесь (2.5 Кб).

Что такое Keytool ?

Keytool - это утилита командной строки, для управления ключами или сертификатами, а так же хранилищами ключей. Она позволяет пользователям управлять своими собственными парами открытых и закрытых ключей и связанными сертификатами для использования при аутентификации, где от пользователя, это требует конечный сервис или службах целостности данных и аутентификации с использованием цифровых подписей. Keytool также позволяет пользователям администрировать секретные ключи, используемые при симметричном шифровании/дешифровании (например, DES). Пользователь имеет возможность самостоятельно генерировать эти пары ключей, после чего он их сохраняет в хранилище ключей (keystore).

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

Закрытый и открытый ключи используются в асимметричном шифровании. Открытый ключ может иметь связанный сертификат. Сертификат - это цифровой документ, удостоверяющий личность человека, организации или устройства, претендующего на владение открытым ключом. Сертификат обычно имеет цифровую подпись проверяющей стороны в качестве доказательства (Удостоверяющие центры).

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

Все это многообразие используется приложениями Java для:

Keystore умеет работать в ситуации, когда в процессе работы необходима аутентификация сервера и клиента, где все реализовано с помощью SSL соединения, подразумевающее использование приватных ключей и сертификатов и так же keystore применяется при односторонней аутентификации, но только на стороне сервера. Java KeyStore представлен классом java.security.KeyStore. Поскольку KeyStore общедоступен, пользователи JDK могут создавать дополнительные приложения безопасности, которые его используют.

Типы поддерживаемых форматов в keystore

pkcs12 - это один из типов хранилища, заточенный чисто под хранение и перенос закрытых ключей пользователя, сертификатов.
jceks - сторонняя разработка хранилища, отличная более стойким шифрованием на основе triple DES. Позволяет обновлять существующие jks-хранилища до jceks
jks - это самый обычный, стандартный тип хранилища, в виде простого файла имеющего расширение jks ("java key storage"), устанавливается по умолчанию и, поэтому, применяется наиболее часто.

Реализации Keystore основаны на провайдере. Более конкретно, интерфейсы приложений, предоставляемые KeyStore, реализованы в терминах "Интерфейс поставщика услуг" (Service Provider Interface - SPI). То есть существует соответствующий абстрактный класс KeystoreSpi, также в пакете java.security, который определяет методы интерфейса поставщика услуг, которые должны реализовывать " провайдеры-поставщики". (Термин «поставщик» относится к пакету или набору пакетов, которые предоставляют конкретную реализацию подмножества служб, к которым может обращаться API безопасности Java.)

Приложения могут выбирать различные типы реализаций хранилища ключей от разных поставщиков, используя фабричный метод getInstance, предоставленный в классе KeyStore . Тип хранилища ключей определяет хранилище и формат данных информации хранилища ключей, а также алгоритмы, используемые для защиты личных ключей в хранилище ключей и целостности самого хранилища ключей. Реализации Keystore разных типов несовместимы. keytool работает с любой файловой реализацией хранилища ключей. (Он обрабатывает расположение хранилища ключей, которое ему передается в командной строке, как имя файла и преобразует его в FileInputStream, из которого он загружает информацию о хранилище ключей.) Инструменты jarsigner и policytool, с другой стороны, могут читать хранилище ключей из любого места, которое можно указать с помощью URL.

Если вы не укажете явно тип хранилища ключей, инструменты выберут реализацию хранилища ключей просто на основании значения свойства keystore.type, указанного в файле свойств безопасности. Файл свойств безопасности называется java.security и находится в каталоге свойств безопасности JDK, java.home/lib/security. Каждый инструмент получает значение keystore.type, а затем проверяет все установленные на данный момент провайдеры, пока не найдет того, который реализует хранилища ключей этого типа. Затем он использует реализацию хранилища ключей от этого провайдера.

Где хранится Keystore и что такое алиас

Где скачать утилиту keytool

Утилита Keytool входит в состав Java SDK (или JRE), в большинстве компьютеров в основном установлена JRE версия. В Windows данную утилиту можно найти по пути:

Тут все зависит от разрядности Java. На скриншоте отмечен файл Keytool.exe.

Как запустить утилиту Keytool в Windows

Сейчас я вам расскажу, как вы можете запускать утилиту Keytool в операционных системах Windows. Откройте командную строку в режиме администратора. Далее выполните вот такую команду, чтобы перейти в расположение утилиты:

cd C:\Program Files (x86)\Java\jre1.8.0_201\bin\ или cd C:\Program Files\Java\jre1.8.0_201\bin\ (Хочу отметить, что у вас будет своя версия отличная моей jre1.8.0_201)

Далее вы просто пишите keytool.exe и нажимаете Enter, в результате чего вы увидите справку по утилите.

Так же утилиту keytool.exe вы можете запускать и в оболочке PowerShell. Откройте ее от имени администратора или другого пользователя с аналогичными правами. Для этого в оболочке введите:

После чего введите .\keytool.exe

Команды и примеры использования утилиты Keytool

Получение справки по утилите Keytool. Первое, что я хочу, чтобы вы научились, это использование справки, чтобы представлять, как строится конструкция команд и их возможности. Вводим просто Keytool, у вас появятся основные ключи, которые покажут, что вы можете делать через утилиту

C:\Program Files (x86)\Java\jre1.8.0_201\bin>keytool.exe
Key and Certificate Management Tool

-certreq - генерация CSR запроса
-changealias - изменить запись алиаса
-delete - удалить запись
-exportcert - экспортировать сертификат
-genkeypair - генерация пары ключей
-genseckey - генерация секретного ключа
-gencert - генерация сертификата из csr запроса
-importcert - импорт сертификата или цепочки
-importpass - импорт паролей
-importkeystore - импорт одной или нескольких записей из другого Keystore
-keypasswd - изменить пароль у записи
-list - список всех записей в хранилище сертификатов
-printcert - вывод содержимого сертификата
-printcertreq - вывод содержимого CSR запроса
-printcrl - вывод содержимого CRL запроса
-storepasswd - изменить пароль на Keystore

Далее, чтобы получить дополнительные ключи по командам из первого списка, вам необходимо добавить ключ -help. Например, я хочу понять как строится команда по генерации пары ключей, для этого я пишу:

keytool.exe -genkeypair -help и получаю вывод дополнительных ключей:

-alias <alias> alias name of the entry to process
-keyalg <keyalg> key algorithm name
-keysize <keysize> key bit size
-sigalg <sigalg> signature algorithm name
-destalias <destalias> destination alias
-dname <dname> distinguished name
-startdate <startdate> certificate validity start date/time
-ext <value> X.509 extension
-validity <valDays> validity number of days
-keypass <arg> key password
-keystore <keystore> keystore name
-storepass <arg> keystore password
-storetype <storetype> keystore type
-providername <providername> provider name
-providerclass <providerclass> provider class name
-providerarg <arg> provider argument
-providerpath <pathlist> provider classpath
-v verbose output
-protected password through protected mechanism

Мы можем подробно изучить содержимое всех созданных в OpenSSL файлов, а также при необходимости конвертировать их в другие форматы.

В следующих командах используются тестовые файлы со следующими именами:

Обратите внимание на расширения файлов — они могут отличаться от тех, которые используются в других инструкциях. Например, вместо .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, можно изучить содержимое запроса на подпись сертификата:

Информацию о содержимом сертификатов можно посмотреть командой 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 списки отозванных сертификатов, публикуемые через регулярные промежутки времени (например, семь дней).

Расширение 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:

Для показа отпечатка сертификата:

Чтобы вывести сертификат в виде строки символов в стиле 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: принципы работы, создание сертификатов, аудит».

Привет, Хабр! Представляю вашему вниманию перевод 10 статьи "Java Keytool" автора Jakob Jenkov из серии статей для начинающих, желающих освоить основы криптографии в Java.

Утилита Keytool

Java Keytool — это инструмент командной строки, который может генерировать пары открытый ключ / закрытый ключ и сохранять их в хранилище ключей. Исполняемый файл утилиты распространяется вместе с Java SDK (или JRE), поэтому, если у вас установлен SDK, значит она у вас также будет предустановлена.
Исполняемый файл называется keytool . Чтобы выполнить его, откройте командную строку (cmd, console, shell и т.д.). и измените текущий каталог на каталог bin в каталоге установки Java SDK. Введите keytool , а затем нажмите клавишу Enter . Вы должны увидеть что-то похожее на это:

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

Скрипты Keytool

Команды утилиты Keytool принимают много аргументов, правильность установки которых может быть трудно запомнить. Поэтому рекомендуется создать несколько скриптов CMD или Shell с последовательностью команд Keytool . Эти сценарии упрощают повторное выполнение команд, а также позволяют вернуться назад и посмотреть, как было создано хранилище ключей.

Генерация ключевой пары

Генерация ключевой пары (открытый ключ / закрытый ключ) является одной из наиболее распространенных задач, для которых используется утилита Keytool . Сгенерированная пара ключей вставляется в файл KeyStore как пара ключей с собственной подписью. Вот общий формат командной строки для генерации пары ключей:

Аргументы объяснены в разделе Аргументы Keytool. Не все эти аргументы нужны и многие являются не обязательными. Утилита сообщит вам, если вы пропустили обязательный аргумент. Вот пример команды, которая импортирует сертификат в KeyStore. Не забудьте удалить разрывы строк при вводе команды в командной строке.

Список записей хранилища

Чтобы вывести список записей в хранилище ключей, вы можете использовать команду list . Ниже представлен формат для команды list . Разрывы строк предназначены только для упрощения чтения. Удалите разрывы строк перед выполнением команды:

Вот пример команды list . Не забудьте удалить разрывы строк!

Эта команда выведет список всех записей в данном хранилище ключей. Результат выполнения будет выглядеть примерно так:

Если вы включите аргумент alias в команду list , в список попадет только запись, соответствующая данному псевдониму. Вот пример команды list с аргументом alias :

Результат выполнения вышеупомянутой команды:

Удаление записи хранилища ключей

Так же в в утилите keytool имеется команда, которая может удалить запись из хранилища ключей: delete . Вот формат этой команды:

Вот пример вызова команды delete . Не забудьте удалить разрывы строк перед запуском!

Эта команда удаляет запись хранилища с псевдонимом testkey хранящегося в файле keystore.jks .

Генерация запроса на сертификат

Утилита keytool может генерировать запрос сертификата с помощью команды certreq . Запрос сертификата — это запрос к центру сертификации (ЦС) на создание публичного сертификата для вашей организации. После создания запроса на сертификат он должен быть отправлен в центр сертификации, в котором вы хотите создать сертификат (например, Verisign, Thawte или какой-либо другой центр сертификации). Прежде чем вы сможете сгенерировать запрос сертификата для личного ключа и пары открытых ключей, вы должны сгенерировать этот закрытый ключ и пару открытых ключей в хранилище ключей (или импортировать его). Как это сделать можно посмотреть в соответсвтующей главе. Вот формат команды для генерации запроса сертификата. Не забудьте удалить все разрывы строк при использовании этой команды:

Вот пример команды -certreq :

Эта команда сгенерирует запрос сертификата для ключа, сохраненного с псевдонимом testkey в файле keystore.jks , и запишет запрос сертификата в файл с именем certreq.certreq .

Аргументы утилиты keytool

Ниже приведен список аргументов, которые принимают различные команды keytool . Помните, что не все команды принимают все эти аргументы. Посмотрите на конкретную команду, чтобы увидеть, какие аргументы она принимает.

Читайте также: