Является ли предупреждение «SSL3_READ_BYTES: неверный сертификат оповещения sslv3», указывающее на сбой SSL

17

Во время выполнения команды ниже 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)**
kris433
источник

Ответы:

25

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

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

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

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

РЕДАКТИРОВАТЬ: Как видно из комментария, вы можете иметь ключ клиента и цепочку сертификатов, а также привязку (я) сервера в 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
источник
привет Дейв; ниже процедура, которой мы следовали. 1: Загрузить корневой CA и промежуточные сертификаты в хранилище ключей. 2. Загрузите подписанный сертификат Comodo в хранилище ключей. 3: Загрузите корневой CA и промежуточные сертификаты в склад доверенных сертификатов. 4. Скопируйте хранилище ключей и файлы trustore для каждого узла в кластере (cassandra). Узлы используют SSL для связи, и они, похоже, извлекают данные без проблем. Однако, когда я запускаю вышеупомянутую команду SSL, проблема поднимается.
kris433
@ kris433: что это за хранилище ключей? Описанная вами процедура звучит так же, как и для Java, если (и только если) она уже сгенерировала закрытый ключ, для которого вы получаете (ed) «подписанный сертификат Comodo», хотя, если вы используете стандартную установку Java, она имеет значение по умолчанию склад доверенных сертификатов, в который входит Comodo, поэтому вам не нужно это менять. OpenSSL не использует хранилище ключей Java или хранилище доверенных сертификатов и по умолчанию вообще не использует хранилище ключей, поэтому вам нужно указывать файлы с помощью -cert [-key]. Если я правильно истолковал ваш комментарий, см. Изменить.
dave_thompson_085
Большое спасибо, Дэйв. Это сработало отлично. Вы спасли мою неделю. Если ты когда-нибудь приедешь в Филадельфию, сырный стейк и джелато на мне;). Еще раз спасибо
kris433 30.09.16
@ kris433: пожалуйста, но официальный способ StackExchange - принять полезный ответ с помощью галочки, чтобы система могла автоматически использовать эту информацию при отображении результатов для других участников; посмотрите «тур», на который вы должны были взглянуть, когда заходите на этот сайт, или, более конкретно, serverfault.com/help/someone-answers .
dave_thompson_085
0

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

Блейк
источник