ฉันกำลังค่อยๆ เปลี่ยนจากบทบาทนักพัฒนาเฉพาะและไปสู่บทบาท DevOps แบบไฮบริดที่บริษัทของฉันมากขึ้น ซึ่งหมายความว่าฉันยังใหม่กับสิ่งนี้ โปรดไปกับฉัน... :-p
เซิร์ฟเวอร์ของลูกค้าของฉันใช้งาน Ubuntu 16.04 พร้อม PHP 5.6.4 และมีฟังก์ชันในพอร์ทัลการดูแลระบบของไซต์ที่เรียกใช้ ขด คำสั่ง (เป็นหลัก) กลับไปที่ตัวเองสำหรับการซิงค์ไฟล์บางประเภท และล้มเหลวมาระยะหนึ่งแล้ว (สองสามสัปดาห์/เดือน) ปัญหา (I คิด) คือการตรวจสอบใบรับรองล้มเหลว ดังนั้น ฟังก์ชันกำลังจะตายในเถาวัลย์
เมื่อฉัน ssh เข้าสู่เซิร์ฟเวอร์ ฉันสามารถขดตัวไปที่ใดก็ได้อย่างง่ายดายโดยไม่มีปัญหา (Google, example.org ฯลฯ...) แต่พยายามเพียงแค่ curl พื้นฐานไปยัง url หลักของเว็บไซต์ บอร์ค.
$ curl -v https://www.[ชื่อเว็บไซต์ของฉัน].com
* ลอง [my-site-IP]...
* เชื่อมต่อกับ [my-site-name] ([my-site-IP]) พอร์ต 443 (#0)
* พบใบรับรอง 258 รายการใน /etc/ssl/certs/ca-certificates.crt
* พบ 908 ใบรับรองใน /etc/ssl/certs/
* ALPN ให้บริการ http/1.1
* การเชื่อมต่อ SSL โดยใช้ TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* การตรวจสอบใบรับรองเซิร์ฟเวอร์ล้มเหลว CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: ไม่มี
* ปิดการเชื่อมต่อ 0
curl: (60) การตรวจสอบใบรับรองเซิร์ฟเวอร์ล้มเหลว CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: ไม่มี
รายละเอียดเพิ่มเติมที่นี่: http://curl.haxx.se/docs/sslcerts.html
curl ทำการตรวจสอบใบรับรอง SSL ตามค่าเริ่มต้น โดยใช้ "บันเดิล"
ของคีย์สาธารณะของผู้ออกใบรับรอง (CA) (ใบรับรอง CA) ถ้าค่าเริ่มต้น
ไฟล์บันเดิลไม่เพียงพอ คุณสามารถระบุไฟล์อื่นได้
โดยใช้ตัวเลือก --cacert
หากเซิร์ฟเวอร์ HTTPS นี้ใช้ใบรับรองที่ลงนามโดย CA ที่เป็นตัวแทน
บันเดิล การตรวจสอบใบรับรองอาจล้มเหลวเนื่องจากก
ปัญหาเกี่ยวกับใบรับรอง (ใบรับรองอาจหมดอายุหรือชื่ออาจ
ไม่ตรงกับชื่อโดเมนใน URL)
หากคุณต้องการปิดการตรวจสอบใบรับรองของ curl ให้ใช้
ตัวเลือก -k (หรือ --insecure)
ฉันรู้ว่าฉันสามารถเรียกใช้ขดกับ -k ถึงจะไม่ปลอดภัยแต่ฉันก็ลังเลที่จะทำเช่นนั้น ฉันเดาว่าคำถามแรกคือฉันไม่ควรกังวลเกี่ยวกับการรันสิ่งนี้ด้วยแฟล็กที่ไม่ปลอดภัยเนื่องจากทางเทคนิคไม่ได้ออกจากเซิร์ฟเวอร์เลย ฉันได้ทดสอบคำสั่ง curl เดียวกันนี้บนหนึ่งในกล่องใหม่ของเราที่ใช้ Ubuntu 18.x และบน DigitalOcean ที่ใช้ v20 โดยไม่มีปัญหาเลย ทั้งการม้วนภายนอกและภายในทำงานได้ดีมาก
ฉันยังสามารถอยู่บนเซิร์ฟเวอร์อื่นและขดตัวกลับไปหาเซิร์ฟเวอร์ที่ประสบปัญหา ซึ่งนั่นก็ใช้ได้ดีเช่นกัน
ฉันลองทุกอย่างที่นึกออกแล้ว (ซึ่งยอมรับว่าไม่มาก) และดูเหมือนจะไม่มีอะไรทำงาน
update-ca-ใบรับรองcurl.cainfo และ opensl.cafile vars ใน php.iniฉันรู้ว่าสิ่งนี้อาจไม่สำคัญ แต่เพื่อความสมบูรณ์ ฉันยังได้เรียกใช้ไซต์ผ่านบริการยืนยันออนไลน์ต่างๆ:
ทั้งหมดกลับมาพร้อมกับผลลัพธ์ที่เป็นบวก ข้อเสียเพียงอย่างเดียว (ฉันเดา) คือ SSLLabs ให้คะแนนเราด้วย 'B' เพราะเห็นได้ชัดว่า TLS 1.0 ยังเปิดใช้งานอยู่
ความช่วยเหลือใด ๆ ที่จะได้รับการชื่นชมอย่างมาก. ฉันรู้สึกว่าการอ่านเอกสารที่กล่าวถึงในคำเตือนความล้มเหลวนั้นไม่ได้มีประโยชน์อะไรเลย
ข้อเสนอแนะ / เคล็ดลับ / เทคนิค ??
1,000 ขอบคุณล่วงหน้า!
Meta: ยังไม่ใช่คำตอบ อย่างน้อยก็ยังไม่มี แต่ข้อมูลและคำแนะนำบางอย่าง
โอเค กรณีง่ายใช้ไม่ได้ เท่าที่เคยเจอมา ขด ไม่ให้ข้อมูลที่เป็นประโยชน์มากนักเมื่อได้รับข้อผิดพลาดในการยืนยันใบรับรองจากสแต็ก SSL/TLS พื้นฐาน อย่างน้อยก็เมื่อใช้ GnuTLS เช่นเดียวกับที่ Ubuntu สร้างขึ้น อย่างไรก็ตาม OpenSSL (ซึ่งควรมีอยู่เพราะ curl มีการพึ่งพา แต่ฉันไม่เห็นว่าทำไม) ให้โปรแกรม commandline ชื่อง่ายๆ opensl ซึ่งส่วนใหญ่จะเป็นเครื่องมือทดสอบ และค่อนข้างละเอียดกว่าและทนต่อข้อผิดพลาดได้มากกว่า ตัวอย่างเช่น บนไซต์ที่จงใจให้ร้าย ในเวอร์ชันนักเทียบท่าของ Ubuntu 16.04:
# curl -v https://unrusted-root.badssl.com/
* ลอง 104.154.89.105...
* เชื่อมต่อกับพอร์ตที่ไม่น่าเชื่อถือ root.badssl.com (104.154.89.105) 443 (#0)
* พบใบรับรอง 129 รายการใน /etc/ssl/certs/ca-certificates.crt
* พบใบรับรอง 516 รายการใน /etc/ssl/certs
* ALPN ให้บริการ http/1.1
* การเชื่อมต่อ SSL โดยใช้ TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* การตรวจสอบใบรับรองเซิร์ฟเวอร์ล้มเหลว CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: ไม่มี
* ปิดการเชื่อมต่อ 0
curl: (60) การตรวจสอบใบรับรองเซิร์ฟเวอร์ล้มเหลว CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: ไม่มี
รายละเอียดเพิ่มเติมที่นี่: http://curl.haxx.se/docs/sslcerts.html
[snip ข้อความกระป๋อง -- เช่นเดียวกับของคุณ]
# openssl s_client -เชื่อมต่อที่ไม่น่าเชื่อถือ root.badssl.com:443 -ชื่อเซิร์ฟเวอร์ไม่น่าเชื่อถือ root.badssl.com
เชื่อมต่อแล้ว(00000003)
ความลึก=1 C = สหรัฐอเมริกา ST = แคลิฟอร์เนีย L = ซานฟรานซิสโก O = BadSSL CN = BadSSL ผู้ออกใบรับรองหลักที่ไม่น่าเชื่อถือ
ตรวจสอบข้อผิดพลาด: num=19: ใบรับรองที่ลงนามด้วยตนเองในห่วงโซ่ใบรับรอง
---
ห่วงโซ่ใบรับรอง
0 วินาที:/C=US/ST=แคลิฟอร์เนีย/L=ซานฟรานซิสโก/O=BadSSL/CN=*.badssl.com
i:/C=US/ST=California/L=San Francisco/O=BadSSL/CN=BadSSL ผู้ออกใบรับรองหลักที่ไม่น่าเชื่อถือ
1 วินาที:/C=US/ST=แคลิฟอร์เนีย/L=ซานฟรานซิสโก/O=BadSSL/CN=BadSSL ผู้ออกใบรับรองหลักที่ไม่น่าเชื่อถือ
i:/C=US/ST=California/L=San Francisco/O=BadSSL/CN=BadSSL ผู้ออกใบรับรองหลักที่ไม่น่าเชื่อถือ
---
ใบรับรองเซิร์ฟเวอร์
-----เริ่มต้นใบรับรอง-----
MIIEmTCCAoGgAwIBAgIJAMJ1vCpOBAlkMA0GCSqGSIb3DQEBCwUAMIGBMQswCQYD
VQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5j
aXNjbzEPMA0GA1UECgwGQmFkU1NMMTQwMgYDVQQDDCtCYWRTU0wgVW50cnVzdGVk
IFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTIxMTIwNDAwMDgxOVoXDTIz
MTIwNDAwMDgxOVowYjELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWEx
FjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xDzANBgNVBAoMBkJhZFNTTDEVMBMGA1UE
AwwMKi5iYWRzc2wuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
wgTs+IzuBMKz2FDVcFjMkxjrXKhoSbAitfmVnrErLHY+bMBLYExM6rK0wA+AtrD5
csmGAvlcQV0TK39xxEu86ZQuUDemZxxhjPZBQsVG0xaHJ5906wqdEVImIXNshEx5
VeTRA+gGPUgVUq2zKNuq/27/YJVKd2s58STRMbbdTcDE/FO5bUKttXz+rvUV0jNI
5yJxx8IUemwo6jdK3+pstXK0flqiFtxpsVdE2woSq97DD0d0XEEi4Zr5G5PmrSIG
KS6xukkcDCeeo/uL90ByAKySCNmMV4RTgQXL5v5rVJhAJ4XHELtzcO9pGEEHRVV8
+WQ/PSzDqXzrkxpMhtHKhQIDAQABozIwMDAJBgNVHRMEAjAAMCMGA1UdEQQcMBqC
DCouYmFkc3NsLmNvbYIKYmFkc3NsLmNvbTANBgkqhkiG9w0BAQsFAAOCAgEADVgB
Ias+fb/Ckdnw5iSYsfRIcfhnTBNgvroorUQe09Psx0tAbjlIYqOCtloNhvCbJYa7
tQQOO65s7RKArpAA1qoapWfDti2aHuMNvGwImwX538RiLf4Rm4MEF6vuF6MZMH/u
Ts1iugB3+d7oSWl/K+RvA4NMRNrlxOLelBJwaTsExsQ5QalpปามงนีWXHZ2Sna
dsw9hBku9ZmlRqYOCE/TajsydqCIhCc2QC5xdd3fxXlcfq5h7G0oOuCYvW7BscTk
AQZYkwS+y3mTHF9wSlxJB4iEGC0NovdM5GsVgfvZ5+jtXGuDlsphaAIFLxpIJi1bR
+NsAkEthHoQZDNttvtVJPFPp83PdRDmL6IwrbbXvAwZWWgYmS6HpbF5bxR09JIOA
KttGK1wnd6bh2d9Xy6kfoxZ1gz6i2y5OpxbMoi6z8o1Y2hSOv2kgnD2fxtR9X4OO
wrwWZWnhwsiq7pnZbZiA9GFR4tKZVcJ5ny5aul/MZ0wb5MST7wHW/7qhydfBpOy6
hZ5BSbwfmBao+CJ7NxNJb5c03W5+/Vf1uxXZhodpag6Z5p0rru0v7ea9nMk5dNUm
qR+2XGwzDk9n8jCWwfvSKCa77rf2HqKi8ZaQN/NRp7uVqfY++JVI+h3CLyMk8wTL
FifbLPKbSCW7PAFEfM3wh76VQg1CHpHOPVp/wno=
-----จบใบรับรอง-----
เรื่อง=/C=US/ST=แคลิฟอร์เนีย/L=ซานฟรานซิสโก/O=BadSSL/CN=*.badssl.com
ผู้ออก=/C=US/ST=แคลิฟอร์เนีย/L=ซานฟรานซิสโก/O=BadSSL/CN=BadSSL ผู้ออกใบรับรองหลักที่ไม่น่าเชื่อถือ
---
ไม่มีการส่งชื่อ CA ของใบรับรองไคลเอ็นต์
สรุปการลงนามเพียร์: SHA512
คีย์อุณหภูมิเซิร์ฟเวอร์: ECDH, P-256, 256 บิต
---
SSL handshake อ่าน 3561 ไบต์และเขียน 425 ไบต์
---
ใหม่, TLSv1/SSLv3, การเข้ารหัสคือ ECDHE-RSA-AES128-GCM-SHA256
รหัสสาธารณะของเซิร์ฟเวอร์คือ 2048 บิต
รองรับการเจรจาต่อรองใหม่อย่างปลอดภัย
การบีบอัด: ไม่มี
การขยายตัว: ไม่มี
ไม่มีการเจรจา ALPN
เซสชัน SSL:
โปรโตคอล : TLSv1.2
รหัส : ECDHE-RSA-AES128-GCM-SHA256
รหัสเซสชัน: AC5EB655FAEA1C1A320CA930E6A087FBFE020D3D9C451A72DD7CE77A8080AF0D
เซสชัน-ID-ctx:
มาสเตอร์คีย์: 419065F69901D74454A224DD22F9D459FA85E6EB4D6F043C649C8FDFA2E5E1FD9C168AC270087B88511B0939927F9A0A
คีย์อาร์กิวเมนต์ : ไม่มี
ตัวตน PSK: ไม่มี
คำใบ้ประจำตัว PSK: ไม่มี
ชื่อผู้ใช้ SRP: ไม่มี
คำแนะนำอายุการใช้งานตั๋วเซสชัน TLS: 300 (วินาที)
ตั๋วเซสชั่น TLS:
0000 - ซีซี 91 34 52 b1 ce c6 7c-8a 97 27 b0 b4 50 d6 9d ..4R...|..'..P..
0010 - 27 b8 87 13 0b 70 92 e7-23 เป็น 57 5c 00 31 f7 90 '....p..#.W\.1..
0020 - 65 e3 08 d5 63 14 e9 cd-cc 50 59 3f 2a 98 31 d1 e...c....PY?*.1.
0030 - ab f8 ca a8 09 aa 66 bf-7c ff b6 66 42 10 8b 6e ...... ฉ.|..fB..n
0040 - c7 e8 7b f3 2b 35 b3 76-8c 95 b3 b5 37 85 09 42 ..{.+5.v....7..B
0050 - 83 a9 c3 f7 54 f4 c5 f5-b2 0d d5 fa c6 24 a6 e2 ....T........$..
0060 - fb 03 cf 35 9c 0d cc 48-e0 bc fc 43 11 3c 19 51 ...5...H...C.<.Q
0070 - 0a 23 7d b2 6c ff 9b e2-bc 64 1d 74 34 cb 13 7b .#}.l....d.t4..{
0080 - c8 55 47 95 71 9d 94 00-33 a0 a0 87 d4 4a fb 81 .UG.q...3....J..
0090 - 34 36 28 2e ac d7 22 36-36 5f 9c cb 3f 0d e7 00 46(..."66_..?...
00a0 - e2 b7 d0 35 48 81 2f c7-9d a1 8a f6 52 a3 11 17 ...5H./.....R...
00b0 - 67 89 94 d3 66 2b 5c c4-73 c5 72 1e 84 46 57 a5 g...f+\.s.r..FW.
00c0 - 77 05 bc 49 a3 1a fe e6-da a8 0f 40 e2 17 f0 40 w..I.......@...@
เวลาเริ่มต้น: 1644060097
หมดเวลา : 300 (วินาที)
ตรวจสอบรหัสส่งคืน: 19 (ใบรับรองที่ลงนามด้วยตนเองในห่วงโซ่ใบรับรอง)
---
ถาม
เสร็จแล้ว
สังเกตว่าผลลัพธ์แรกหลังจาก เชื่อมต่อแล้ว ไลน์: ความลึก=1 ... / ตรวจสอบข้อผิดพลาด:num=19:.... บ่งชี้ว่าการตรวจสอบใบรับรองล้มเหลว อย่างไรก็ตาม opensl ละเว้นข้อผิดพลาดนี้และทำการจับมือกันให้เสร็จสิ้น ส่งผลให้ส่วนสุดท้ายของเอาต์พุต: เซสชัน SSL: / โปรโตคอล: (ถูกต้อง) / การเข้ารหัส: (ถูกต้อง) / ... / ตรวจสอบรหัสส่งคืน: ... หลังจากนั้นคุณต้องพิมพ์ ถาม และย้อนกลับหรือ control-D (เพียงอย่างเดียว) เพื่อออกจากโปรแกรม หรือ control-C เพื่อ kill เว้นแต่คุณจะเพิ่ม </dev/null บน commandline ซึ่งมีผลเหมือนกับการพิมพ์ control-D โดยอัตโนมัติ สำหรับตอนนี้ คุณไม่จำเป็นต้องเข้าใจค่าเฉพาะของ Protocol และ Cipher เพียงแต่ว่าค่าเหล่านี้ไม่ใช่ค่า 'none' หรือ 'error' หรือ 'missing'
แต่ขอเตือนไว้ก่อนว่าข้อความของ OpenSSL สำหรับ Verify=19 นั้นไม่สมบูรณ์จนเกิดความสับสน เป็นเรื่องปกติอย่างยิ่งที่ห่วงโซ่ใบรับรองจากเซิร์ฟเวอร์ SSL/TLS จะรวมใบรับรองรูทซึ่งลงนามด้วยตนเอง และ หากรูทนั้นอยู่ใน truststore ในเครื่อง OpenSSL ทำ (และแน่นอน curl/GnuTLS ควร) ยอมรับห่วงโซ่ดังกล่าว ก็ต่อเมื่อรูทอยู่ในห่วงโซ่และไม่น่าเชื่อถือในเครื่องเท่านั้นที่คุณจะได้รับรหัสยืนยันนี้ รหัสยืนยันอื่นๆ เช่น 'หมดอายุ' จะมีข้อความที่ชัดเจนกว่าเป็นส่วนใหญ่
โปรดทราบว่าฉันใช้ -ชื่อเซิร์ฟเวอร์ ด้วยชื่อโฮสต์; สิ่งนี้เรียก SNI=ตัวระบุชื่อเซิร์ฟเวอร์ ซึ่งปัจจุบันมีเซิร์ฟเวอร์ SSL/TLS จำนวนมาก รวมถึง badssl.คอมจำเป็นต้องให้บริการใบรับรองที่ถูกต้อง อย่างไรก็ตาม เวอร์ชันของ curl ใน Ubuntu16.04 ไม่ส่ง SNI; หากไม่มีการวิจัยฉันไม่รู้ว่าเป็นเพราะ curl เวอร์ชันเก่ากว่าเล็กน้อย (แต่ไม่มาก) การใช้ GnuTLS หรือเป็นเพียงความผิดพลาดในการสร้าง แต่อย่างไรก็ตาม เป็นการทดสอบลอง เดอะ openssl s_client สั่งกับเซิร์ฟเวอร์ของคุณทั้งที่มีและไม่มี - โฮสต์ชื่อเซิร์ฟเวอร์ part และบันทึกเอาต์พุต (ด้วย redirection หรือ tee ควรรวม stderr ด้วย &> หรือ |&ที หรือเทียบเท่า) เพราะเราอาจต้องการ หากเวอร์ชันที่มี SNI ใช้งานได้ และเวอร์ชันที่ไม่มี SNI ได้รับข้อผิดพลาดในการยืนยัน นั่นคือปัญหาของคุณ นั่นคือการขาด SNI (มันอาจจะแก้ไขได้ยาก แต่อย่างน้อยคุณก็รู้ว่ามันคืออะไร)
มิฉะนั้น ให้ดูผลลัพธ์ที่ไม่มี SNI หาก OpenSSL รายงานข้อผิดพลาดในการยืนยัน (เห็นด้วยกับ curl/GnuTLS) ให้ดูที่ข้อความที่เกี่ยวข้อง อย่างน้อยก็ควรชี้ไปในทิศทางของปัญหา หากไม่ตรงกัน หาก OpenSSL รายงานว่าไม่มีข้อผิดพลาดในการยืนยัน (โดยที่ curl/GnuTLS ทำ ทั้งคู่ใช้ truststore ที่ระบบจัดหาให้เหมือนกันใน /etc/ssl) มันจะซับซ้อนกว่านี้ ดังนั้นฉันจะปล่อยไว้ตอนนี้ และเพิ่มในภายหลังหากจำเป็น
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
