ทำความเข้าใจเกี่ยวกับผลลัพธ์ของ openssl s

14

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

ในระหว่างการสอบสวนความสนใจของฉันถูกดึงไปยังความแตกต่างในเอาต์พุตของสองคำสั่งต่อไปนี้ (ฉันได้ลบใบรับรองออกจากเอาต์พุตเพื่อให้สามารถอ่านได้):

echo "" | openssl s_client -showcerts -connect pop.gmail.com:995

เชื่อมต่อ (00000003)
ความลึก = 2 / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
ยืนยันข้อผิดพลาด: num = 20: ไม่สามารถรับใบรับรองผู้ออกในท้องถิ่น
ยืนยันผลตอบแทน: 0
---
ห่วงโซ่ใบรับรอง
 0 s: / C = US / ST = California / L = Mountain View / O = Google Inc / CN = pop.gmail.com
   i: / C = US / O = Google Inc / CN = Google Internet Authority G2
----- เริ่มต้นใบรับรอง -----
----- สิ้นสุดใบรับรอง -----
 1 s: / C = US / O = Google Inc / CN = Google Internet Authority G2
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
----- เริ่มต้นใบรับรอง -----
----- สิ้นสุดใบรับรอง -----
 2 s: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
   i: / C = US / O = Equifax / OU = Equifax Secure Certificate Authority
----- เริ่มต้นใบรับรอง -----
----- สิ้นสุดใบรับรอง -----
---
ใบรับรองเซิร์ฟเวอร์
หัวเรื่อง = / C = US / ST = แคลิฟอร์เนีย / L = Mountain View / O = Google Inc / CN = pop.gmail.com
ผู้ออก = / C = US / O = Google Inc / CN = ผู้ให้บริการอินเทอร์เน็ตของ Google G2
---
ไม่มีการส่งชื่อไคลเอ็นต์ใบรับรอง CA
---
SSL handshake อ่าน 3236 ไบต์และเขียน 435 ไบต์
---
ใหม่ TLSv1 / SSLv3 รหัสคือ RC4-SHA
รหัสสาธารณะของเซิร์ฟเวอร์คือ 2048 บิต
รองรับการเจรจาต่อรองอย่างปลอดภัย
การบีบอัด: ไม่มี
การขยายตัว: ไม่มี
SSL-เซสชัน:
    โปรโตคอล: TLSv1
    รหัส: RC4-SHA
    รหัสเซสชัน: 745F84194498529B91B7D9194363CBBD23425446CF2BFF3BF5557E3C6606CA06
    เซสชัน ID-ctx:
    มาสเตอร์คีย์: DED1AE0A44609F9D6F54626F4370ED96436A561A59F64D66240A277066322DCD2CCB9A6D198C95F4D7B67C7E67D
    Key-Arg: ไม่มี
    เวลาเริ่มต้น: 1397678434
    หมดเวลา: 300 (วินาที)
    ยืนยันรหัสส่งคืน: 20 (ไม่สามารถรับใบรับรองผู้ออกในท้องถิ่น)
---
+ ตกลง Gpop พร้อมรับคำขอจาก 69.3.61.10 c13mb42148040pdj
DONE

echo "" | openssl s_client -showcerts -connect secure.emailsrvr.com:995

เชื่อมต่อ (00000003)
ความลึก = 2 / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
ตรวจสอบข้อผิดพลาด: num = 19: ใบรับรองที่ลงนามเองในห่วงโซ่ใบรับรอง
ยืนยันผลตอบแทน: 0
---
ห่วงโซ่ใบรับรอง
 0 s: / serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU = ดู www.rapidssl.com/resources/cps (c) 14 / OU = การควบคุมโดเมนที่ตรวจสอบแล้ว - RapidSSL (R) /CN=secureem
   i: / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
----- เริ่มต้นใบรับรอง -----
----- สิ้นสุดใบรับรอง -----
 1 s: / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
----- เริ่มต้นใบรับรอง -----
----- สิ้นสุดใบรับรอง -----
 2 s: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
----- เริ่มต้นใบรับรอง -----
----- สิ้นสุดใบรับรอง -----
---
ใบรับรองเซิร์ฟเวอร์
หัวเรื่อง = / serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU = ดู www.rapidssl.com/resources/cps (c) 14 / OU = การควบคุมโดเมนผ่านการตรวจสอบ - RapidSSL (R) /CN =secure.rrv
ผู้ออก = / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
---
ไม่มีการส่งชื่อไคลเอ็นต์ใบรับรอง CA
---
SSL handshake อ่าน 3876 ไบต์และเขียน 319 ไบต์
---
ใหม่ TLSv1 / SSLv3 รหัสคือ DHE-RSA-AES256-SHA
รหัสสาธารณะของเซิร์ฟเวอร์คือ 2048 บิต
รองรับการเจรจาต่อรองอย่างปลอดภัย
การบีบอัด: ไม่มี
การขยายตัว: ไม่มี
SSL-เซสชัน:
    โปรโตคอล: TLSv1
    รหัส: DHE-RSA-AES256-SHA
    Session-ID: 3F4EE3992B46727BE2C7C3E76A9A6A8A64D64D66EE843CB1BB17A76AE2E030C7161
    เซสชัน ID-ctx:
    รหัสหลัก: 016209E50432EFE2359DB73AB527AF718152BFE6F88215A9CE40604E8FF2E2A3AC97A175F46DF737596866A8BC8E3F7F
    Key-Arg: ไม่มี
    เวลาเริ่มต้น: 1397678467
    หมดเวลา: 300 (วินาที)
    ยืนยันรหัสส่งคืน: 19 (ใบรับรองที่ลงนามเองในห่วงโซ่ใบรับรอง)
---
DONE

ฉันพยายามเข้าใจว่าสิ่งนี้มีความหมายหรือไม่เพราะเมื่อมีการจัด-CApathเตรียมตัวเลือกไว้คำสั่งจะไม่สร้างข้อผิดพลาดใด ๆ :

openssl s_client -CApath /etc/ssl/certs -showcerts -connect secure.emailsrvr.com:995

CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = "GeoTrust, Inc.", CN = RapidSSL CA
verify return:1
depth=0 serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ/dD, OU = 4159320284, OU = See www.rapidssl.com/resources/cps (c)14, OU = Domain Control Validated - RapidSSL(R), CN = secure.emailsrvr.com
verify return:1
...

openssl s_client -CApath /etc/ssl/certs -showcerts -connect pop.gmail.com:995

CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = pop.gmail.com
verify return:1
...

ฉันยังสามารถใช้-CAfileตัวเลือกสำเร็จหลังจากดาวน์โหลดใบรับรอง CAfileโดยตรงจาก GeoTrust

อย่างไรก็ตาม Fog Creek ดูเหมือนว่าจะคิดว่าปัญหาอยู่ที่ใบรับรองเพราะพวกเขาได้ลองเพิ่มใบรับรองในTrustร้านของโมโนโดยไม่ประสบความสำเร็จ ฉันจะไม่เห็นด้วยกับพวกเขา แต่ (ดังกล่าวข้างต้น) ในขณะที่ตัวตรวจสอบ SSL ส่วนใหญ่ไม่ตรวจสอบพอร์ต 995 หรือประสบความสำเร็จในระหว่างการพยายามฉันพบหน้านี้ที่สร้างข้อผิดพลาด SSL 7

ฉันจะตีความผลลัพธ์ที่ถูกต้องเพื่อหมายความว่าไม่มีอะไรผิดปกติกับใบรับรองหรือไม่

ssl-certificate openssl

— jobu1324
แหล่งที่มา

2

ฉันคิดว่าข้อผิดพลาด "ใบรับรองที่ลงชื่อด้วยตนเองในห่วงโซ่ใบรับรอง" เป็นปลาเฮอริ่งแดง CA หลักจะลงนามด้วยตนเองเสมอดังนั้นเซิร์ฟเวอร์ที่ส่งคืนเชนใบรับรองแบบเต็มจะส่งคืนใบรับรองที่เซ็นชื่อเองเสมอ ข้อมูลเพิ่มเติมที่นี่

— bennettp123

2

ที่จริงแล้วดูเหมือนopenssl s_clientจะไม่นำเข้ารูทไฟล์ใด ๆ โดยค่าเริ่มต้น ลองใช้สิ่งนี้แทน: openssl s_client -connect secure.emailsrvr.com:995 -showcerts -CApath /etc/ssl/certsและคุณอาจพบว่าข้อผิดพลาดที่ลงนามเองหายไป

— bennettp123

@ bennettp123 ฉันบันทึกผลลัพธ์ของคำสั่งนั้นไว้ที่ด้านล่างของคำถาม ฉันถูกต้องหรือไม่ที่จะเข้าใจเอาต์พุตของทั้งสองเวอร์ชันของคำสั่งเพื่อหมายความว่าใบรับรองนั้นถูกต้อง?

— jobu1324

ใช่ตามที่เอาท์พุท openssl คิดว่าใบรับรองนั้นถูกต้อง ทำไมมันถูกปฏิเสธ ฉันไม่รู้ อาจเป็นเพราะฟิลด์องค์กรไม่ได้ตั้งค่า แต่เป็นเพียงการเดา

— bennettp123

5

คำตอบ (ตามที่อธิบายไว้ในการรักษาความปลอดภัยนี้โพสต์ SEE ) คือใบรับรองGeoTrust Global CAสองใบรับรองที่คุณเห็นในกลุ่มนั้นไม่ได้เป็นใบรับรองเดียวกันแต่อย่างใดอย่างหนึ่งมาจากใบรับรองอื่น

เพราะ CA การลงนามข้าม!

เมื่อสร้างและลงชื่อใบรับรอง GeoTrust Global CA เป็นครั้งแรกจะไม่มีคอมพิวเตอร์ / เบราว์เซอร์ / แอปพลิเคชันในที่เก็บข้อมูลที่เชื่อถือได้

ด้วยการมีCA อื่น (ที่มีชื่อเสียงและการกระจายอยู่แล้ว) ลงนามในใบรับรอง GeoTrust root CA ใบรับรองผลที่ได้ (เรียกว่า "สะพาน" ใบรับรอง) ตอนนี้สามารถตรวจสอบโดย CA ที่สองโดยไม่ต้องมีใบรับรอง CA ราก GeoTrust ที่จะได้รับความไว้วางใจจากลูกค้าอย่างชัดเจน

เมื่อ Google นำเสนอใบรับรอง CA root ของ GeoTrust รุ่นไขว้ลูกค้าที่ไม่ไว้วางใจต้นฉบับสามารถใช้ใบรับรอง Equifax CA เพื่อตรวจสอบ GeoTrust ดังนั้น Equifax จึงทำหน้าที่เป็นจุดยึดความไว้วางใจ "แบบดั้งเดิม"

— Mathias R. Jessen
แหล่งที่มา

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

— dave_thompson_085

0

ปัญหาที่คล้ายกันมีกับ fetchmail เมื่อฉันเปิดใช้งาน SSL pop.gmail.comสำหรับการตรวจสอบ

ฉันดาวน์โหลดไฟล์ Equifax pem แต่มันไม่ทำงานเหมือนเดิมต้องทำงานc_rehash ssl/certsซึ่งสร้างลิงค์สัญลักษณ์ที่มีค่าแฮชจากนั้นก็ใช้งานได้

หรืออาจจะรู้จักค่าแฮชด้วยการเรียกใช้ ...

openssl x509 -in Equifax_Secure_Certificate_Authority.pem -fingerprint -subject -issuer -serial -hash -noout | sed  -n /^[0-9]/p

https://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Certificate_Authority.pem

— chetangb
แหล่งที่มา

คุณช่วยขยายเพิ่มเติมเกี่ยวกับไฟล์ pem ที่เชื่อมโยงได้ไหม

— sebix

# ldd / usr / bin / fetchmail | grep ssl libssl.so.10 => /lib64/libssl.so.10

— chetangb

สิ่งที่ฉันอ่านบางครั้งคือ fetchmail ใช้ openssl libs และจะดูเฉพาะค่าแฮชของ cert productforums.google.com/forum/#!topic/gmail/tqjOmqxpMKY # ldd / usr / bin / fetchmail grep ssl libssl.so.10 => /lib64/libssl.so.10 yum whatprovides libssl.so.10 openssl-libs-1.0.1e-42.el7.i686: ไลบรารีการเข้ารหัสวัตถุประสงค์ทั่วไปที่มีการใช้ TLS Repo: ฐานตรงกัน จาก: ให้: libssl.so.10

— chetangb

โปรดขยายคำตอบของคุณและอธิบายปัญหาที่อาจเกิดขึ้นคุณต้องการบรรลุ

— sebix

0

ในขณะที่สร้างและกำหนดค่าใบรับรองหนึ่งควรอัปเดตopenssl.cnfไฟล์เช่นกัน (Debian - /etc/ssl/openssl.cnf) เพื่อระบุพา ธ ที่ถูกต้องชื่อใบรับรอง ฯลฯ จากนั้นคุณสามารถเรียกใช้คำสั่งและตรวจสอบโดยไม่มี-CApathตัวเลือก

และโฮสต์จากระยะไกลก็สามารถตรวจสอบใบรับรองของคุณได้อย่างถูกต้องในกรณีนี้

นี่คือopenssl.cnfส่วนที่เหมาะสม:

####################################################################
[ ca ]

default_ca  = CA_default        # The default ca section

####################################################################
[ CA_default ]

dir     = /etc/ssl

— user155270
แหล่งที่มา

1

นี่คือผิด default_caข้อมูลใน (ใด ๆ ) OpenSSL config ของไฟล์ที่ใช้เฉพาะสำหรับ 'Ca' ยูทิลิตี้ที่จะออกและใบรับรองเลือกเพิกถอนไม่เคยสำหรับการตรวจสอบ วิธีการเปลี่ยนที่เก็บการตรวจสอบเริ่มต้น (นอกเหนือจากการคอมไพล์ใหม่) อยู่กับตัวแปรสภาพแวดล้อม SSL_CERT_ {FILE, DIR} อย่างไรก็ตาม (1) เนื่องจากข้อผิดพลาดs_clientไม่ได้ใช้ค่าเริ่มต้น (แก้ไขการวางแผน ณ เดือนเมษายน 2015) ซึ่ง (2) OP นี้ไม่ต้องการเปลี่ยน

— dave_thompson_085

ทำความเข้าใจเกี่ยวกับผลลัพธ์ของ openssl s_client

เพราะ CA การลงนามข้าม!