การแจ้งเตือน“ SSL3_READ_BYTES: sslv3 การแจ้งเตือนใบรับรองไม่ถูกต้อง” ระบุว่า 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)**

"การจับมือล้มเหลว" หมายถึงการจับมือล้มเหลวและไม่มีการเชื่อมต่อ SSL / TLS คุณจะเห็นว่าopensslออกจากเชลล์ (หรือ CMD ฯลฯ ) และไม่รอให้ป้อนข้อมูลที่จะส่งไปยังเซิร์ฟเวอร์ "ตรวจสอบรหัสส่งคืน 0" หมายความว่าไม่พบปัญหาในใบรับรองของเซิร์ฟเวอร์เพราะไม่ได้ทำการตรวจสอบเลยหรือตรวจสอบแล้วและดี (เท่าที่การตรวจสอบของ OpenSSL ไปซึ่งไม่ครอบคลุมทุกอย่าง) ในกรณีนี้โดยรู้ว่าโปรโตคอลเราสามารถอนุมานกรณีหลังใช้

การรับการแจ้งเตือนbad certificate (รหัส 42) หมายความว่าเซิร์ฟเวอร์ต้องการให้คุณตรวจสอบความถูกต้องด้วยใบรับรองและคุณไม่ได้ทำเช่นนั้นและทำให้เกิดการจับมือล้มเหลว สองสามบรรทัดก่อนถึงบรรทัดที่SSL handshake has read ... and written ...คุณควรเห็นบรรทัดAcceptable client certificate CA namesมักตามด้วยหลายบรรทัดที่ระบุ CAs อาจตามด้วยการขึ้นบรรทัดใหม่Client Certificate TypesและอาจRequested Signature Algorithmsขึ้นอยู่กับรุ่น OpenSSL และโปรโตคอลที่ต่อรองของคุณ

ค้นหาใบรับรองที่ออกโดย CA ในรายการ 'ที่ยอมรับได้' หรือถ้าเอกสารนั้นว่างเปล่าให้ค้นหาเอกสารเกี่ยวกับหรือเกี่ยวกับเซิร์ฟเวอร์ที่บอกว่า CA ใดที่เชื่อถือหรือติดต่อผู้ให้บริการเซิร์ฟเวอร์หรือเจ้าของเซิร์ฟเวอร์และถามพวกเขารวมถึงคีย์ส่วนตัวที่ตรงกันทั้งคู่ ในรูปแบบ PEM และระบุด้วย-cert $file -key $file; หากคุณมีทั้งไฟล์เดียวเป็นไปได้กับ PEM เพียงใช้-cert $file. หากคุณมีพวกเขาในรูปแบบที่แตกต่างกันทั้งระบุหรือค้นหาที่นี่และอาจจะ superuser และ security.SX; มีคำถาม & คำตอบมากมายเกี่ยวกับการแปลงใบรับรองและรูปแบบคีย์ส่วนตัวต่างๆ หากใบรับรองของคุณต้องการใบรับรอง "ห่วงโซ่" หรือ "ขั้นกลาง" (หรือมากกว่าหนึ่งรายการ) ที่จะตรวจสอบซึ่งมักจะเป็นกรณีสำหรับใบรับรองจาก CA สาธารณะ (เทียบกับใบรับรองภายใน) ขึ้นอยู่กับวิธีกำหนดค่าเซิร์ฟเวอร์s_clientต้องการเคล็ดลับ: เพิ่มใบรับรองลูกโซ่ลงในระบบ truststore ของคุณหรือสร้าง truststore แบบโลคัล / ชั่วคราวที่มีใบรับรอง CA ที่คุณต้องการเพื่อตรวจสอบเซิร์ฟเวอร์รวมถึงใบรับรองลูกโซ่ที่คุณต้องการส่ง

หากคุณไม่มีใบรับรองเช่นนั้นคุณจำเป็นต้องได้รับหนึ่งซึ่งเป็นคำถามที่แตกต่างกันที่ต้องการรายละเอียดเพิ่มเติมเพื่อตอบหรือคุณต้องการค้นหาวิธีการเชื่อมต่อกับเซิร์ฟเวอร์โดยไม่ต้องใช้การรับรองความถูกต้องของใบรับรอง ตรวจสอบเอกสารอีกครั้งและ / หรือถามผู้ประกอบการ / เจ้าของ

แก้ไข: มันปรากฏขึ้นจากความคิดเห็นที่คุณอาจมีไคลเอนต์คีย์และใบรับรองโซ่เช่นเดียวกับที่ยึดเซิร์ฟเวอร์ (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

ในกรณีของฉันฉันพบข้อผิดพลาดนี้เมื่อคีย์ส่วนตัวไม่ตรงกับใบรับรอง ฉันได้อัปเดตใบรับรองเมื่อฉันหมดอายุและจำเป็นต้องสร้างรหัสส่วนตัวใหม่ อย่างไรก็ตามฉันลืมอ้างอิงในแอปของฉัน เมื่อฉันชี้ไปที่คีย์ส่วนตัวใหม่ - ข้อผิดพลาดนี้หายไป