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

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

ลักษณะปัญหา

การทำงานแฮนด์เชค 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 ไม่สำเร็จมีดังนี้

สาเหตุ	คำอธิบาย	ผู้ที่มีสิทธิ์ทำตามขั้นตอนการแก้ปัญหา
โปรโตคอลไม่ตรงกัน	เซิร์ฟเวอร์ไม่รองรับโปรโตคอลที่ไคลเอ็นต์ใช้	ผู้ใช้ Private Cloud และผู้ใช้ Cloud สาธารณะ
ชุดการเข้ารหัสไม่ตรงกัน	เซิร์ฟเวอร์ไม่รองรับชุดการเข้ารหัสที่ไคลเอ็นต์ใช้	ผู้ใช้ Private Cloud และผู้ใช้ Cloud สาธารณะ
ใบรับรองไม่ถูกต้อง	ชื่อโฮสต์ใน URL ที่ไคลเอ็นต์ใช้ไม่ตรงกับชื่อโฮสต์ในใบรับรองที่จัดเก็บไว้ในฝั่งเซิร์ฟเวอร์	ผู้ใช้ Private Cloud และผู้ใช้ Cloud สาธารณะ
	ชุดใบรับรองที่ไม่สมบูรณ์หรือไม่ถูกต้องจะถูกเก็บไว้ที่ฝั่งไคลเอ็นต์หรือเซิร์ฟเวอร์	ผู้ใช้ Private Cloud และผู้ใช้ Cloud สาธารณะ
	ไคลเอ็นต์ส่งใบรับรองที่ไม่ถูกต้องหรือหมดอายุไปยังเซิร์ฟเวอร์หรือใบรับรองจากเซิร์ฟเวอร์ไปยังไคลเอ็นต์	ผู้ใช้ Private Cloud และผู้ใช้ Cloud สาธารณะ
เซิร์ฟเวอร์ที่เปิดใช้ SNI	เซิร์ฟเวอร์แบ็กเอนด์เปิดใช้ Server Name Indication (SNI) แล้ว แต่ไคลเอ็นต์สื่อสารกับเซิร์ฟเวอร์ SNI ไม่ได้	ผู้ใช้ Private Cloud เท่านั้น

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

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

การวินิจฉัย

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

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

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

     

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

     

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

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

     

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

ความละเอียด

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

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

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

การวินิจฉัย

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

   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 (ปลายทาง)

     

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

     

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

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

       

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

     

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

ความละเอียด

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

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

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

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

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

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

คุณอาจเห็นข้อความแสดงข้อผิดพลาดต่างกันไป ขึ้นอยู่กับสาเหตุของแฮนด์เชค 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

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

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

สาเหตุ	คำอธิบาย	ผู้ที่มีสิทธิ์ทำตามขั้นตอนการแก้ปัญหา
ชื่อโฮสต์ไม่ตรงกัน	ชื่อโฮสต์ที่ใช้ใน URL และใบรับรองในคีย์สโตร์ของเราเตอร์ไม่ตรงกัน ตัวอย่างเช่น การจับคู่ที่ไม่ตรงกันจะเกิดขึ้นหากชื่อโฮสต์ที่ใช้ใน URL คือ myorg.domain.com ในขณะที่ใบรับรองมีชื่อโฮสต์ใน CN เป็น CN=something.domain.com.	ผู้ใช้ Edge ส่วนตัวและระบบคลาวด์สาธารณะ
เชนใบรับรองไม่สมบูรณ์หรือไม่ถูกต้อง	ชุดใบรับรองไม่สมบูรณ์หรือไม่ถูกต้อง	ผู้ใช้ Edge ส่วนตัวและระบบคลาวด์สาธารณะเท่านั้น
ใบรับรองที่หมดอายุหรือไม่รู้จักที่ส่งโดยเซิร์ฟเวอร์หรือไคลเอ็นต์	ใบรับรองที่หมดอายุหรือไม่รู้จักจะถูกส่งมาจากเซิร์ฟเวอร์หรือไคลเอ็นต์ที่อยู่ทางทิศเหนือหรือการเชื่อมต่อทางใต้	ผู้ใช้ Edge Private Cloud และ Edge Public Cloud

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

การวินิจฉัย

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

      หากคุณเป็นผู้ใช้ Cloud สาธารณะ ให้ใช้ 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
      

      หากคุณเป็นผู้ใช้ Public Cloud
      

      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": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",

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

รายการอ้างอิง

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

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

การวินิจฉัย

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
      

      หากคุณเป็นผู้ใช้ Public Cloud ให้ทำดังนี้
      

      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
      

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

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

   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. ทั้ง 2 ฝ่ายตรวจสอบโปรโตคอลและอัลกอริทึมชุดการเข้ารหัสที่ใช้ร่วมกัน
   4. เซิร์ฟเวอร์แบ็กเอนด์จะส่งข้อความ Certificate และ Server Hello Done ไปยัง Message Processor ในข้อความ #68
   5. ผู้ประมวลผลข้อความจะส่งการแจ้งเตือนร้ายแรง "Description: Certificate Unknown" ในข้อความ #70
   6. เมื่ออ่านข้อความ #70 แล้ว ไม่มีรายละเอียดเพิ่มเติมนอกเหนือจากข้อความแจ้งเตือนดังที่แสดงด้านล่าง

      
      

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

      

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

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

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

ความละเอียด

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

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

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

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

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

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

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

      

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

      

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

        

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

      

   9. ซึ่งเป็นการยืนยันว่าผู้ประมวลผลข้อความไม่ได้ส่ง server_name ไปยังเซิร์ฟเวอร์แบ็กเอนด์ที่เปิดใช้ SNI
   10. ซึ่งเป็นสาเหตุของความล้มเหลวในแฮนด์เชค TLS/SSL และเหตุผลที่เซิร์ฟเวอร์แบ็กเอนด์ส่งการแจ้งเตือนร้ายแรง: แฮนด์เชคล้มเหลวไปยังผู้ประมวลผลข้อความ
5. ตรวจสอบว่าได้ตั้งค่า jsse.enableSNIExtension property ใน system.properties เป็น false ในตัวประมวลผลข้อความเพื่อยืนยันว่าไม่ได้เปิดใช้งานตัวประมวลผลข้อความเพื่อสื่อสารกับเซิร์ฟเวอร์ที่เปิดใช้ 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 เครื่อง ให้ทำตามขั้นตอนที่ 1 ถึง #4 ซ้ำในเครื่องมือประมวลผลข้อความทั้งหมด

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