Keystore в Java | dev64

Краткое введение в keytool

keytool – это инструмент управления ключами и сертификатами. Это позволяет пользователям управлять своими собственными парами открытых / закрытых ключей и соответствующими сертификатами для самоутентификации (посредством цифровых подписей) (пользователи аутентифицируют себя для других пользователей / служб) или служб целостности данных и аутентификации. Этот инструмент входит в состав JDK 1.4 и более поздних версий, и его расположение: «% JAVA_HOME% bin keytool.exe».

Обзор

В этом учебнике мы смотрим на управление криптографическими ключами и сертификатами на Java с помощью KeyStore API.

Ключевые магазины

Если нам нужно управлять ключами и сертификатами на Java, нам нужна keystore, который является просто безопасной коллекцией псевдонимомзаписиключей и сертификатов.

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

По умолчанию Java имеет файл клавиатуры, расположенный в JAVA_HOME/ jre /lib/безопасность/cacerts . Мы можем получить доступ к этому keystore с помощью пароля клавиатуры по умолчанию changeit .

Теперь, с этим немного фона, Давайте вернемся к созданию нашего первого.

1. Строительство

Мы можем легко создать keystore с помощью ключевые , или мы можем сделать это программно с помощью KeyStore API:

Здесь мы используем тип по умолчанию, хотя есть несколько типов keystore доступны, как jceks или pcks12 .

Мы можем переопределить по умолчанию “JKS” (протокол, собственный Oracle) с помощью -Dkeystore.тип параметр:

Или, конечно, можно перечислить один из поддерживаемых форматов в getInstance :

2. Инициализация

Сначала нам нужно загрузка keystore:

Мы используем загрузка создаем ли мы новый магазин ключей или открываем существующий.

И мы расскажем KeyStore создать новый, передавая нулевой в качестве первого параметра.

Мы также предоставляем пароль, который будет использоваться для доступа к keystore в будущем. Мы также можем установить это нулевой , хотя это сделает наши секреты открытыми.

3. Хранение

Наконец, мы экономим наш новый клавиатурный магазин для файловой системы:

Обратите внимание, что не показаны выше несколько проверенных исключений, которые getInstance , нагрузка, и магазин каждый бросок.

Загрузка Keystore

Чтобы загрузить магазин ключей, сначала нужно создать KeyStore например, как и раньше.

На этот раз, однако, давайте указать формат, так как мы загружаем существующий:

Если наш JVM не поддерживает тип клавиатуры, который мы прошли, или если он не соответствует типу клавиатуры в файловой системе, которую мы открываем, мы получим KeyStoreException :

Кроме того, если пароль не так, мы получим НевосстановимоеKeyException:

Хранение записей

В keystore, мы можем хранить три различных вида записей, каждая запись под своим псевдонимом:

• Симметричные ключи (именуемые Секретными Ключами в JCE),
• Асимметричные ключи (именуемые государственными и частными ключами в JCE) и
• Доверенные сертификаты

Давайте посмотрим на каждый из них.

1. Сохранение симметричного ключа

Самое простое, что мы можем хранить в keystore является симметричный ключ.

Чтобы сохранить симметричный ключ, нам нужно три вещи:

1. псевдоним – его просто имя, которое мы будем использовать в будущем для обозначения вступления
2. ключевой – который завернут в KeyStore.SecretKeyEntry .
3. пароль – который завернут в то, что называется ЗащитаПарам .

Имейте в виду, что пароль не может бытьнулевой,однако, это может быть пустойструна. Если мы оставим пароль нулевой для входа, мы получим KeyStoreException:

Это может показаться немного странным, что нам нужно обернуть ключ и пароль в обертке классов.

Мы заворачиваем ключ, потому что setEntry является общим методом, который может быть использован для других типов вступления, а также. Тип ввода позволяет KeyStore API, чтобы относиться к нему по-разному.

Мы заворачиваем пароль, потому что KeyStore API поддерживает обратные вызовы в ГУИ и ЦРУ для сбора пароля от конечному пользователю. Отъезд KeyStore. CallbackHandlerПротекторная Джавадок для получения более подробной информации.

Мы также можем использовать этот метод для обновления существующего ключа. Нам просто нужно позвонить ему снова с тем же псевдонимом и паролем и нашим новым секрет.

2. Сохранение частного ключа

Хранение асимметричных ключей немного сложнее, так как нам нужно иметь дело с цепочками сертификатов.

Кроме того, KeyStore API дает нам специальный метод под названием setKeyEntry что удобнее, чем общий setEntry метод.

Таким образом, чтобы сохранить асимметричный ключ, нам нужно четыре вещи:

1. псевдоним , как и раньше
2. частный ключевой . Поскольку мы не используем общий метод, ключ не будет обернут. Кроме того, для нашего случая, это должен быть пример ПриватНаяКей
3. пароль для доступа к записи. На этот раз пароль является обязательным
4. цепочка сертификатов который удостоверяет соответствующий общественный ключ

Теперь, много может пойти не так здесь, конечно, как если бы pwdArray это нулевой :

Но, есть действительно странное исключение, чтобы быть в курсе, и это, если pwdArray это пустой массив:

Чтобы обновить, мы можем просто позвонить в метод снова с тем же псевдонимом и новым частныйКей и сертификатChain.

Кроме того, это может быть ценным, чтобы сделать быстрое переподготовку на как создать цепочку сертификатов.

3. Сохранение доверенного сертификата

Хранение доверенных сертификатов довольно просто.Для этого требуется только псевдоним и сертификатсама , который имеет тип Сертификат :

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

Из-за этого, важно отметить, что здесь KeyStore на самом деле не проверяет этот сертификат. Мы должны проверить это самостоятельно, прежде чем хранить его.

Чтобы обновить, мы можем просто позвонить в метод снова с тем же псевдонимом и новым доверенныеЦерикатный .

Чтение Записей

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

1. Чтение одной записи

Во-первых, мы можем вытащить ключи и сертификаты по их псевдониму:

Если нет записи под этим именем или она другого типа, то getKey просто возвращает нулевой :

Но, если пароль для ключа не так, Мы получим ту же странную ошибку, о которой мы говорили ранее:

2. Проверка того, содержит ли Keystore псевдоним

С KeyStore просто хранит записи с помощью Карта , он предоставляет возможность проверить существование без получения записи:

3. Проверка вида въезда

Или, KeyStore#entryInstanceOf немного мощнее.

Это как содержитАлиас , за исключением того, что он также проверяет тип входа:

Удаление записей

KeyStore , конечно, поддерживает удаление добавленных записей:

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

Удаление Keystore

Если мы хотим удалить наш keystore, API не поможет нам, но мы все еще можем использовать Java для этого:

Или, в качестве альтернативы, мы можем сохранить keystore вокруг, и просто удалить записи:

Getcertificates()

Получив экземпляр CertPath, вы можете получить экземпляры Certificate, из которых состоит CertPath, вызвав метод getCertificates(). Вот пример получения сертификатов из экземпляра CertPath:

List<Certificate> certificates = certPath.getCertificates();

Getencoded()

Метод getEncoded() сертификата возвращает закодированную версию сертификата в виде байтового массива. Например, если сертификат является сертификатом X509, возвращенный байтовый массив будет содержать версию экземпляра сертификата в кодировке X.590 (ASN.1 DER). Вот пример использования методаgetEncoded():

byte[] encodedCertificate = certificate.getEncoded();

Getpublickey()

Метод сертификата getPublicKey() возвращает открытый ключ этого экземпляра сертификата. Вот пример метода getPublicKey():

PublicKey certificatePublicKey = certificate.getPublicKey();

Gettype()

Метод getType() возвращает строку, указывающую, какой тип сертификатов (например, X.509) содержится в этом экземпляре CertPath. Вот пример получения типа CertPath через методом getType():

String type = certPath.getType();

How to import a .cer certificate into a java keystore?

Java certificatefactory (фабрика сертификатов

Класс CertificateFactory (java.security.cert.CertificateFactory) способен создавать экземпляры сертификата (Certificate) из двоичных данных сертификатов с кодировками X.509 (ASN.1 DER). CertificateFactory также может создавать экземпляры CertPath. CertPath — это цепочка сертификатов, где каждый сертификат подписан следующим сертификатом в данной цепочке.

Java certpath (цепочка сертификатов)

Класс CertPath (java.security.cert.CertPath) представляет цепочку сертификатов (объекты Certificate), где каждый сертификат является цифровым подписывающим лицом следующего сертификата в цепочке. Класс CertPath обычно используется для проверки сертификата личности вместе с сертификатами центров сертификации (ЦС), которые подписали сертификат.

Verify()

Класс сертификата содержит три метода verify(). Эти методы могут использоваться для проверки того, что сертификат действительно подписан с закрытым ключом, соответствующим ожидаемому открытому ключу. Вот пример проверки сертификата:

// получение ожидаемого открытого ключа (не из сертификата!)
PublicKey expectedPublicKey = ... ;

try{
    certificate.verify(expectedPublicKey);

} catch (InvalidKeyException e) {
    // сертификат не был подписан данным открытым ключом

} catch (NoSuchAlgorithmException |
         NoSuchProviderException |
         SignatureException |
         CertificateException e){
    // что-то еще пошло не так
}

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

Выдача и импорт сертификатов

В этом процессе задействованы 3 команды:

-certreq、-gencert、-importcert

1) Учреждение A использует команду certreq для создания файла запроса на подпись сертификата (CSR) и отправки его в учреждение B;

2) После того, как организация B получает этот запрос, она использует команду gencert для выдачи сертификата, который генерирует сертификат или цепочку сертификатов;

3) Учреждение A получает ответ и использует команду importcert для импорта сертификата выдачи в хранилище ключей;

Пример: импортируйте сертификат, подписанный хранилищем ключей test.keystore, в хранилище ключей bo.keystore

Сначала создайте хранилище ключей test.keystore

keytool -genkeypair -alias test -keyalg RSA -keystore d:keystoretest.keystore -storetype pkcs12

 Введите пароль хранилища ключей:
 Введите новый пароль еще раз:
 Как ваше имя и фамилия?
  [Unknown]:  test
 Как называется ваше организационное подразделение?
  [Unknown]:  xinwei
 Как называется ваша организация?
  [Unknown]:  xinwei
 Как называется ваш город или район?
  [Unknown]:  bj
 Как называется ваша провинция / город / автономный район?
  [Unknown]:  bj
 Какой двухбуквенный код страны у этого устройства?
  [Unknown]:  cn
 Правильно ли CN = test, OU = xinwei, O = xinwei, L = bj, ST = bj, C = cn?
     [Нет]: y

Создать файл запроса на подпись сертификата CSR

keytool -certreq -alias www.bo.org -keystore d:keystorebo.keystore -file d:keystorecert.csr

 Введите пароль хранилища ключей:

Объяснение: Экспортируйте открытый ключ с псевдонимом записи www.bo.org и некоторой личной информацией из файла хранилища ключей bo.keystore в виде файла запроса сертификата.

Выдать сертификат

keytool -gencert -infile d:keystorecert.csr -outfile d:keystoretest_to_bo.crt -alias test -keystore d:keystoretest.keystore

 Введите пароль хранилища ключей:

Объяснение: Используйте закрытый ключ записи с псевдонимом test в хранилище ключей test.keystore, чтобы выдать сертификат для cert.csr и сохранить его в файле test_to_bo.crt.

Импортируйте выданный сертификат в хранилище ключей

keytool -importcert -file D:keystoretest_to_bo.crt -alias www.bo.org -keystore D:keystorebo.keystore

 Введите пароль хранилища ключей:
 ошибка keytool: java.lang.Exception: невозможно установить цепочку из ответа

Объяснение: Обновите выданный сертификат test_to_bo.crt в файл хранилища ключей bo.keystore существующего псевдонима ww.bo.org

В командной строке появляется сообщение об ошибке «Невозможно установить цепочку из ответа». Это связано с тем, что перед обновлением выданного сертификата в файл хранилища ключей должен быть импортирован доверенный сертификат организации-эмитента, то есть сертификат теста хранилища ключей. .keystore Импортировать его в хранилище ключей bo.keystore с соответствующим псевдонимом.

Экспортируйте сертификат доверия test.keystore:

keytool -exportcert -keystore d:keystoretest.keystore -alias test -file d:keystoretest.crt

 Введите пароль хранилища ключей:
 Сертификат хранится в файле <d:  keystore  test.crt>

Импортируйте доверенный сертификат test.crt с псевдонимом test в хранилище ключей bo.keystore:

keytool -importcert -file D:keystoretest.crt -alias test -keystore D:keystorebo.keystore

 Введите пароль хранилища ключей:
 Владелец: CN = test, OU = xinwei, O = xinwei, L = bj, ST = bj, C = cn
 Издатель: CN = test, OU = xinwei, O = xinwei, L = bj, ST = bj, C = cn
 Серийный номер: c3cd021
 Действительно с вс 17 февраля, 21:44:45 CST 2021 по субботу 18 мая 21:44:45 CST 2021
 Отпечаток сертификата:
         MD5:  61:BF:F3:13:EE:CB:7E:41:9B:1C:CD:C9:AC:34:6F:62
         SHA1: E5:C4:5A:22:4A:E2:39:2F:D1:8F:75:9F:4F:D5:94:20:EB:00:A9:A8
         SHA256: F2:6C:35:7E:07:F1:F3:7E:13:8D:A3:13:3E:34:6E:D9:D4:BF:FA:53:29:
8F:84:71:27:DC:DB:0A:26:2F:F7:1A
 Имя алгоритма подписи: SHA256withRSA
 Алгоритм открытого ключа субъекта: 2048-битный ключ RSA
 Версия: 3

 Расширение:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 52 32 69 80 EF C3 A3 7B   FF A8 26 11 79 F5 65 1A  R2i.......&.y.e.
0010: 98 56 37 D5                                        .V7.
]
]

 Вы доверяете этому сертификату? [Нет]: y
 Сертификат добавлен в хранилище ключей

Импортируйте выданный сертификат test_to_bo.crt в хранилище ключей bo.keystore с псевдонимом «www.bo.org»:

keytool -importcert -file D:keystoretest_to_bo.crt -alias www.bo.org -keystore D:keystorebo.keystore

 Введите пароль хранилища ключей:
 Ответ сертификата установлен в хранилище ключей

В это время самозаверяющий сертификат с псевдонимом записи www.bo.org в хранилище ключей bo.keystore был обновлен до сертификата выдачи, подписанного хранилищем ключей test.keystore:

keytool -list -v -keystore D:keystorebo.keystore

Введите пароль хранилища ключей:
 Тип хранилища ключей: JKS
 Поставщик хранилища ключей: SUN

 Ваше хранилище ключей содержит 2 записи

 Псевдоним: www.bo.org
 Дата создания: 2021-2-17
 Тип записи: PrivateKeyEntry
 Длина цепочки сертификатов: 2
 Сертификат [1]:
 Владелец: CN = www.bo.org, OU = www.bo.org, O = xinwei, L = xinwei, ST = bj, C = bj
 Издатель: CN = test, OU = xinwei, O = xinwei, L = bj, ST = bj, C = cn
 Серийный номер: 566b0d42
 Действительно с вс 17 февраля, 22:05:54 CST 2021 по субботу 18 мая 22:05:54 CST 2021
 Отпечаток сертификата:
         MD5:  50:24:53:0D:9A:42:F7:5E:6E:C6:4D:27:21:B1:D3:4B
         SHA1: 28:47:47:87:E3:67:C1:88:85:57:A8:DF:1D:34:04:CC:C7:CC:EE:9C
         SHA256: E2:AC:94:A9:77:4B:5B:F1:DE:76:0E:DE:55:42:B4:12:8A:BD:D6:BA:0E:
9E:8B:3E:08:32:B5:A9:1A:80:13:42
 Имя алгоритма подписи: SHA256withRSA
 Алгоритм открытого ключа субъекта: 2048-битный ключ RSA
 Версия: 3

 Расширение:

#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 52 32 69 80 EF C3 A3 7B   FF A8 26 11 79 F5 65 1A  R2i.......&.y.e.
0010: 98 56 37 D5                                        .V7.
]
]

#2: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: C6 AB A5 21 DC 68 97 79   91 5C D1 0D A3 3A C4 DA  ...!.h.y....:..
0010: 64 F7 73 3A                                        d.s:
]
]

 Сертификат [2]:
 Владелец: CN = test, OU = xinwei, O = xinwei, L = bj, ST = bj, C = cn
 Издатель: CN = test, OU = xinwei, O = xinwei, L = bj, ST = bj, C = cn
 Серийный номер: c3cd021
 Действительно с вс 17 февраля, 21:44:45 CST 2021 по субботу 18 мая 21:44:45 CST 2021
 Отпечаток сертификата:
         MD5:  61:BF:F3:13:EE:CB:7E:41:9B:1C:CD:C9:AC:34:6F:62
         SHA1: E5:C4:5A:22:4A:E2:39:2F:D1:8F:75:9F:4F:D5:94:20:EB:00:A9:A8
         SHA256: F2:6C:35:7E:07:F1:F3:7E:13:8D:A3:13:3E:34:6E:D9:D4:BF:FA:53:29:
8F:84:71:27:DC:DB:0A:26:2F:F7:1A
 Имя алгоритма подписи: SHA256withRSA
 Алгоритм открытого ключа субъекта: 2048-битный ключ RSA
 Версия: 3

 Расширение:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 52 32 69 80 EF C3 A3 7B   FF A8 26 11 79 F5 65 1A  R2i.......&.y.e.
0010: 98 56 37 D5                                        .V7.
]
]



*******************************************
*******************************************


 Псевдонимы: test
 Дата создания: 2021-2-17
 Тип записи: trustCertEntry

 Владелец: CN = test, OU = xinwei, O = xinwei, L = bj, ST = bj, C = cn
 Издатель: CN = test, OU = xinwei, O = xinwei, L = bj, ST = bj, C = cn
 Серийный номер: c3cd021
 Действительно с вс 17 февраля, 21:44:45 CST 2021 по субботу 18 мая 21:44:45 CST 2021
 Отпечаток сертификата:
         MD5:  61:BF:F3:13:EE:CB:7E:41:9B:1C:CD:C9:AC:34:6F:62
         SHA1: E5:C4:5A:22:4A:E2:39:2F:D1:8F:75:9F:4F:D5:94:20:EB:00:A9:A8
         SHA256: F2:6C:35:7E:07:F1:F3:7E:13:8D:A3:13:3E:34:6E:D9:D4:BF:FA:53:29:
8F:84:71:27:DC:DB:0A:26:2F:F7:1A
 Имя алгоритма подписи: SHA256withRSA
 Алгоритм открытого ключа субъекта: 2048-битный ключ RSA
 Версия: 3

 Расширение:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 52 32 69 80 EF C3 A3 7B   FF A8 26 11 79 F5 65 1A  R2i.......&.y.e.
0010: 98 56 37 D5                                        .V7.
]
]



*******************************************
*******************************************

Сравнивая информацию о сертификате хранилища ключей bo.keystore, созданную в начале, можно обнаружить, что цепочка сертификатов с псевдонимом «www.bo.org» была изменена с одного самозаверяющего сертификата bo.keystore на два сертификата. , а именно test.Сертификат bo.keystore, подписанный хранилищем ключей, и самозаверяющий сертификат test.keystore.

Импортируйте доверенный сертификат в хранилище ключей

Пример: Импортируйте доверенный сертификат test.crt в хранилище ключей bo.keystore с псевдонимом «test»

cmd команда:

keytool -importcert -file D:keystoretest.crt -alias test -keystore D:keystorebo.keystore

 Введите пароль хранилища ключей:
 Владелец: CN = test, OU = xinwei, O = xinwei, L = bj, ST = bj, C = cn
 Издатель: CN = test, OU = xinwei, O = xinwei, L = bj, ST = bj, C = cn
 Серийный номер: c3cd021
 Действительно с вс 17 февраля, 21:44:45 CST 2021 по субботу 18 мая 21:44:45 CST 2021
 Отпечаток сертификата:
         MD5:  61:BF:F3:13:EE:CB:7E:41:9B:1C:CD:C9:AC:34:6F:62
         SHA1: E5:C4:5A:22:4A:E2:39:2F:D1:8F:75:9F:4F:D5:94:20:EB:00:A9:A8
         SHA256: F2:6C:35:7E:07:F1:F3:7E:13:8D:A3:13:3E:34:6E:D9:D4:BF:FA:53:29:
8F:84:71:27:DC:DB:0A:26:2F:F7:1A
 Имя алгоритма подписи: SHA256withRSA
 Алгоритм открытого ключа субъекта: 2048-битный ключ RSA
 Версия: 3

 Расширение:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 52 32 69 80 EF C3 A3 7B   FF A8 26 11 79 F5 65 1A  R2i.......&.y.e.
0010: 98 56 37 D5                                        .V7.
]
]

 Вы доверяете этому сертификату? [Нет]: y
 Сертификат добавлен в хранилище ключей

После импорта сертификата test.crt проверьте информацию о хранилище ключей bo.keystore и добавьте “тестовую” запись:

keytool -list -v -keystore D:keystorebo.keystore

 Введите пароль хранилища ключей:
 Тип хранилища ключей: JKS
 Поставщик хранилища ключей: SUN

 Ваше хранилище ключей содержит 2 записи

 Псевдоним: www.bo.org
 Дата создания: 2021-2-17
 Тип записи: PrivateKeyEntry
 Длина цепочки сертификатов: 1
 Сертификат [1]:
 Владелец: CN = www.bo.org, OU = www.bo.org, O = xinwei, L = xinwei, ST = bj, C = bj
 Издатель: CN = www.bo.org, OU = www.bo.org, O = xinwei, L = xinwei, ST = bj, C = bj
 Серийный номер: 53e1769
 Действительно с вс 17 февраля, 21:42:31 CST 2021 по субботу 18 мая 21:42:31 CST 2021
 Отпечаток сертификата:
         MD5:  D3:4B:91:FE:0D:08:77:D2:AC:8D:65:10:F1:26:30:2F
         SHA1: CB:43:4E:B5:03:5B:FC:60:FA:DC:BF:EC:02:E1:FA:C8:9C:53:D4:FE
         SHA256: 5D:44:89:D4:FF:1A:70:45:67:2D:3D:14:11:72:61:1D:D3:9A:EA:01:4B:
43:FD:38:F6:A9:38:B8:78:7D:53:3E
 Имя алгоритма подписи: SHA256withRSA
 Алгоритм открытого ключа субъекта: 2048-битный ключ RSA
 Версия: 3

 Расширение:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: C6 AB A5 21 DC 68 97 79   91 5C D1 0D A3 3A C4 DA  ...!.h.y....:..
0010: 64 F7 73 3A                                        d.s:
]
]



*******************************************
*******************************************


 Псевдонимы: test
 Дата создания: 2021-2-17
 Тип записи: trustCertEntry

 Владелец: CN = test, OU = xinwei, O = xinwei, L = bj, ST = bj, C = cn
 Издатель: CN = test, OU = xinwei, O = xinwei, L = bj, ST = bj, C = cn
 Серийный номер: c3cd021
 Действительно с вс 17 февраля, 21:44:45 CST 2021 по субботу 18 мая 21:44:45 CST 2021
 Отпечаток сертификата:
         MD5:  61:BF:F3:13:EE:CB:7E:41:9B:1C:CD:C9:AC:34:6F:62
         SHA1: E5:C4:5A:22:4A:E2:39:2F:D1:8F:75:9F:4F:D5:94:20:EB:00:A9:A8
         SHA256: F2:6C:35:7E:07:F1:F3:7E:13:8D:A3:13:3E:34:6E:D9:D4:BF:FA:53:29:
8F:84:71:27:DC:DB:0A:26:2F:F7:1A
 Имя алгоритма подписи: SHA256withRSA
 Алгоритм открытого ключа субъекта: 2048-битный ключ RSA
 Версия: 3

 Расширение:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 52 32 69 80 EF C3 A3 7B   FF A8 26 11 79 F5 65 1A  R2i.......&.y.e.
0010: 98 56 37 D5                                        .V7.
]
]



*******************************************
*******************************************

Примечание: test.crt – это сертификат, сгенерированный другим хранилищем ключей test.keystore, псевдоним записи, указанный при его импорте в хранилище ключей bo.keystore, не может совпадать с псевдонимом записи, который уже существует в хранилище ключей (кроме импорта сертификата подписи) , как правило, он совпадает с псевдонимом записи хранилища ключей экспортированного сертификата. В это время импортированная запись будет сохранена в форме доверенного сертификата, а тип записи – trustCertEntry.

Попытайтесь импортировать сертификат test.crt в хранилище ключей bo.keystore с псевдонимом «www.bo.org», сообщив, что операция недопустима:

keytool -importcert -file D:keystoretest.crt -alias www.bo.org -keystore D:keystorebo.keystore

 Введите пароль хранилища ключей:
 ошибка keytool: java.lang.Exception: открытый ключ в ответе не соответствует хранилищу ключей

Инструкция по использованию keytool

Следующие команды могут использоваться при использовании инструмента keytool (команды каждой версии JDK будут разными, но будут иметь обратную совместимость, в этом примере используется JDK1.8)

Настройка jre

Казалось бы, все настроено, и должно работать. Но нет. Остается еще один важный штрих.

Чтобы из приложения на JBoss аутентифицироваться в КриптоПро УЦ по протоколу Gost TLS, сервер JBoss нужно запускать в JRE с установленным КриптоПро JCP провайдером.

При установке JCP в настройки JRE вносятся изменения. В частности, в jre1.8.0_144libsecurity java.security алгоритмы KeyManagerFactory и TrustManagerFactory меняются на Gost. Если так оставить, то в JBoss при старте будет возникать ошибка:

Настройка приложения

Для того чтобы при установке deployment-приложение интегрировалось с настройками на сервере, необходимо внести ряд параметров в его конфигурационные файлы.

Домен безопасности и виртуальный хост приложения указываются в /WEB-INF/jboss-web.xml

Настройка сервера jboss

Для настройки сервера JBoss EAP 7.0.0 все изменения нужно внести в конфигурационный файл jboss-EAP-7.0.0standaloneconfiguration

standalone.xml

В раздел <system-properties> добавляются настройки, указывающие серверу, каких провайдера и хранилища использовать для двусторонней ГОСТ-аутентификации:

Для настройки RSA TLSv1.2 аутентификации пользователя и сервера JBoss в раздел

нужно добавить область безопасности:

Таким образом, для JBoss указаны все необходимые хранилища ключей и сертификатов.

В раздел

Подготовка gost-ключей аутентификации

Процесс обоюдной аутентификации сервера JBoss и КриптоПро УЦ сервера в сущности такой же. Единственное отличие в криптографических алгоритмах.

Серверы обмениваются сертификатами с алгоритмами подписи ГОСТ Р 34.11/34.10-2001 и хэширования подписи ГОСТ Р 34.11-94 вместо применяемых в RSA TLSv1.2 sha256RSA и sha256 соответственно. В качестве корневого сертификата здесь выступает ROOT-сертификат самого ПАК КриптоПро УЦ.

Подготовка rsa-ключей аутентификации

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

Удостоверяющие центры для сервера и клиента могут быть разные.

Пользователь должен доверять удостоверяющему центру, выпустившему сертификат для сервера.

Сервер должен доверять удостоверяющему центру, выпустившему сертификат для клиента.

Существует много утилит и инструментов с хорошим описанием и примерами, которые позволяют работать с хранилищами и выполнять генерацию ключей и запросов на сертификат (keytool, openSSL, Portecle, XCA). Поэтому процесс подготовки хранилищ и выпуск сертификатов здесь пропустим.

Вот, например, хорошая статья и пошаговая инструкция по настройке Two-way SSL with TLS1.2 для Oracle SOA Suite с использованием openSSL и keytool. Но, правда, она частично потеряла актуальность и перестала отражать всю картину. Выпущенные по ней сертификаты не будут корректно восприниматься в веб-браузерах.

Error: «Subject Alternative Name Missing» or NET::ERR_CERT_COMMON_NAME_INVALID or «Your connection is not private»

если получит с сервера SSL-сертификат без домена в альтернативном имени субъекта сертификации.

Вот что говорит об этом Support Google Chrome Answer

Как с помощью openSSL добавить в сертификат subjectAlternativeName — можно посмотреть здесь и здесь

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

Получение экземпляра certpath

Обычно экземпляр CertPath получают из фабрики сертификатов (CertificateFactory или CertPathBuilder).

Получение экземпляра сертификата

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

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

Постановка задачи

Для корпоративного приложения с тонким клиентом в веб-браузере, middle или backend servlet-а, которые запускаются на JBoss EAP, необходимо настроить двустороннюю аутентификацию по протоколу TLSv1.2 с применением зарубежных криптографических алгоритмов.

Задача усложняется тем, что приложение на сервере JBoss в свою очередь взаимодействует, например, с Программно-аппаратным комплексом «ПАК Удостоверяющий центр КриптоПро», где требуется процедура двусторонней аутентификации по протоколу Transport Layer Security (TLSv1.0) c использованием российских криптографических алгоритмов.

Получается, что в одном приложении на сервере JBoss нужно подружить отечественную и зарубежную криптографию.

Аутентификация должна выполняться комбинированным методом инструментами Инфраструктуры открытых ключей (PKI), т.е. с помощью сертификатов клиента и сервера.

Просмотр информации о хранилище ключей

Пример: просмотр информации о хранилище ключей с именем bo.keystore

Cmd команда:

keytool -list -v -keystore D:keystorebo.keystore

 Введите пароль хранилища ключей:
 Тип хранилища ключей: JKS
 Поставщик хранилища ключей: SUN

 Ваше хранилище ключей содержит 1 запись

 Псевдоним: www.bo.org
 Дата создания: 2021-2-17
 Тип записи: PrivateKeyEntry
 Длина цепочки сертификатов: 1
 Сертификат [1]:
 Владелец: CN = www.bo.org, OU = www.bo.org, O = xinwei, L = xinwei, ST = bj, C = bj
 Издатель: CN = www.bo.org, OU = www.bo.org, O = xinwei, L = xinwei, ST = bj, C = bj
 Серийный номер: 53e1769
 Действительно с вс 17 февраля, 21:42:31 CST 2021 по субботу 18 мая 21:42:31 CST 2021
 Отпечаток сертификата:
         MD5:  D3:4B:91:FE:0D:08:77:D2:AC:8D:65:10:F1:26:30:2F
         SHA1: CB:43:4E:B5:03:5B:FC:60:FA:DC:BF:EC:02:E1:FA:C8:9C:53:D4:FE
         SHA256: 5D:44:89:D4:FF:1A:70:45:67:2D:3D:14:11:72:61:1D:D3:9A:EA:01:4B:
43:FD:38:F6:A9:38:B8:78:7D:53:3E
 Имя алгоритма подписи: SHA256withRSA
 Алгоритм открытого ключа субъекта: 2048-битный ключ RSA
 Версия: 3

 Расширение:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: C6 AB A5 21 DC 68 97 79   91 5C D1 0D A3 3A C4 DA  ...!.h.y....:..
0010: 64 F7 73 3A                                        d.s:
]
]



*******************************************
*******************************************

Распечатать содержимое сертификата

Пример: распечатать сертификат bo.crt, экспортированный из хранилища ключей bo.keystore с псевдонимом www.bo.org

cmd команда:

keytool -printcert -v -file d:keystorebo.crt

 Владелец: CN = www.bo.org, OU = www.bo.org, O = xinwei, L = xinwei, ST = bj, C = bj
 Издатель: CN = www.bo.org, OU = www.bo.org, O = xinwei, L = xinwei, ST = bj, C = bj
 Серийный номер: 53e1769
Действительно с вс 17 февраля, 21:42:31 CST 2021 по субботу 18 мая 21:42:31 CST 2021
 Отпечаток сертификата:
         MD5:  D3:4B:91:FE:0D:08:77:D2:AC:8D:65:10:F1:26:30:2F
         SHA1: CB:43:4E:B5:03:5B:FC:60:FA:DC:BF:EC:02:E1:FA:C8:9C:53:D4:FE
         SHA256: 5D:44:89:D4:FF:1A:70:45:67:2D:3D:14:11:72:61:1D:D3:9A:EA:01:4B:
43:FD:38:F6:A9:38:B8:78:7D:53:3E
 Имя алгоритма подписи: SHA256withRSA
 Алгоритм открытого ключа субъекта: 2048-битный ключ RSA
 Версия: 3

 Расширение:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: C6 AB A5 21 DC 68 97 79   91 5C D1 0D A3 3A C4 DA  ...!.h.y....:..
0010: 64 F7 73 3A                                        d.s:
]
]

Примечание. Вы также можете использовать параметр -sslserver ip: port, чтобы распечатать содержимое сертификата, предоставленного определенным ssl-сервером, непосредственно из сети.

Результаты

Приложение и среда исполнения с двусторонней аутентификацией настроены, каналы передачи данных зашифрованы, между участниками системы установлены надежные соединения.

Создание экземпляра certificate

Создав экземпляр CertificateFactory, вы можете начать создавать экземпляры Certificate. Это делается с помощью вызова метода generateCertificate(). Пример вызова методаgenerateCertificate():

InputStream certificateInputStream = new FileInputStream("my-x509-certificate.crt");

Certificate certificate = certificateFactory.generateCertificate(certificateInputStream);

Создание экземпляра certificatefactory

Прежде чем вы сможете создавать экземпляры Certificate, вы должны создать экземпляр CertificateFactory. Пример:

CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509");

В этом примере создается экземпляр CertificateFactory, способный создавать экземпляры сертификата X.509 (X509Certificate — подкласс Certificate).

Создание экземпляра certpath

CertificateFactory также может создавать экземпляр CertPath. Экземпляр CertPath создается вызовом метода generateCertPath():

InputStream certificateInputStream = new FileInputStream("my-x509-certificate-chain.crt");

CertPath certPath = certificateFactory.generateCertPath(certificateInputStream);

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

Пример: удалите запись сертификата с проверкой псевдонима в хранилище ключей bo.keystore

cmd команда:

keytool -delete -keystore D:keystorebo.keystore -alias test

 Введите пароль хранилища ключей:

Экспорт сертификата входа в хранилище ключей

Пример: экспорт соответствующей информации и открытого ключа псевдонима записи www.bo.org в хранилище ключей bo.keystore в файл цифрового сертификата bo.crt

cmd команда:

keytool -exportcert -keystore d:keystorebo.keystore -alias www.bo.org -file d:keystorebo.crt

 Введите пароль хранилища ключей:
 Сертификат хранится в файле <d:  keystore  bo.crt>

Результат операции: в указанном каталоге операционной системы создается файл «bo.crt». Обратите внимание, что файл сертификата не содержит закрытого ключа.

Заключение

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

Полную реализацию примера можно найти более на Github .