Несоответствие KeyStore и TrustStore

Question

У меня есть клиент, который заменил хранилище ключей и доверие наших компонентов продукта. После замены компоненты не могут связываться друг с другом (2-сторонний SSL).

На SSL бревнами я вижу:
http-nio-8100-exec-2, fatal error: 42: null cert chain javax.net.ssl.SSLHandshakeException: null cert chain %% Invalidated: [Session-6, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256] http-nio-8100-exec-2, SEND TLSv1.2 ALERT: fatal, description = bad_certificate http-nio-8100-exec-2, WRITE: TLSv1.2 Alert, length = 2 http-nio-8100-exec-2, fatal: engine already closed. Rethrowing javax.net.ssl.SSLHandshakeException: null cert chain

Они настроили те же хранилища ключей и доверенных файлов с обеих сторон. Я открыл их хранилище ключей и доверенных и это, как они построены:
хранилище ключей
entry1 - сервер
серт [1] MD5: X
серт [2] MD5: Y
серт [3 ] MD5: Z

доверенное хранилище entry1 - корень
серт [1] MD5: Z
entry2 - промежуточная
cert [1] MD5: Y

Мне кажется, что факт, что cert [1] в хранилище ключей (с MD5 X) отсутствует в доверенности, проблематичен.

Я прав?

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

Answer 1

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

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

Вы должны проверить, является ли ваш серта [1] в хранилища является самостоятельно подписанным сертификатом. Вы можете достичь этого следующим образом:

Для.JKS Java тип хранилища ключей:

keytool -list -v -keystore [keystore-file-name].jks 

-Для # Тип PKCS12 хранилище ключей:

keytool -list -keystore [keystore-file-name].p12 -storetype PKCS12 -v 

Если сертификат печатается, проверьте 'Эмитенту' атрибут.

Если он соответствует атрибут «Владелец», это означает, что это само-подписанный сертификат и вам нужно добавить «серт [1]» в доверенных сертификатов.

Если они не совпадают, попробуйте один из следующих вариантов:

• Сформировать новый 'серт [1] подписанную либо «Y» или 'Z' и добавить его в keystore или заменить существующий. Решение о замене или добавлении зависит от того, как ваш код считывает сертификат. Замена может быть лучшим вариантом.
• Добавить текущий 'Эмитент' из 'серт [1] из хранилищу ключей в доверенных сертификатов.

Если сертификат на 'эмитента' из 'CERT [1' в хранилище уже присутствует в доверенных сертификатов, я бы ожидается, что квитирование SSL будет успешным.

Вот как добавить эмитент в доверенные сертификаты:

1) Достать Общественный Сертификат эмитента, который хранится в .cer файла.Если эмитент является самогенерируемым, и вы получите доступ к своему хранилища, сертификату экспортироваться оттуда, используя следующую команду:

keytool -export -keystore [issuer-keystore].jks -alias [alias]-file [output-file-name].cer 

2) Импортируйте .cer файл в доверенных сертификатов:

keytool -importcert -file [output-file-name].cer -keystore [truststore-file-name].jks -alias [alias] 

Answer 2

Я прав?

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