это предупреждение «SSL3_READ_BYTES: sslv3 alert bad certificate», указывающий, что SSL не удалось

при запуске следующей команды openssl s_client -host example.xyz -port 9093

Я получаю следующую ошибку.

139810559764296:error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate:s3_pkt.c:1259:SSL alert number 42
39810559764296:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184:

Но в конце я получаю сообщение "Verify return code: 0 (ok)".

Мой вопрос в том, что означает вышеуказанное предупреждение, и если SSL был фактически успешным. Большое спасибо за помощь заранее.

SSL handshake has read 6648 bytes and written 354 bytes
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1.2
Cipher    : AES128-SHA
Session-ID: xx
Session-ID-ctx:
Master-Key: xx
Key-Arg   : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1475096098
Timeout   : 300 (sec)
**Verify return code: 0 (ok)**
11 голосов | спросил kris433 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2016 18:58:45 +0300 2016, 18:58:45

1 ответ


15

«Сбой рукопожатия» означает, что квитирование не выполнено, и соединение SSL /TLS отсутствует. Вы должны увидеть, что openssl выходит в оболочку (или CMD и т. Д.) И не дожидается отправки исходных данных на сервер. «Проверить код возврата 0» означает, что в сертификате сервера не было проблем found , потому что оно не было проверено вообще или потому, что оно было проверено и было хорошо (насколько проверены проверки OpenSSL, что не охватывает все); в этом случае, зная протокол, мы можем вывести последний случай.

Получение предупреждения bad certificate (код 42) означает, что сервер требует аутентификации с сертификатом, и вы этого не сделали, и это привело к сбою рукопожатия. Несколько строк перед строкой SSL handshake has read ... and written ... вы должны увидеть строку Acceptable client certificate CA names обычно следуют несколько строк, идентифицирующих ЦС, возможно, за ними следует начало строки Client Certificate Types и, возможно, некоторые из Requested Signature Algorithms в зависимости от вашей версии OpenSSL и согласованного протокола.

Найти сертификат , выданный ЦС в «приемлемом» списке, или если он был пустым, найдите документацию на сервере или о сервере, в котором указано, какие центры сертификации доверять или обращаться к операторам или владельцам серверов и спросите их, плюс соответствующий личный ключ , как в формате PEM, , так и укажите их с помощью -cert $file -key $file; если вы оба в одном файле, как это возможно с помощью PEM, просто используйте -cert $file. Если у вас их в другом формате, укажите его или выполните поиск здесь и, возможно, суперпользователя и security.SX; Есть уже много Q & Как о преобразовании различных сертификатов и форматов privatekey. Если вашему сертификату требуется «цепочка» или «промежуточный» сертификат (или даже более одного), который будет проверен, как это часто бывает для сертификата от открытого ЦС (в сравнении с внутренним) в зависимости от того, как настроен сервер, s_client требует трюка: либо добавьте сертификаты цепочки в ваш системный магазин доверия, либо создайте локальную /временную сеть доверия, содержащую сертификат CA (ы), вам необходимо проверить сервер PLUS на сертификат (ы) цепи, который вам нужно отправить.

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

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

# Assume Java keystore is type JKS (the default but not only possibility)
# named key.jks and the privatekey entry is named mykey (ditto)
# and the verify certs are in trust.jks in entries named trust1 trust2 etc.

# convert Java key entry to PKCS12 then PKCS12 to PEM files
keytool -importkeystore -srckeystore key.jks -destkeystore key.p12 -deststoretype pkcs12 -srcalias mykey 
openssl pkcs12 -in key.p12 -nocerts -out key.pem
openssl pkcs12 -in key.p12 -nokeys -clcerts -out cert.pem
openssl pkcs12 -in key.p12 -nokeys -cacerts -out chain.pem
# extract verify certs to individual PEM files
# (or if you 'uploaded' PEM files and still have them just use those)
keytool -keystore trust.jks -export -alias trust1 -rfc -file trust1.pem
keytool -keystore trust.jks -export -alias trust2 -rfc -file trust2.pem
... more if needed ...
# combine for s_client 
cat chain.pem trust*.pem >combined.pem
openssl s_client -connect host:port -key key.pem -cert cert.pem -CAfile combined.pem
ответил dave_thompson_085 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2016 20:52:04 +0300 2016, 20:52:04

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132