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

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

ลักษณะปัญหา

การแฮนด์เชค TLS/SSL ล้มเหลวเกิดขึ้นเมื่อไคลเอ็นต์และเซิร์ฟเวอร์ไม่สามารถสร้างการสื่อสารโดยใช้โปรโตคอล TLS/SSL เมื่อข้อผิดพลาดนี้เกิดขึ้นใน Apigee Edge แอปพลิเคชันไคลเอ็นต์จะได้รับสถานะ HTTP 503 พร้อมข้อความบริการไม่พร้อมใช้งาน คุณจะเห็นข้อผิดพลาดนี้หลังจากการเรียก 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 ล้มเหลวจะเกิดขึ้นหากเซิร์ฟเวอร์ไม่รองรับโปรโตคอลที่ไคลเอ็นต์ใช้ในการเชื่อมต่อขาเข้า (Northbound) หรือขาออก (Southbound) ดูเพิ่มเติม ทำความเข้าใจการเชื่อมต่อขาเข้าและขาออก

การวินิจฉัย

1. ตรวจสอบว่าข้อผิดพลาดเกิดขึ้นกับการเชื่อมต่อขาขึ้นหรือขาลง ดูคำแนะนำเพิ่มเติมเกี่ยวกับการพิจารณานี้ได้ที่ การระบุแหล่งที่มาของปัญหา
2. เรียกใช้ยูทิลิตี tcpdump เพื่อรวบรวมข้อมูลเพิ่มเติม
   • หากเป็นผู้ใช้ Private Cloud คุณจะรวบรวมข้อมูล tcpdump ได้ที่ไคลเอ็นต์หรือเซิร์ฟเวอร์ที่เกี่ยวข้อง ไคลเอ็นต์อาจเป็นแอปไคลเอ็นต์ (สำหรับการเชื่อมต่อขาเข้าหรือการเชื่อมต่อที่มุ่งหน้าไปยังเซิร์ฟเวอร์) หรือตัวประมวลผลข้อความ (สำหรับการเชื่อมต่อขาออกหรือการเชื่อมต่อที่มุ่งหน้าไปยังไคลเอ็นต์) เซิร์ฟเวอร์อาจเป็นเราเตอร์ Edge (สำหรับการเชื่อมต่อขาเข้าหรือการเชื่อมต่อขาขึ้น) หรือเซิร์ฟเวอร์แบ็กเอนด์ (สำหรับการเชื่อมต่อขาออกหรือการเชื่อมต่อขาลง) โดยขึ้นอยู่กับการพิจารณาจากขั้นตอนที่ 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 ไม่สำเร็จเกิดขึ้นระหว่าง Message Processor กับ เซิร์ฟเวอร์แบ็กเอนด์ (การเชื่อมต่อขาออกหรือการเชื่อมต่อที่ส่งจากเซิร์ฟเวอร์ไปยังอุปกรณ์)
   • ข้อความ #4 ในtcpdumpเอาต์พุตด้านล่างแสดงให้เห็นว่า Message Processor (แหล่งที่มา) ส่งข้อความ "Client Hello" ไปยังเซิร์ฟเวอร์แบ็กเอนด์ (ปลายทาง)
     

     

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

     

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

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

     

   • เนื่องจากโปรโตคอลที่ใช้โดย Message Processor และเซิร์ฟเวอร์แบ็กเอนด์ไม่ตรงกัน เซิร์ฟเวอร์แบ็กเอนด์จึงส่งข้อความ Fatal Alert Message: Close Notify

ความละเอียด

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

1. อัปเกรดเซิร์ฟเวอร์แบ็กเอนด์ให้รองรับโปรโตคอล TLSv1.2 นี่คือโซลูชันที่แนะนำเนื่องจาก โปรโตคอล TLSv1.2 ปลอดภัยกว่า
2. หากคุณอัปเกรดเซิร์ฟเวอร์แบ็กเอนด์ไม่ได้ในทันทีด้วยเหตุผลบางประการ คุณสามารถ บังคับให้ Message Processor ใช้โปรโตคอล 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. หากคุณกำหนดค่า เซิร์ฟเวอร์เป้าหมายสำหรับพร็อกซี ให้ใช้ Management API นี้เพื่อตั้งค่าโปรโตคอลเป็น TLSv1.0 ในการกำหนดค่าเซิร์ฟเวอร์เป้าหมาย ที่เฉพาะเจาะจง

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

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

การวินิจฉัย

1. ตรวจสอบว่าข้อผิดพลาดเกิดขึ้นที่การเชื่อมต่อขาเข้าหรือขาออก ดูคำแนะนำเพิ่มเติมเกี่ยวกับการพิจารณานี้ได้ที่ การระบุ แหล่งที่มาของปัญหา
2. เรียกใช้ยูทิลิตี tcpdump เพื่อรวบรวมข้อมูลเพิ่มเติม
   • หากเป็นผู้ใช้ Private Cloud คุณจะรวบรวมข้อมูล tcpdump ได้ที่ไคลเอ็นต์หรือเซิร์ฟเวอร์ที่เกี่ยวข้อง ไคลเอ็นต์อาจเป็นแอปไคลเอ็นต์ (สำหรับการเชื่อมต่อขาเข้าหรือการเชื่อมต่อที่มุ่งหน้าไปยังเซิร์ฟเวอร์) หรือตัวประมวลผลข้อความ (สำหรับการเชื่อมต่อขาออกหรือการเชื่อมต่อที่มุ่งหน้าไปยังไคลเอ็นต์) เซิร์ฟเวอร์อาจเป็นเราเตอร์ Edge (สำหรับการเชื่อมต่อขาเข้าหรือการเชื่อมต่อขาขึ้น) หรือเซิร์ฟเวอร์แบ็กเอนด์ (สำหรับการเชื่อมต่อขาออกหรือการเชื่อมต่อขาลง) โดยขึ้นอยู่กับการพิจารณาจากขั้นตอนที่ 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 (การเชื่อมต่อขาขึ้น) ระบบรวบรวมเอาต์พุต tcpdump ในเราเตอร์ Edge

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

     

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

     

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

     • อย่างไรก็ตาม เราเตอร์ Edge ยังคงส่ง Fatal Alert: Handshake Failure ไปยังแอปพลิเคชันไคลเอ็นต์ตามที่แสดงในภาพหน้าจอด้านล่าง

       

   • ข้อผิดพลาดอาจเกิดจากปัญหาอย่างใดอย่างหนึ่งต่อไปนี้
     • แอปพลิเคชันไคลเอ็นต์ไม่ได้ใช้อัลกอริทึมชุดการเข้ารหัสที่ 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

ความละเอียด

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

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

การแฮนด์เชค TLS/SSL จะล้มเหลวหากคุณมีใบรับรองที่ไม่ถูกต้องในที่เก็บคีย์/ที่เก็บที่เชื่อถือได้ ไม่ว่าจะในการเชื่อมต่อขาเข้า (Northbound) หรือขาออก (Southbound) ใน 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 ที่การเรียก API การจัดการ Edge ต่อไปนี้ส่งคืน

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

   ตัวอย่าง

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

2. รับ CN ที่ใช้ในใบรับรองที่จัดเก็บไว้ในคีย์สโตร์ที่เฉพาะเจาะจง คุณใช้ API การจัดการ Edge ต่อไปนี้เพื่อดูรายละเอียดของใบรับรองได้
   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 ที่ล้มเหลว

ความละเอียด

คุณแก้ไขปัญหานี้ได้ 2 วิธีต่อไปนี้

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

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

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

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

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

ห่วงโซ่ใบรับรองไม่สมบูรณ์หรือไม่ถูกต้อง

การวินิจฉัย

1. รับ CN ที่ใช้ในใบรับรองที่จัดเก็บไว้ในคีย์สโตร์ที่เฉพาะเจาะจง คุณใช้ API การจัดการ Edge ต่อไปนี้เพื่อดูรายละเอียดของใบรับรองได้
   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 (สำหรับการเชื่อมต่อขาเข้าหรือการเชื่อมต่อขาขึ้น) หรือเซิร์ฟเวอร์แบ็กเอนด์ (สำหรับการเชื่อมต่อขาออกหรือการเชื่อมต่อขาลง) โดยขึ้นอยู่กับการพิจารณาจากขั้นตอนที่ 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 ระหว่าง Message Processor กับ เซิร์ฟเวอร์แบ็กเอนด์

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

   
   

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

      
      

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

      

   8. ใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์และชุดใบรับรองที่สมบูรณ์ทั้งหมดจะพร้อมใช้งาน ในส่วน "ใบรับรอง" ดังที่แสดงในรูปภาพด้านบน
7. หากเราเตอร์ (ขาออก) หรือ Message Processor (ขาเข้า) พบว่าใบรับรองไม่รู้จัก ดังตัวอย่างที่แสดงไว้ด้านบน ให้ทำตามขั้นตอนต่อไปนี้
   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 ของเราเตอร์ (ขาเข้า) หรือ Message Processor (ขาออก) ตรงกับใบรับรองที่จัดเก็บไว้ใน Keystore ของแอปพลิเคชันไคลเอ็นต์ (ขาเข้า) หรือเซิร์ฟเวอร์เป้าหมาย (ขาออก) หรือ ใบรับรองที่ได้จากเอาต์พุต tcpdump หากมีข้อมูลไม่ตรงกัน นั่นคือสาเหตุที่ทำให้แฮนด์เชค TLS/SSL ไม่สำเร็จ
8. หากแอปพลิเคชันไคลเอ็นต์ (ขาขึ้น) หรือเซิร์ฟเวอร์เป้าหมาย (ขาลง) ระบุว่าใบรับรองไม่รู้จัก ให้ทำตามขั้นตอนต่อไปนี้
   1. รับเชนใบรับรองที่สมบูรณ์ซึ่งใช้ในใบรับรองที่จัดเก็บไว้ในคีย์สโตร์ที่เฉพาะเจาะจง (ดูการกำหนดค่าโฮสต์เสมือนสำหรับเราเตอร์และการกำหนดค่าปลายทางเป้าหมาย สำหรับการกำหนดค่า Message Processor) คุณใช้ 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 (ขาออก) ตรงกับใบรับรองที่จัดเก็บไว้ใน Truststore ของ แอปพลิเคชันไคลเอ็นต์ (ขาเข้า) หรือเซิร์ฟเวอร์เป้าหมาย (ขาออก) หรือใบรับรองที่ ได้รับจากเอาต์พุต tcpdump หากมีข้อมูลไม่ตรงกัน นั่นคือสาเหตุที่ทำให้แฮนด์เชค SSL ไม่สำเร็จ
9. หากพบว่าใบรับรองที่เซิร์ฟเวอร์/ไคลเอ็นต์ส่งมาหมดอายุแล้ว ไคลเอ็นต์/เซิร์ฟเวอร์ที่รับจะปฏิเสธใบรับรอง และคุณจะเห็นข้อความแจ้งต่อไปนี้ใน tcpdump

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

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

ความละเอียด

หากต้องการแก้ไขปัญหาที่ระบุไว้ในตัวอย่างข้างต้น ให้อัปโหลดใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์ที่ถูกต้องไปยัง Truststore ใน Message Processor

ตารางต่อไปนี้สรุปขั้นตอนในการแก้ไขปัญหาตามสาเหตุของปัญหา

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

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

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

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

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

   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 (สำหรับการเชื่อมต่อขาเข้าหรือการเชื่อมต่อขาขึ้น) หรือเซิร์ฟเวอร์แบ็กเอนด์ (สำหรับการเชื่อมต่อขาออกหรือการเชื่อมต่อขาลง) โดยขึ้นอยู่กับการพิจารณาจากขั้นตอนที่ 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 Processor กับเซิร์ฟเวอร์แบ็กเอนด์ (การเชื่อมต่อขาออก)
   2. ข้อความ #4 ในtcpdumpเอาต์พุตด้านล่างแสดงให้เห็นว่า Message Processor (แหล่งที่มา) ส่ง ข้อความ "Client Hello" ไปยังเซิร์ฟเวอร์แบ็กเอนด์ (ปลายทาง)

      

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

      

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

        

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

      

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

ความละเอียด

เปิดใช้ Message Processor ให้สื่อสารกับเซิร์ฟเวอร์ที่เปิดใช้ SNI โดยทำตามขั้นตอนต่อไปนี้

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

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

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

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

5. หากมี Message Processor มากกว่า 1 รายการ ให้ทำขั้นตอนที่ 1 ถึง 4 ซ้ำใน Message Processor ทั้งหมด

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