При выполнении следующей команды 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)**
«Сбой рукопожатия» означает, что рукопожатие не удалось, и соединение SSL / TLS отсутствует. Вы должны это увидеть openssl выходит в оболочку (или CMD и т. д.) и не ожидает отправки входных данных на сервер. «Проверить код возврата 0» означает, что проблем не было нашел в сертификате сервера, либо потому, что он не был проверен вообще, либо потому, что он был проверен и был хорош (что касается проверок 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. Если у вас есть они в другом формате, либо укажите его, либо выполните поиск здесь и, возможно, 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
В моем случае я получил эту ошибку, когда закрытый ключ не соответствовал сертификату. Я обновил сертификат, когда срок действия моего истек, и мне нужно было создать новый закрытый ключ. Однако я забыл упомянуть об этом в своем приложении. Когда я указал на новый закрытый ключ - эта ошибка исчезла.