แฮนด์เชค TLS/SSL ล้มเหลว

คุณกำลังดูเอกสารประกอบ Apigee Edge
ไปที่ เอกสารประกอบเกี่ยวกับ Apigee X. ข้อมูล

ลักษณะปัญหา

ความล้มเหลวในแฮนด์เชค TLS/SSL เกิดขึ้นเมื่อไคลเอ็นต์และเซิร์ฟเวอร์ไม่สามารถสร้างการสื่อสารโดยใช้ โปรโตคอล TLS/SSL เมื่อข้อผิดพลาดนี้เกิดขึ้นใน Apigee Edge ไคลเอ็นต์ แอปพลิเคชันจะได้รับสถานะ HTTP 503 พร้อมข้อความ Service Unavailable คุณ ดูข้อผิดพลาดนี้หลังการเรียก API ที่แฮนด์เชค TLS/SSL ล้มเหลว

ข้อความแสดงข้อผิดพลาด

HTTP/1.1 503 Service Unavailable

นอกจากนี้ คุณยังสามารถดูข้อความแสดงข้อผิดพลาดนี้เมื่อแฮนด์เชค TLS/SSL ล้มเหลว:

Received fatal alert: handshake_failure

สาเหตุที่เป็นไปได้

TLS (Transport Layer Security) ซึ่งก่อนหน้านี้คือ SSL) เป็นเทคโนโลยีการรักษาความปลอดภัยมาตรฐานสำหรับ การสร้างลิงก์ที่เข้ารหัสระหว่างเว็บเซิร์ฟเวอร์และเว็บไคลเอ็นต์ เช่น เบราว์เซอร์หรือแอป แฮนด์เชคคือกระบวนการที่ทำให้ไคลเอ็นต์และเซิร์ฟเวอร์ TLS/SSL สร้างชุดข้อมูลลับได้ ใช้สื่อสารได้ ในระหว่างขั้นตอนนี้ ไคลเอ็นต์และเซิร์ฟเวอร์จะดำเนินการต่อไปนี้

1. ยอมรับเวอร์ชันของโปรโตคอลที่จะใช้
2. เลือกอัลกอริทึมการเข้ารหัสที่จะใช้
3. ตรวจสอบสิทธิ์กันและกันด้วยการแลกเปลี่ยนและตรวจสอบใบรับรองดิจิทัล

หากแฮนด์เชค TLS/SSL สำเร็จ ไคลเอ็นต์และเซิร์ฟเวอร์ TLS/SSL จะโอนข้อมูลไปยัง อื่นๆ ได้อย่างปลอดภัย ไม่เช่นนั้นแล้ว หากแฮนด์เชค TLS/SSL ล้มเหลว การเชื่อมต่อจะถูกยุติและไคลเอ็นต์ ได้รับข้อผิดพลาด 503 Service Unavailable

สาเหตุที่เป็นไปได้สำหรับความล้มเหลวในการแฮนด์เชค TLS/SSL มีดังนี้

โปรโตคอล ไม่ตรงกัน

ความล้มเหลวในการแฮนด์เชค TLS/SSL จะเกิดขึ้นหากโปรโตคอลที่ใช้โดยไคลเอ็นต์ไม่รองรับโปรโตคอลดังกล่าว เซิร์ฟเวอร์ที่การเชื่อมต่อขาเข้า (ทิศเหนือ) หรือการเชื่อมต่อขาออก (ขาออก) ดูเพิ่มเติม ทำความเข้าใจเส้นเชื่อมต่อระหว่างทิศเหนือและทิศใต้

การวินิจฉัย

1. พิจารณาว่าข้อผิดพลาดเกิดขึ้นที่ทิศเหนือ หรือ ขาออก สำหรับคำแนะนำเพิ่มเติมในการดำเนินการ การตัดสินใจ, โปรดดู พิจารณาที่มาของปัญหา
2. เรียกใช้ tcpdump ยูทิลิตีเพื่อรวบรวมข้อมูลเพิ่มเติม
   • หากคุณเป็นผู้ใช้ Private Cloud คุณสามารถรวบรวม tcpdump ไปยังไคลเอ็นต์หรือเซิร์ฟเวอร์ที่เกี่ยวข้อง ไคลเอ็นต์อาจเป็นแอปไคลเอ็นต์ (สำหรับ หรือการเชื่อมต่อทางทิศเหนือ) หรือข้อความ โปรเซสเซอร์ (สำหรับการเชื่อมต่อขาออกหรือการเชื่อมต่อทางใต้) เซิร์ฟเวอร์อาจเป็น Edge Router (สำหรับ การเชื่อมต่อขาเข้าหรือการเชื่อมต่อทางเหนือ) หรือเซิร์ฟเวอร์แบ็กเอนด์ (สำหรับการเชื่อมต่อขาออก หรือการเชื่อมต่อทางใต้) โดยพิจารณาจากการตัดสินใจของคุณในขั้นตอนที่ 1
   • หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ คุณสามารถรวบรวม tcpdump ข้อมูลเฉพาะในแอปไคลเอ็นต์ (สำหรับการเชื่อมต่อขาเข้าหรือการเชื่อมต่อทางเหนือ) หรือเซิร์ฟเวอร์แบ็กเอนด์ (สำหรับการเชื่อมต่อขาออก หรือการเชื่อมต่อทางใต้) เนื่องจากคุณ ไม่มีสิทธิ์เข้าถึง Edge Router หรือ Message Processor

   tcpdump -i any -s 0 host IP address -w File name
   

   ดู ข้อมูล tcpdump สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการใช้ tcpdump คำสั่ง
3. วิเคราะห์ข้อมูล tcpdump โดยใช้เครื่องมือ Wireshark หรือเครื่องมือที่คล้ายกัน
4. ต่อไปนี้เป็นตัวอย่างการวิเคราะห์ของ tcpdump โดยใช้ Wireshark
   • ในตัวอย่างนี้ ความล้มเหลวในการแฮนด์เชค TLS/SSL เกิดขึ้นระหว่างตัวประมวลผลข้อความและ เซิร์ฟเวอร์แบ็กเอนด์ (การเชื่อมต่อขาออกหรือการเชื่อมต่อทางใต้)
   • ข้อความ #4 ในเอาต์พุต tcpdump ด้านล่างแสดงให้เห็นว่าเครื่องมือประมวลผลข้อความ (แหล่งที่มา) ได้ส่ง "สวัสดี ลูกค้า" ไปยังเซิร์ฟเวอร์แบ็กเอนด์ (ปลายทาง)
     

     

   • หากคุณเลือกข้อความ Client Hello แสดงว่าโปรแกรมประมวลผลข้อความกำลังใช้ โปรโตคอล TLSv1.2 ดังที่แสดงด้านล่าง

     

   • ข้อความ #5 แสดงให้เห็นว่าเซิร์ฟเวอร์แบ็กเอนด์รับทราบข้อความ "Client Hello" ข้อความจาก Message Processor
   • เซิร์ฟเวอร์แบ็กเอนด์จะส่งการแจ้งเตือนที่ร้ายแรง : ปิดการแจ้งเตือนไปยัง ตัวประมวลผลข้อความ (ข้อความ #6) ซึ่งหมายความว่าแฮนด์เชค TLS/SSL ล้มเหลวและการเชื่อมต่อจะ ปิด

   • เพิ่มเติมในข้อความที่ 6 นี้แสดงว่าสาเหตุของความล้มเหลวในแฮนด์เชค TLS/SSL คือ เซิร์ฟเวอร์แบ็กเอนด์รองรับโปรโตคอล TLSv1.0 เท่านั้นดังที่แสดงด้านล่าง

     

   • เนื่องจากโปรโตคอลที่ใช้โดยเครื่องมือประมวลผลข้อความและ เซิร์ฟเวอร์ส่วนหลัง เซิร์ฟเวอร์ส่วนหลังได้ส่งข้อความ: ข้อความแจ้งเตือนที่ร้ายแรง: ปิด แจ้งเตือน

ความละเอียด

Message Processor จะทำงานบน Java 8 และใช้โปรโตคอล TLSv1.2 โดยค่าเริ่มต้น หากแบ็กเอนด์ เซิร์ฟเวอร์ไม่รองรับโปรโตคอล TLSv1.2 คุณสามารถดำเนินการตามขั้นตอนต่อไปนี้เพื่อแก้ไข ปัญหานี้:

1. อัปเกรดเซิร์ฟเวอร์แบ็กเอนด์ให้รองรับโปรโตคอล TLSv1.2 นี่คือวิธีแก้ปัญหาที่แนะนำ โปรโตคอล TLSv1.2 มีความปลอดภัยมากกว่า
2. หากอัปเกรดเซิร์ฟเวอร์แบ็กเอนด์ไม่ได้ทันทีด้วยเหตุผลบางประการ คุณก็ทำสิ่งต่อไปนี้ได้ บังคับให้โปรแกรมประมวลผลข้อความใช้โปรโตคอล TLSv1.0 เพื่อสื่อสารกับ เซิร์ฟเวอร์แบ็กเอนด์โดยทำตามขั้นตอนต่อไปนี้
   1. ถ้าคุณไม่ได้ระบุเซิร์ฟเวอร์เป้าหมายในคำจำกัดความ TargetEndpoint ของพร็อกซี ให้ตั้งค่า องค์ประกอบ Protocol เป็น TLSv1.0 ตามที่แสดง ด้านล่าง

      <TargetEndpoint name="default">
       …
       <HTTPTargetConnection>
         <SSLInfo>
             <Enabled>true</Enabled>
             <Protocols>
                 <Protocol>TLSv1.0</Protocol>
             </Protocols>
         </SSLInfo>
         <URL>https://myservice.com</URL>
       </HTTPTargetConnection>
       …
      </TargetEndpoint>
      

   2. หากคุณกำหนดค่า เซิร์ฟเวอร์เป้าหมายสำหรับพร็อกซีแล้วใช้ API การจัดการนี้เพื่อตั้งค่าโปรโตคอลเป็น TLSv1.0 ใน การกำหนดค่าเซิร์ฟเวอร์เป้าหมาย

การเข้ารหัสไม่ตรงกัน

คุณจะเห็นความล้มเหลวในแฮนด์เชค TLS/SSL หากอัลกอริทึมชุดการเข้ารหัสที่ไคลเอ็นต์ใช้ไม่ใช่ รองรับโดยเซิร์ฟเวอร์ในการเชื่อมต่อขาเข้า (ทิศเหนือ) หรือขาออก (ขาออก) ใน Apigee Edge ดูเพิ่มเติมที่ ทำความเข้าใจเส้นเชื่อมต่อระหว่างทิศเหนือและทิศใต้

การวินิจฉัย

1. ตรวจสอบว่าข้อผิดพลาดเกิดขึ้นที่ การเชื่อมต่อแบบ northbound หรือ southbound ดูคำแนะนำเพิ่มเติมเกี่ยวกับการพิจารณาเรื่องนี้ได้ที่ การพิจารณา แหล่งที่มาของปัญหา
2. เรียกใช้ tcpdump ยูทิลิตีเพื่อรวบรวมข้อมูลเพิ่มเติม
   • หากคุณเป็นผู้ใช้ Private Cloud คุณสามารถรวบรวม tcpdump ไปยังไคลเอ็นต์หรือเซิร์ฟเวอร์ที่เกี่ยวข้อง ไคลเอ็นต์อาจเป็นแอปไคลเอ็นต์ (สำหรับ หรือการเชื่อมต่อทางทิศเหนือ) หรือข้อความ โปรเซสเซอร์ (สำหรับการเชื่อมต่อขาออกหรือการเชื่อมต่อทางใต้) เซิร์ฟเวอร์อาจเป็น Edge Router (สำหรับ การเชื่อมต่อขาเข้าหรือการเชื่อมต่อทางเหนือ) หรือเซิร์ฟเวอร์แบ็กเอนด์ (สำหรับการเชื่อมต่อขาออก หรือการเชื่อมต่อทางใต้) โดยพิจารณาจากการตัดสินใจของคุณในขั้นตอนที่ 1
   • หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ คุณสามารถรวบรวม tcpdump ข้อมูลเฉพาะในแอปไคลเอ็นต์ (สำหรับการเชื่อมต่อขาเข้าหรือการเชื่อมต่อทางเหนือ) หรือเซิร์ฟเวอร์แบ็กเอนด์ (สำหรับการเชื่อมต่อขาออก หรือการเชื่อมต่อทางใต้) เนื่องจากคุณ ไม่มีสิทธิ์เข้าถึง Edge Router หรือ Message Processor

   tcpdump -i any -s 0 host IP address -w File name
   

   ดู ข้อมูล tcpdump สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการใช้คำสั่ง tcpdump
3. วิเคราะห์ข้อมูล tcpdump โดยใช้เครื่องมือ Wireshark หรือเครื่องมืออื่นๆ ที่คุณคุ้นเคย
4. การวิเคราะห์เอาต์พุต tcpdump โดยใช้ Wireshark มีดังนี้
   • ในตัวอย่างนี้ แฮนด์เชค TLS/SSL ล้มเหลวระหว่างแอปพลิเคชันไคลเอ็นต์กับ Edge Router (การเชื่อมต่อทิศเหนือ) รวบรวมเอาต์พุต tcpdump ใน Edge แล้ว เราเตอร์

   • ข้อความ #4 ในผลลัพธ์ tcpdump ด้านล่างแสดงให้เห็นว่าแอปพลิเคชันไคลเอ็นต์ (แหล่งที่มา) ได้ส่ง "สวัสดี ลูกค้า" ไปยัง Edge Router (ปลายทาง)

     

   • การเลือกข้อความ Client Hello แสดงว่าแอปพลิเคชันไคลเอ็นต์กำลังใช้ โปรโตคอล TLSv1.2

     

   • ข้อความ #5 แสดงให้เห็นว่า Edge Router รับทราบถึง "Client Hello" ข้อความจาก แอปพลิเคชันไคลเอ็นต์
   • เราเตอร์ Edge จะส่งการแจ้งเตือนร้ายแรง : แฮนด์เชคล้มเหลวในทันทีเพื่อ แอปพลิเคชันไคลเอ็นต์ (ข้อความ #6) ซึ่งหมายความว่าแฮนด์เชค TLS/SSL ล้มเหลวและการเชื่อมต่อ จะปิด
   • เนื้อหาในข้อความ #6 จะแสดงข้อมูลต่อไปนี้
     • Edge Router รองรับโปรโตคอล TLSv1.2 ซึ่งหมายความว่าโปรโตคอลจะจับคู่ ระหว่างแอปพลิเคชันไคลเอ็นต์และ Edge Router ได้

     • แต่เราเตอร์ Edge จะยังคงส่งการแจ้งเตือนร้ายแรง: แฮนด์เชค ทำงานไม่สำเร็จกับแอปพลิเคชันไคลเอ็นต์ดังที่แสดงในภาพหน้าจอด้านล่าง

       

   • ข้อผิดพลาดอาจเกิดจากปัญหาอย่างใดอย่างหนึ่งต่อไปนี้
     • แอปพลิเคชันไคลเอ็นต์ไม่ได้ใช้อัลกอริทึมชุดการเข้ารหัสที่ Edge Router
     • Edge Router เปิดใช้งาน SNI แล้ว แต่แอปพลิเคชันไคลเอ็นต์ไม่ส่งข้อมูล ชื่อเซิร์ฟเวอร์
   • ข้อความ #4 ในเอาต์พุต tcpdump จะแสดงอัลกอริทึมชุดการเข้ารหัสที่ไคลเอ็นต์รองรับ ตามที่แสดงด้านล่าง

     

   • รายการอัลกอริทึมชุดการเข้ารหัสที่ Edge Router รองรับจะแสดงอยู่ในรายการ /opt/nginx/conf.d/0-default.conf ไฟล์ ในตัวอย่างนี้ Edge Router รองรับเฉพาะอัลกอริทึมชุดการเข้ารหัสสูง
   • แอปพลิเคชันไคลเอ็นต์ไม่ได้ใช้อัลกอริทึมของชุดการเข้ารหัสการเข้ารหัสสูงใดๆ การไม่ตรงกันนี้เป็นสาเหตุของ แฮนด์เชค TLS/SSL ล้มเหลว
   • เนื่องจาก Edge Router รองรับ SNI ให้เลื่อนลงไปที่ข้อความ #4 ในเอาต์พุต tcpdump และ ยืนยันว่าแอปพลิเคชันไคลเอ็นต์ส่งชื่อเซิร์ฟเวอร์อย่างถูกต้อง ดังที่แสดงใน รูปด้านล่าง
     วันที่
     
     
   • ถ้าชื่อนี้ถูกต้อง คุณสามารถอนุมานได้ว่าความล้มเหลวในแฮนด์เชค TLS/SSL เกิดขึ้นเนื่องจากอัลกอริทึมชุดการเข้ารหัสที่แอปพลิเคชันไคลเอ็นต์ไม่รองรับ Edge Router

ความละเอียด

คุณต้องตรวจสอบว่าไคลเอ็นต์ใช้อัลกอริทึมชุดการเข้ารหัสที่ ที่เซิร์ฟเวอร์รองรับ เพื่อแก้ไขปัญหาที่อธิบายไว้ก่อนหน้านี้ การวิเคราะห์ ให้ดาวน์โหลดและติดตั้ง Java Cryptography Extension (JCE) และรวมไว้ใน Java ให้รองรับอัลกอริทึมชุดการเข้ารหัสแบบ High Encryption

ใบรับรองไม่ถูกต้อง

ความล้มเหลวในการแฮนด์เชค TLS/SSL จะเกิดขึ้นหากคุณมีใบรับรองที่ไม่ถูกต้องในคีย์สโตร์/ทรัสต์สโตร์ ที่การเชื่อมต่อขาเข้า (ทิศเหนือ) หรือการเชื่อมต่อขาออก (ขาออก) ใน Apigee Edge ดูเพิ่มเติม ทำความเข้าใจเส้นเชื่อมต่อระหว่างทิศเหนือและทิศใต้

หากปัญหาอยู่ในทิศทางเหนือ คุณอาจเห็นข้อความแสดงข้อผิดพลาดที่แตกต่างกัน โดยขึ้นอยู่กับสาเหตุที่แท้จริง

ส่วนต่อไปนี้จะแสดงตัวอย่างข้อความแสดงข้อผิดพลาด และขั้นตอนในการวิเคราะห์และแก้ไขปัญหานี้ ปัญหา

ข้อความแสดงข้อผิดพลาด

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

* SSL certificate problem: Invalid certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

สาเหตุที่เป็นไปได้

สาเหตุทั่วไปของปัญหานี้มีดังนี้

ชื่อโฮสต์ ไม่ตรงกัน

การวินิจฉัย

1. โปรดทราบว่าชื่อโฮสต์ที่ใช้ใน URL ที่แสดงโดยการเรียก Edge Management API ต่อไปนี้

   curl -v https://myorg.domain.com/v1/getinfo

   ดังตัวอย่างต่อไปนี้

   curl -v https://api.enterprise.apigee.com/v1/getinfo

2. รับ CN ที่ใช้ในใบรับรองที่จัดเก็บไว้ในคีย์สโตร์ที่เฉพาะเจาะจง คุณสามารถใช้ Edge Management API ต่อไปนี้เพื่อรับรายละเอียดของใบรับรอง
   1. ดูชื่อใบรับรองในคีย์สโตร์:
      
      หากคุณเป็นผู้ใช้ Private Cloud ให้ใช้ Management API ดังนี้
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ ให้ใช้ Management API ดังนี้
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. ดูรายละเอียดของใบรับรองในคีย์สโตร์โดยใช้ Edge Management API
      
      หากคุณเป็นผู้ใช้ Private Cloud ให้ทำดังนี้
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ ให้ทำดังนี้
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      ตัวอย่างใบรับรอง:

      "certInfo": [
          {
            "basicConstraints": "CA:FALSE",
            "expiryDate": 1456258950000,
            "isValid": "No",
            "issuer": "SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=\"GoDaddy.com, Inc.\", L=Scottsdale, ST=Arizona, C=US",
            "publicKey": "RSA Public Key, 2048 bits",
            "serialNumber": "07:bc:a7:39:03:f1:56",
            "sigAlgName": "SHA1withRSA",
            "subject": "CN=something.domain.com, OU=Domain Control Validated, O=something.domain.com",
            "validFrom": 1358287055000,
            "version": 3
          },
      

      ชื่อเรื่องในใบรับรองหลักมี CN เป็น something.domain.com.

      เนื่องจากชื่อโฮสต์ที่ใช้ใน URL ของคำขอ API (ดูขั้นตอนที่ 1 ด้านบน) และชื่อเรื่อง ชื่อในใบรับรองไม่ตรงกัน จะทำให้แฮนด์เชค TLS/SSL ล้มเหลว

ความละเอียด

ปัญหานี้แก้ไขได้ด้วยวิธีใดวิธีหนึ่งต่อไปนี้

• รับใบรับรอง (หากยังไม่มี) ซึ่ง CN เรื่องมีไวลด์การ์ด แล้วอัปโหลดชุดใบรับรองที่สมบูรณ์รายการใหม่ไปยังคีย์สโตร์ เช่น

  "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",

• รับใบรับรอง (หากยังไม่มี) ที่มี CN เรื่องที่มีอยู่ แต่ใช้ your-orgyour-domain เป็นชื่ออื่นของเรื่อง แล้วอัปโหลด เชนใบรับรองไปยังคีย์สโตร์

ข้อมูลอ้างอิง

คีย์สโตร์และ Truststores

ชุดใบรับรองไม่สมบูรณ์หรือไม่ถูกต้อง

การวินิจฉัย

1. รับ CN ที่ใช้ในใบรับรองที่จัดเก็บไว้ในคีย์สโตร์ที่เฉพาะเจาะจง คุณสามารถใช้ Edge Management API ต่อไปนี้เพื่อรับรายละเอียดของใบรับรอง
   1. ดูชื่อใบรับรองในคีย์สโตร์:
      
      หากคุณเป็นผู้ใช้ Private Cloud
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

      หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ ให้ทำดังนี้
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. ดูรายละเอียดของใบรับรองในคีย์สโตร์:
      
      หากคุณเป็นผู้ใช้ Private Cloud
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ ให้ทำดังนี้
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

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

   ตัวอย่างใบรับรองกลางและรูทที่ผู้ออกบัตรและ เรื่องไม่ตรงกัน

   
   

ความละเอียด

1. รับใบรับรอง (หากคุณยังไม่มี) ที่มีใบรับรองที่ถูกต้องและครบถ้วน กลุ่มใบรับรอง
2. เรียกใช้คำสั่ง openssl ต่อไปนี้เพื่อยืนยันว่าชุดใบรับรองถูกต้องและ เสร็จสมบูรณ์:

   openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert

3. อัปโหลดชุดใบรับรองที่ตรวจสอบแล้วไปยังคีย์สโตร์

หมดอายุหรือไม่ทราบ ใบรับรองที่ส่งโดยเซิร์ฟเวอร์หรือไคลเอ็นต์

หากเซิร์ฟเวอร์/ไคลเอ็นต์ส่งใบรับรองที่ไม่ถูกต้อง/หมดอายุไปทางทิศเหนือ หรือที่การเชื่อมต่อทิศใต้ ปลายอีกด้านหนึ่ง (เซิร์ฟเวอร์/ไคลเอ็นต์) จะปฏิเสธใบรับรอง จะทำให้เกิดแฮนด์เชค TLS/SSL ไม่สำเร็จ

การวินิจฉัย

1. พิจารณาว่าข้อผิดพลาดเกิดขึ้นที่ทิศเหนือ หรือ ขาออก สำหรับคำแนะนำเพิ่มเติมในการดำเนินการ การตัดสินใจ, โปรดดู พิจารณาที่มาของปัญหา
2. เรียกใช้ tcpdump ยูทิลิตีเพื่อรวบรวมข้อมูลเพิ่มเติม
   • หากคุณเป็นผู้ใช้ Private Cloud คุณสามารถรวบรวม tcpdump ไปยังไคลเอ็นต์หรือเซิร์ฟเวอร์ที่เกี่ยวข้อง ไคลเอ็นต์อาจเป็นแอปไคลเอ็นต์ (สำหรับ หรือการเชื่อมต่อทางทิศเหนือ) หรือข้อความ โปรเซสเซอร์ (สำหรับการเชื่อมต่อขาออกหรือการเชื่อมต่อทางใต้) เซิร์ฟเวอร์อาจเป็น Edge Router (สำหรับ การเชื่อมต่อขาเข้าหรือการเชื่อมต่อทางเหนือ) หรือเซิร์ฟเวอร์แบ็กเอนด์ (สำหรับการเชื่อมต่อขาออก หรือการเชื่อมต่อทางใต้) โดยพิจารณาจากการตัดสินใจของคุณในขั้นตอนที่ 1
   • หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ คุณสามารถรวบรวม tcpdump ข้อมูลเฉพาะในแอปไคลเอ็นต์ (สำหรับการเชื่อมต่อขาเข้าหรือการเชื่อมต่อทางเหนือ) หรือเซิร์ฟเวอร์แบ็กเอนด์ (สำหรับการเชื่อมต่อขาออก หรือการเชื่อมต่อทางใต้) เนื่องจากคุณ ไม่มีสิทธิ์เข้าถึง Edge Router หรือ Message Processor

   tcpdump -i any -s 0 host IP address -w File name
   

   ดู ข้อมูล tcpdump สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการใช้คำสั่ง tcpdump
3. วิเคราะห์ข้อมูล tcpdump โดยใช้ Wireshark หรือ เครื่องมือที่คล้ายกัน
4. จากเอาต์พุต tcpdump ให้ระบุโฮสต์ (ไคลเอ็นต์หรือเซิร์ฟเวอร์) ที่ปฏิเสธ ในระหว่างขั้นตอนการยืนยัน
5. คุณสามารถเรียกใบรับรองที่ส่งจากอีกฝั่งหนึ่งจากเอาต์พุต tcpdump โดยที่ จะไม่มีการเข้ารหัสข้อมูล ซึ่งจะมีประโยชน์ในการเปรียบเทียบว่าใบรับรองนี้ตรงกับ ที่มีให้บริการใน Truststore
6. ตรวจสอบตัวอย่าง tcpdump สำหรับการสื่อสาร SSL ระหว่างตัวประมวลผลข้อความและ เซิร์ฟเวอร์แบ็กเอนด์

   ตัวอย่าง tcpdump แสดงข้อผิดพลาดใบรับรองที่ไม่รู้จัก

   
   

   1. โปรแกรมประมวลผลข้อความ (ไคลเอ็นต์) จะส่ง "Client Hello" ไปยังเซิร์ฟเวอร์แบ็กเอนด์ (เซิร์ฟเวอร์) ในข้อความ #59
   2. เซิร์ฟเวอร์แบ็กเอนด์จะส่ง "Server Hello" ไปที่โปรแกรมประมวลผลข้อความในข้อความ #61.
   3. และตรวจสอบโปรโตคอลและอัลกอริทึมชุดการเข้ารหัสที่ใช้ร่วมกัน
   4. เซิร์ฟเวอร์แบ็กเอนด์จะส่งข้อความใบรับรองและ Hello Done ของเซิร์ฟเวอร์ไปยังไฟล์ ตัวประมวลผลข้อความในข้อความ #68
   5. เครื่องมือประมวลผลข้อความจะส่งการแจ้งเตือนร้ายแรง "Description: ใบรับรอง ไม่รู้จัก" ในข้อความ #70
   6. โปรดดูรายละเอียดเพิ่มเติมในข้อความ #70 ไม่มีรายละเอียดอื่นๆ เพิ่มเติม สูงกว่าข้อความแจ้งเตือนดังที่แสดงด้านล่าง

      
      

   7. ตรวจสอบข้อความ #68 เพื่อดูรายละเอียดเกี่ยวกับใบรับรองที่ส่งโดยแบ็กเอนด์ ดังแสดงในกราฟิกต่อไปนี้

      

   8. ใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์และเชนแบบสมบูรณ์ทั้งหมดจะพร้อมใช้งาน ใต้ "ใบรับรอง" ดังที่แสดงในรูปด้านบน
7. หากพบว่าเราเตอร์ไม่ทราบใบรับรอง (ทิศเหนือ) หรือใบรับรอง ตัวประมวลผลข้อความ (ขาออก) ตามตัวอย่างที่แสดงด้านบน จากนั้นทำตาม ขั้นตอน:
   1. รับใบรับรองและเชนที่จัดเก็บไว้ใน Truststore ที่เฉพาะเจาะจง (โปรดดู ไปยังการกำหนดค่าโฮสต์เสมือนสำหรับการกำหนดค่าเราเตอร์และปลายทางเป้าหมายสำหรับ Message Processor) คุณสามารถใช้ API ต่อไปนี้เพื่อรับรายละเอียดของ ใบรับรอง:
      1. รับชื่อใบรับรองใน Truststore ดังนี้

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs

      2. ดูรายละเอียดของใบรับรองใน Truststore ดังนี้

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name

   2. ตรวจสอบว่าใบรับรองที่จัดเก็บไว้ใน Truststore ของเราเตอร์ (ทิศเหนือ) หรือ ตัวประมวลผลข้อความ (ขาออก) ตรงกับใบรับรองที่เก็บไว้ใน คีย์สโตร์ของแอปพลิเคชันไคลเอ็นต์ (ทิศเหนือ) หรือเซิร์ฟเวอร์เป้าหมาย (อยู่ทางใต้) หรือ ซึ่งเป็นรายการที่ได้รับจากเอาต์พุต tcpdump หากมีข้อมูลที่ไม่ตรงกัน นั่นเป็นสาเหตุที่ แฮนด์เชค TLS/SSL ล้มเหลว
8. หากพบว่าไม่รู้จักใบรับรองจากแอปพลิเคชันไคลเอ็นต์ (อยู่เหนือ) หรือเซิร์ฟเวอร์เป้าหมาย (ขาออก) ให้ทำตามขั้นตอนต่อไปนี้
   1. รับชุดใบรับรองที่สมบูรณ์ที่ใช้ในใบรับรองที่เก็บไว้ใน คีย์สโตร์ (โปรดดูการกำหนดค่าโฮสต์เสมือนสำหรับเราเตอร์และปลายทางเป้าหมาย สำหรับเครื่องมือประมวลผลข้อความ) คุณสามารถใช้ API ต่อไปนี้เพื่อรับ รายละเอียดของใบรับรอง:
      1. ดูชื่อใบรับรองในคีย์สโตร์ดังนี้

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      2. ดูรายละเอียดของใบรับรองในคีย์สโตร์:
         

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
         

   2. ตรวจสอบว่าใบรับรองที่จัดเก็บไว้ในคีย์สโตร์ของเราเตอร์ (ทิศเหนือ) หรือ Message Processor (southbound) ตรงกับใบรับรองที่เก็บไว้ใน Truststore ของ แอปพลิเคชันไคลเอ็นต์ (ทิศเหนือ) หรือเซิร์ฟเวอร์เป้าหมาย (ขาออก) หรือเซิร์ฟเวอร์ที่ ที่ได้รับจากเอาต์พุต tcpdump หากมีข้อมูลที่ไม่ตรงกัน นี่ก็เป็นสาเหตุของ SSL แฮนด์เชคล้มเหลว
9. หากพบว่าใบรับรองที่เซิร์ฟเวอร์/ไคลเอ็นต์ส่งหมดอายุ แสดงว่าใบรับรองที่ได้รับ ไคลเอ็นต์/เซิร์ฟเวอร์ปฏิเสธใบรับรอง และคุณจะเห็นข้อความแจ้งเตือนต่อไปนี้ใน tcpdump:

   การแจ้งเตือน (ระดับ: ร้ายแรง คำอธิบาย: ใบรับรองหมดอายุ)

10. ตรวจสอบว่าใบรับรองในคีย์สโตร์ของโฮสต์ที่เหมาะสมหมดอายุแล้ว

ความละเอียด

หากต้องการแก้ไขปัญหาที่ระบุในตัวอย่างด้านบน ให้อัปโหลด ให้กับทรัสตีในเครื่องมือประมวลผลข้อความ

ตารางต่อไปนี้สรุปขั้นตอนในการแก้ไขปัญหา โดยขึ้นอยู่กับสาเหตุของปัญหา ปัญหา

เปิดใช้ SNI เซิร์ฟเวอร์

ความล้มเหลวในแฮนด์เชค TLS/SSL อาจเกิดขึ้นเมื่อไคลเอ็นต์กำลังสื่อสารกับเซิร์ฟเวอร์ เปิดใช้การระบุชื่อ (SNI) อยู่ เซิร์ฟเวอร์ แต่ไคลเอ็นต์ไม่ได้เปิดใช้ SNI ซึ่งเกิดขึ้นได้ทั้งทางทิศเหนือหรือ แล้วเชื่อมต่อกับทิศใต้ใน Edge

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

การระบุเซิร์ฟเวอร์ที่เปิดใช้งาน SNI

1. เรียกใช้คำสั่ง openssl แล้วลองเชื่อมต่อกับชื่อโฮสต์เซิร์ฟเวอร์ที่เกี่ยวข้อง (Edge เราเตอร์หรือเซิร์ฟเวอร์แบ็กเอนด์) โดยไม่ส่งชื่อเซิร์ฟเวอร์ ดังที่แสดงด้านล่าง

   openssl s_client -connect hostname:port
   

   คุณอาจได้รับใบรับรอง และบางครั้งคุณอาจเห็นความล้มเหลวในการแฮนด์เชคใน คำสั่ง openssl ดังที่แสดงด้านล่าง
   

   CONNECTED(00000003)
   9362:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_clnt.c:593
   

2. เรียกใช้คำสั่ง openssl แล้วลองเชื่อมต่อกับชื่อโฮสต์ของเซิร์ฟเวอร์ที่เกี่ยวข้อง (เราเตอร์ Edge หรือเซิร์ฟเวอร์แบ็กเอนด์) โดยส่งชื่อเซิร์ฟเวอร์ดังที่แสดงด้านล่าง

   openssl s_client -connect hostname:port -servername hostname
   

3. หากแฮนด์เชคล้มเหลวในขั้นตอนที่ 1 หรือได้รับใบรับรองอื่นในขั้นตอนที่ 1 และ ขั้นตอนที่ 2 ก็แสดงว่าเซิร์ฟเวอร์ที่ระบุเปิดใช้งาน SNI อยู่

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

การวินิจฉัย

1. พิจารณาว่าข้อผิดพลาดเกิดขึ้นที่ทิศเหนือ หรือ ขาออก สำหรับคำแนะนำเพิ่มเติมในการดำเนินการ การตัดสินใจ, โปรดดู พิจารณาที่มาของปัญหา
2. เรียกใช้ tcpdump ยูทิลิตีเพื่อรวบรวมข้อมูลเพิ่มเติม
   • หากคุณเป็นผู้ใช้ Private Cloud คุณสามารถรวบรวม tcpdump ไปยังไคลเอ็นต์หรือเซิร์ฟเวอร์ที่เกี่ยวข้อง ไคลเอ็นต์อาจเป็นแอปไคลเอ็นต์ (สำหรับ หรือการเชื่อมต่อทางทิศเหนือ) หรือข้อความ โปรเซสเซอร์ (สำหรับการเชื่อมต่อขาออกหรือการเชื่อมต่อทางใต้) เซิร์ฟเวอร์อาจเป็น Edge Router (สำหรับ การเชื่อมต่อขาเข้าหรือการเชื่อมต่อทางเหนือ) หรือเซิร์ฟเวอร์แบ็กเอนด์ (สำหรับการเชื่อมต่อขาออก หรือการเชื่อมต่อทางใต้) โดยพิจารณาจากการตัดสินใจของคุณในขั้นตอนที่ 1
   • หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ คุณสามารถรวบรวม tcpdump ข้อมูลเฉพาะในแอปไคลเอ็นต์ (สำหรับการเชื่อมต่อขาเข้าหรือการเชื่อมต่อทางเหนือ) หรือเซิร์ฟเวอร์แบ็กเอนด์ (สำหรับการเชื่อมต่อขาออก หรือการเชื่อมต่อทางใต้) เนื่องจากคุณ ไม่มีสิทธิ์เข้าถึง Edge Router หรือ Message Processor

   tcpdump -i any -s 0 host IP address -w File name
   

   โปรดดู ข้อมูล tcpdump สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการใช้คำสั่ง tcpdump
3. วิเคราะห์เอาต์พุต tcpdump โดยใช้ Wireshark หรือ เครื่องมือที่คล้ายกัน
4. การวิเคราะห์ tcpdump โดยใช้ Wireshark มีดังนี้
   1. ในตัวอย่างนี้ ความล้มเหลวในการแฮนด์เชค TLS/SSL เกิดขึ้นระหว่าง Edge Message ตัวประมวลผลและเซิร์ฟเวอร์แบ็กเอนด์ (การเชื่อมต่อขาออก)
   2. ข้อความ #4 ในผลลัพธ์ tcpdump ด้านล่างแสดงให้เห็นว่าระบบส่งข้อความ (แหล่งที่มา) ส่ง "สวัสดี ลูกค้า" ไปยังเซิร์ฟเวอร์แบ็กเอนด์ (ปลายทาง)

      

   3. การเลือก "Client Hello" แสดงว่าข้อความ โปรเซสเซอร์ใช้โปรโตคอล TLSv1.2

      

   4. ข้อความ #4 แสดงว่าเซิร์ฟเวอร์แบ็กเอนด์รับทราบข้อความ "Client Hello" ข้อความ จาก Message Processor
   5. เซิร์ฟเวอร์แบ็กเอนด์จะส่งการแจ้งเตือนที่ร้ายแรง : แฮนด์เชคทันที ระบบประมวลผลข้อความ (ข้อความ #5) ไม่ได้ หมายถึงแฮนด์เชค TLS/SSL ล้มเหลว และการเชื่อมต่อจะปิด
   6. ตรวจสอบข้อความ #6 เพื่อดูข้อมูลต่อไปนี้
      • เซิร์ฟเวอร์แบ็กเอนด์รองรับโปรโตคอล TLSv1.2 ซึ่งหมายความว่าโปรโตคอล ที่ตรงกันระหว่าง Message Processor และเซิร์ฟเวอร์แบ็กเอนด์
      • แต่เซิร์ฟเวอร์แบ็กเอนด์จะยังคงส่งการแจ้งเตือนร้ายแรง: แฮนด์เชค ทำงานล้มเหลวกับตัวประมวลผลข้อความดังที่แสดงในรูปด้านล่าง

        

   7. ข้อผิดพลาดนี้อาจเกิดขึ้นจากสาเหตุข้อใดข้อหนึ่งต่อไปนี้
      • โปรแกรมประมวลผลข้อความไม่ได้ใช้อัลกอริทึมชุดการเข้ารหัสที่ เซิร์ฟเวอร์แบ็กเอนด์
      • เซิร์ฟเวอร์แบ็กเอนด์เปิดใช้ SNI แล้ว แต่แอปพลิเคชันไคลเอ็นต์ไม่ส่ง ชื่อเซิร์ฟเวอร์
   8. ตรวจสอบข้อความ #3 (Client Hello) ในเอาต์พุต tcpdump โดยละเอียด โปรดทราบว่า ส่วนขยาย: Server_name ขาดหายไปตามที่แสดงด้านล่าง

      

   9. ซึ่งเป็นการยืนยันว่า Message Processor ไม่ได้ส่ง server_name ไปยังเซิร์ฟเวอร์แบ็กเอนด์ที่เปิดใช้ SNI
   10. ซึ่งเป็นสาเหตุของความล้มเหลวในการแฮนด์เชค TLS/SSL และเหตุผลที่แบ็กเอนด์ เซิร์ฟเวอร์จะส่งการแจ้งเตือนร้ายแรง: แฮนด์เชคล้มเหลวไปยังข้อความ ผู้ประมวลผลข้อมูล
5. ตรวจสอบว่า jsse.enableSNIExtension property ใน system.properties ได้รับการตั้งค่าเป็น "เท็จ" ใน Message Processor เพื่อยืนยันว่า ไม่ได้เปิดใช้งานตัวประมวลผลข้อความเพื่อสื่อสารกับเซิร์ฟเวอร์ที่เปิดใช้ SNI

ความละเอียด

เปิดใช้งานตัวประมวลผลข้อความเพื่อสื่อสารกับเซิร์ฟเวอร์ที่เปิดใช้งาน SNI โดยดำเนินการ ขั้นตอนต่อไปนี้

1. สร้าง/opt/apigee/customer/application/message-processor.properties (หากยังไม่มี)
2. เพิ่มบรรทัดต่อไปนี้ลงในไฟล์นี้: conf_system_jsse.enableSNIExtension=true
3. แต่งตั้งเจ้าของไฟล์นี้ให้กับ apigee:apigee:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. รีสตาร์ทโปรแกรมประมวลผลข้อความ

   /opt/apigee/apigee-service/bin/apigee-service message-processor restart

5. หากคุณมีโปรแกรมประมวลผลข้อความมากกว่าหนึ่งโปรแกรม ให้ทำขั้นตอนที่ 1 ถึง #4 ซ้ำในส่วน ตัวประมวลผลข้อความ

หากไม่สามารถระบุสาเหตุที่ทำให้แฮนด์เชค TLS/SSL ล้มเหลว เพื่อแก้ไขปัญหา หรือหากต้องการความช่วยเหลือเพิ่มเติม โปรดติดต่อ การสนับสนุน Apigee Edge แชร์รายละเอียดทั้งหมดเกี่ยวกับปัญหาพร้อมกับ เอาต์พุต tcpdump