"El sıkışma hatası", el sıkışmasının başarısız olduğu ve SSL / TLS bağlantısı olmadığı anlamına gelir. opensslKabuktan (veya CMD vb.) Çıkıldığını ve giriş verilerinin sunucuya gönderilmesini beklemediğini görmelisiniz . Hiçbir sorun olduğu anlamına gelir "dönüş kodu 0 doğrulama" bulundu , Sunucu sertifikasında ya da (OpenSSL çekleri kapak şeyi yok ki, gidip kadarıyla) hiç veya kontrol edildi çünkü kontrol ve iyi değildi çünkü; bu durumda protokolü bilerek ikinci durumun geçerli olduğunu çıkarabiliriz.
Uyarı almakbad certificate (kod 42) , sunucunun bir sertifika ile kimlik doğrulaması yapmanızı istediğini ve bunu yapmadığınızı ve el sıkışmasının başarısız olmasına neden olduğu anlamına gelir . Satırdan birkaç satır önce, genellikle CA'ları tanımlayan birkaç satır, muhtemelen bir satır başlangıcı ve belki de OpenSSL sürümünüze ve anlaşmalı protokole bağlı olarak SSL handshake has read ... and written ...bir satır görmelisiniz .Acceptable client certificate CA namesClient Certificate TypesRequested Signature Algorithms
'Kabul edilebilir' listesinde bir CA tarafından verilen bir sertifika bulun veya boşsa, hangi CA'lara güvendiğini söyleyen veya sunucuyla ilgili dokümanları arayın veya sunucu operatörleri veya sahipleriyle iletişim kurun ve onlara sorun, ayrıca eşleşen özel anahtarı , her ikisi de PEM biçiminde, ve bunları belirtmek ile -cert $file -key $file; eğer PEM ile mümkün olduğunca tek bir dosyada varsa,-cert $file. Bunları farklı bir biçimde kullanıyorsanız, belirtin veya burada ve belki de süper kullanıcı ve güvenlik arasında arama yapın. çeşitli sertifika ve özel formatları dönüştürme hakkında zaten birçok soru ve cevap var. Sertifikanızın doğrulanması için bir "zincir" veya "ara" sertifikasına (veya birden fazlasına) ihtiyacı varsa, sunucunun nasıl yapılandırıldığına bağlı olarak, genel bir CA'dan (dahili olana karşı) bir sertifikada olduğu gibi, s_clientbir hile gerektirir: ya zincir sertifikalarını sistem güven mağazanıza ekleyin ya da sunucu PLUS'u göndermeniz gereken zincir sertifikalarını doğrulamak için ihtiyacınız olan CA sertifikalarını içeren yerel / geçici bir güven deposu oluşturun.
Böyle bir sertifikanız yoksa ya bir sertifika almanız gerekir, bu da cevaplanması çok daha fazla ayrıntı gerektiren farklı bir sorudur ya da sertifika kimlik doğrulaması kullanmadan sunucuya bağlanmanın bir yolunu bulmanız gerekir; belgeleri tekrar kontrol edin ve / veya operatörlere / sahiplere sorun.
DÜZENLEME: Yorumdan, istemci anahtarının ve sertifika zincirinin yanı sıra Java'da sunucu bağlantı (ları) nız olabilir. Kontrol ederken, bu durumu tam olarak kapsayan iyi bir mevcut cevap görmüyorum, bu yüzden bu muhtemelen iyi arama yapmayacak olsa da:
# 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