SSL не найден подходящий сертификат

Я знаю, что это распространенная ошибка и что есть много дубликатов этого вопроса. Хотя они есть, я не смог найти истинную причину и решить мою проблему, так что давайте начнем.

Я использую Kafka, и на стороне сервера в моем доверенном магазине у меня есть 4 цепочки. Каждая цепочка представляет один центр сертификации. Каждая цепочка также импортировалась как пакет (Interm + Root cert). Конечно, у каждого брокера есть собственное хранилище ключей, и он был подписан CA-1.

У моего клиента есть сертификаты, подписанные CA-3. В доверительном магазине моего клиента я могу перечислить те же цепочки, что и у моих брокеров.

Пример:

  1. Клиент пытается пройти аутентификацию и имеет сертификат, подписанный CA-1 (работает)
  2. Клиент пытается пройти аутентификацию и имеет сертификат, подписанный CA-2 (работает)
  3. Клиент пытается пройти аутентификацию и имеет сертификат, подписанный CA-3 (не работает)

В режиме отладки на клиенте я могу найти это:

check handshake state: unknown[13]
*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Supported Signature Algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA
Cert Authorities:
<CN=CA-1>
<CN=CA-2>
<CN=CA-3>
.
.
.
*** ServerHelloDone
[read] MD5 and SHA1 hashes:  len = 4
0000: 0E 00 00 00                                        ....
Warning: no suitable certificate found - continuing without client authentication
*** Certificate chain
<Empty>
*** 
.
.
.
kafka-producer-network-thread | console-producer, READ: TLSv1.2 Handshake, length = 3018
check handshake state: server_hello[2]
kafka-producer-network-thread | console-producer, fatal error: 10: Handshake message sequence violation, 2
javax.net.ssl.SSLProtocolException: Handshake message sequence violation, 2
%% Invalidated:  [Session-4, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384]
kafka-producer-network-thread | console-producer, SEND TLSv1.2 ALERT:  fatal, description = unexpected_message
Padded plaintext before ENCRYPTION:  len = 80

Теперь, что я не понимаю. Приложение нашло доверенный сертификат брокера (логи в начале я не хотел ставить), смогло вычислить в CertificateRequest все доступные ЦС, но рукопожатие по-прежнему не удается.

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

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

Если я сделал что-то не так, пожалуйста, поправьте меня или даже лучше, если я делаю что-то не так. Я SSL кивок и хотел бы узнать кое-что .. Спасибо!


person iMajna    schedule 03.06.2020    source источник


Ответы (1)


Проблема в моем случае, и я думаю, что во многих случаях в стеке была:

  • У меня не было privKeyEntry в хранилище ключей моего клиента.

Итак, если бы я сделал:

$ keytool -list -keystore client.keystore.jks  

Я бы нашел это:

primaryca, Jul 26, 2014, trustedCertEntry,
Certificate fingerprint (SHA1): <snip>
client, Jul 26, 2014, trustedCertEntry,
Certificate fingerprint (SHA1):  <snip>

Как видите, в хранилище ключей для сертификата клиента нет PrivateKeyEntry.

Поэтому я начал с нуля.

# Creating client keystore
$ openssl pkcs12 -export -in client_certificate.crt -inkey client_certificate.key -certfile client_certificate.crt -out client.p12
$ keytool -importkeystore -srckeystore client.p12 -srcstoretype pkcs12 -destkeystore client.keystore.jks -deststoretype JKS

# add bundle (interm + root)
$ keytool -keystore client.keystore.jks -alias CArootbundle -import -file bundle.pem

А теперь, после перечисления хранилища ключей:

CArootbundle, Jul 26, 2014, trustedCertEntry,
Certificate fingerprint (SHA1): <snip>
1, Jul 26, 2014, PrivateKeyEntry,
Certificate fingerprint (SHA1):  <snip>

После того, как я запустил свое приложение с недавно созданным хранилищем ключей, все заработало :)

Надеюсь, я помог кому-то!

Ваше здоровье

person iMajna    schedule 04.06.2020
comment
Ошибка здесь заключалась в том, что вы не использовали тот же псевдоним при импорте подписанного сертификата, который вы использовали при создании пары ключей и CSR. Дубликат многих. - person user207421; 04.06.2020