503 ไม่สามารถใช้บริการได้ - แฮนด์เชค SSL ล้มเหลว

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

ลักษณะปัญหา

แอปพลิเคชันไคลเอ็นต์จะได้รับรหัสสถานะ HTTP เป็น 503 Service Unavailable พร้อมรหัสข้อผิดพลาด messaging.adaptors.http.flow.SslHandshakeFailed เป็นการตอบกลับสำหรับการเรียก API

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

แอปพลิเคชันไคลเอ็นต์จะได้รับโค้ดตอบกลับต่อไปนี้ 

HTTP/1.1 503 Service Unavailable

นอกจากนี้ คุณอาจพบข้อความแสดงข้อผิดพลาดต่อไปนี้ 

{
   "fault":{
      "faultstring":"SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.SslHandshakeFailed"
      }
   }
}

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

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

คุณต้องใช้เทคนิคที่เหมาะสมในการแก้ปัญหา ทั้งนี้ขึ้นอยู่กับข้อความแสดงข้อผิดพลาดที่พบใน faultstring Playbook นี้จะอธิบายวิธีแก้ปัญหาข้อผิดพลาดนี้หากคุณเห็นข้อความแสดงข้อผิดพลาดSSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target ในfaultstring

ข้อผิดพลาดนี้เกิดขึ้นในกระบวนการแฮนด์เชค SSL ระหว่างผู้ประมวลผลข้อความของ Apigee Edge กับเซิร์ฟเวอร์แบ็กเอนด์

  • หาก truststore ของผู้ประมวลผลข้อความของ Apigee Edge มีคุณสมบัติดังนี้
    • มีเชนใบรับรองที่ไม่ตรงกับเชนใบรับรองที่สมบูรณ์ของเซิร์ฟเวอร์แบ็กเอนด์ หรือ
    • ไม่มีเชนใบรับรองที่สมบูรณ์ของเซิร์ฟเวอร์แบ็กเอนด์
  • กรณีที่เซิร์ฟเวอร์แบ็กเอนด์แสดงเชนใบรับรอง ให้ทําดังนี้

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

สาเหตุ คำอธิบาย วิธีการแก้ปัญหาที่ใช้กับ
ใบรับรองหรือชุดใบรับรองที่ไม่ถูกต้อง/ไม่สมบูรณ์ใน Truststore ของผู้ประมวลผลข้อมูลข้อความ ใบรับรองและ/หรือเชนที่จัดเก็บใน Truststore ของ Message Processor ของ Apigee Edge ไม่ตรงกับเชนใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์ หรือไม่มีเชนใบรับรองที่สมบูรณ์ของเซิร์ฟเวอร์แบ็กเอนด์ ผู้ใช้ Edge ส่วนตัวและระบบคลาวด์สาธารณะ
FQDN ในใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์และชื่อโฮสต์ในปลายทางเป้าหมายไม่ตรงกัน ใบรับรองที่เซิร์ฟเวอร์แบ็กเอนด์แสดงมี FQDN ที่ไม่ตรงกับชื่อโฮสต์ที่ระบุในปลายทางเป้าหมาย ผู้ใช้ Edge ส่วนตัวและระบบคลาวด์สาธารณะ
ใบรับรองที่ไม่ถูกต้อง/ไม่สมบูรณ์หรือเชนใบรับรองที่แสดงโดยเซิร์ฟเวอร์แบ็กเอนด์ เชนใบรับรองที่แสดงโดยเซิร์ฟเวอร์แบ็กเอนด์ไม่ถูกต้องหรือไม่สมบูรณ์ ผู้ใช้ Edge ส่วนตัวและระบบคลาวด์สาธารณะ

ขั้นตอนการวินิจฉัยทั่วไป

ใช้เครื่องมือ/เทคนิคอย่างใดอย่างหนึ่งต่อไปนี้เพื่อวิเคราะห์ข้อผิดพลาดนี้

การตรวจสอบ API

ขั้นตอนที่ 1: การใช้ API Monitoring

วิธีวินิจฉัยข้อผิดพลาดโดยใช้ API Monitoring

  1. ลงชื่อเข้าใช้ UI ของ Apigee Edge ในฐานะผู้ใช้ที่มี บทบาทที่เหมาะสม

  2. เปลี่ยนเป็นองค์กรที่คุณต้องการตรวจสอบปัญหา

  3. ไปที่หน้าวิเคราะห์ > การตรวจสอบ API > ตรวจสอบ
  4. เลือกกรอบเวลาเฉพาะที่คุณพบข้อผิดพลาด

  5. พล็อตโค้ดข้อผิดพลาดเทียบกับเวลา

  6. เลือกเซลล์ที่มีรหัสข้อผิดพลาด messaging.adaptors.http.flow.SslHandshakeFailed ดังที่แสดงด้านล่าง

    ( ดูรูปภาพขนาดใหญ่ขึ้น)

  7. ข้อมูลเกี่ยวกับโค้ดข้อผิดพลาด messaging.adaptors.http.flow.SslHandshakeFailed จะแสดงดังที่แสดงด้านล่าง

    ( ดูรูปภาพขนาดใหญ่ขึ้น)

  8. คลิกดูบันทึก แล้วขยายแถวสำหรับคำขอที่ไม่สำเร็จ

    ( ดูรูปภาพขนาดใหญ่ขึ้น)

  9. ดูรายละเอียดต่อไปนี้จากหน้าต่าง Logs
    • ขอรหัสข้อความ
    • รหัสสถานะ: 503
    • แหล่งที่มาของข้อผิดพลาด: target
    • รหัสข้อผิดพลาด: messaging.adaptors.http.flow.SslHandshakeFailed

Trace

ขั้นตอนที่ 2: การใช้เครื่องมือติดตาม

วิธีวินิจฉัยข้อผิดพลาดโดยใช้เครื่องมือติดตาม

  1. เปิดใช้เซสชันการติดตามและ
    • รอให้ข้อผิดพลาด 503 Service Unavailable ที่มีรหัสข้อผิดพลาด messaging.adaptors.http.flow.SslHandshakeFailed เกิดขึ้น หรือ
    • หากทำให้ปัญหาเกิดซ้ำได้ ให้เรียก API เพื่อจำลองปัญหา 503 Service Unavailable

  2. ตรวจสอบว่าเปิดใช้ Show FlowInfos ทั้งหมดแล้ว โดยทำดังนี้

  3. เลือกคำขอที่ล้มเหลว 1 รายการและตรวจสอบการติดตาม
  4. เลื่อนดูการติดตามระยะต่างๆ และค้นหาตำแหน่งที่เกิดข้อผิดพลาด

  5. โดยทั่วไป คุณจะพบข้อผิดพลาดหลังจากระยะเริ่มต้นโฟลว์คำขอเป้าหมายดังที่แสดงด้านล่าง

    ( ดูรูปภาพขนาดใหญ่ขึ้น)

  6. จดจำค่าต่อไปนี้จากการติดตาม
    • ข้อผิดพลาด: SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    • error.cause: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    • error.class: com.apigee.errors.http.server.ServiceUnavailableException
    • ค่าของข้อผิดพลาด SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target บ่งบอกว่าแฮนด์เชค SSL ล้มเหลว เนื่องจากผู้ประมวลผลข้อความของ Apigee Edge ตรวจสอบใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์ไม่ได้
  7. ไปที่เฟส AX (บันทึกข้อมูล Analytics) ในการติดตามแล้วคลิกเลือกดังกล่าว

  8. เลื่อนลงไปที่ส่วน Phase Details Error Headers และระบุค่าของ X-Apigee-fault-code และ X-Apigee-fault-source และ X-Apigee-Message-ID ดังที่แสดงด้านล่าง

    ( ดูรูปภาพขนาดใหญ่ขึ้น)

  9. บันทึกค่าของ X-Apigee-fault-code, X-Apigee-fault-source และ X-Apigee-Message-ID
    10. ส่วนหัวที่ผิดพลาด ค่า
    X-Apigee-fault-code messaging.adaptors.http.flow.SslHandshakeFailed
    X-Apigee-fault-source target
    X-Apigee-Message-ID MESSAGE_ID

NGINX

ขั้นตอนที่ 3: การใช้บันทึกการเข้าถึง NGINX

วิธีวินิจฉัยข้อผิดพลาดโดยใช้บันทึกการเข้าถึง NGINX

  1. หากเป็นผู้ใช้ Private Cloud คุณจะใช้บันทึกการเข้าถึง NGINX เพื่อระบุข้อมูลคีย์เกี่ยวกับ HTTP 503 Service Unavailable ได้

  2. ตรวจสอบบันทึกการเข้าถึง NGINX ดังนี้

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  3. ค้นหาเพื่อดูว่ามีข้อผิดพลาด 503 ที่มีรหัสข้อผิดพลาด messaging.adaptors.http.flow.SslHandshakeFailed ในช่วงเวลาที่ระบุหรือไม่ (หากเกิดปัญหาในอดีต) หรือมีคำขอใดที่ยังคงดำเนินการไม่สำเร็จเมื่อใช้ 503

  4. หากพบข้อผิดพลาด 503 ที่มี X-Apigee-fault-code ตรงกับค่าของ messaging.adaptors.http.flow.SslHandshakeFailed ให้ระบุค่าของ X-Apigee-fault-source

    ตัวอย่างข้อผิดพลาด 503 จากบันทึกการเข้าถึง NGINX

    ( ดูรูปภาพขนาดใหญ่ขึ้น)

    ตัวอย่างรายการด้านบนจากบันทึกการเข้าถึง NGINX มีค่าต่อไปนี้สำหรับ X-Apigee-fault-code และ X-Apigee-fault-code

    ส่วนหัว ค่า
    X-Apigee-fault-code messaging.adaptors.http.flow.SslHandshakeFailed
    X-Apigee-fault-source target

บันทึกตัวประมวลผลข้อความ

ขั้นตอนที่ 4: การใช้บันทึกผู้ประมวลผลข้อความ

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

  2. ค้นหารหัสข้อความคำขอที่เฉพาะเจาะจงในบันทึกผู้ประมวลผลข้อความ (/opt/apigee/var/log/edge-message-processor/logs/system.log) คุณอาจสังเกตเห็นข้อผิดพลาดต่อไปนี้

    org:myorg env:test api:MyProxy rev:1
messageid:myorg-28247-3541813-1
NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
SSLClientChannel[Connected: Remote:X.X.X.X:443
Local:192.168.194.140:55102]@64596 useCount=1
bytesRead=0 bytesWritten=0 age=233ms  lastIO=233ms
isOpen=true handshake failed, message: General SSLEngine problem

    ข้อผิดพลาดข้างต้นบ่งบอกว่าแฮนด์เชค SSL ล้มเหลวระหว่างผู้ประมวลผลข้อความและเซิร์ฟเวอร์แบ็กเอนด์

    ซึ่งจะตามมาโดยข้อยกเว้นเกี่ยวกับสแต็กเทรซโดยละเอียดดังที่แสดงด้านล่าง

    org:myorg env:test api:MyProxy rev:1
messageid:myorg-28247-3541813-1
NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
RequestWriteListener.onException(HTTPRequest@1522922c)
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
	at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1478)
	at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
	... <snipped>
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:203)
	at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
	... <snipped>
Caused by: sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
certification path to requested target
	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
	... <snipped>

    โปรดทราบว่าแฮนด์เชคที่ไม่สำเร็จเกิดจากสาเหตุต่อไปนี้

    Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

    ซึ่งหมายความว่าแฮนด์เชค SSL ล้มเหลวเนื่องจากผู้ประมวลผลข้อความของ Apigee Edge ตรวจสอบใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์ไม่ได้

สาเหตุ: ใบรับรองหรือชุดใบรับรองไม่ถูกต้อง/ไม่สมบูรณ์ใน Truststore ของผู้ประมวลผลข้อมูลข้อความ

การวินิจฉัย

  1. กำหนด Fault Code, Fault Source สำหรับข้อผิดพลาดที่พบโดยใช้ API Monitoring, เครื่องมือติดตาม หรือบันทึกการเข้าถึง NGINX ตามที่อธิบายไว้ในขั้นตอนการวิเคราะห์ทั่วไป
  2. หากรหัสข้อผิดพลาดคือ messaging.adaptors.http.flow.SslHandshakeFailed ให้ระบุข้อความแสดงข้อผิดพลาดโดยใช้วิธีใดวิธีหนึ่งต่อไปนี้
  3. หากข้อความแสดงข้อผิดพลาดคือ sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target" แสดงว่าแฮนด์เชค SSL ล้มเหลว เนื่องจากผู้ประมวลผลข้อความของ Apigee Edge ตรวจสอบใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์ไม่ได้

คุณแก้ไขข้อบกพร่องนี้ได้เป็น 2 ระยะ ดังนี้

  1. ระยะที่ 1: กำหนดสายใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์
  2. ระยะที่ 2: เปรียบเทียบชุดใบรับรองที่จัดเก็บไว้ใน Truststore ของผู้ประมวลผลข้อความ

ระยะที่ 1

ระยะที่ 1: กำหนดชุดใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์

ใช้วิธีใดวิธีหนึ่งต่อไปนี้เพื่อระบุสายใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์

openssl

เรียกใช้คำสั่ง openssl กับชื่อโฮสต์ของเซิร์ฟเวอร์แบ็กเอนด์ดังนี้

openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT#

จดบันทึกเชนใบรับรองจากเอาต์พุตของคำสั่งข้างต้น

ตัวอย่างเชนใบรับรองเซิร์ฟเวอร์แบ็กเอนด์จากเอาต์พุตคำสั่ง openssl

Certificate chain
 0 s:/CN=mocktarget.apigee.net
   i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
 1 s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
 2 s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

tcpdump

  1. หากคุณเป็นผู้ใช้ Public Cloud ให้บันทึกแพ็กเก็ต TCP/IP ในเซิร์ฟเวอร์แบ็กเอนด์
  2. หากคุณเป็นผู้ใช้ Private Cloud คุณจะบันทึกแพ็กเก็ต TCP/IP ในเซิร์ฟเวอร์แบ็กเอนด์หรือตัวประมวลผลข้อความได้ หากเป็นไปได้ ให้บันทึกแพ็กเก็ตไว้ในเซิร์ฟเวอร์แบ็กเอนด์ขณะที่ระบบถอดรหัสแพ็กเก็ตไว้ในเซิร์ฟเวอร์แบ็กเอนด์

  3. ใช้คำสั่ง tcpdump ต่อไปนี้เพื่อบันทึกแพ็กเก็ต TCP/IP

    tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME

  4. วิเคราะห์แพ็กเก็ต TCP/IP โดยใช้เครื่องมือ Wireshark หรือเครื่องมือที่คล้ายกันที่คุณคุ้นเคย

    การวิเคราะห์ตัวอย่างของ Tcpdump

    ( ดูรูปภาพขนาดใหญ่ขึ้น)

    • แพ็คเก็ตที่ 43: ผู้ประมวลผลข้อความ (แหล่งที่มา) ส่งข้อความ Client Hello ไปยังเซิร์ฟเวอร์แบ็กเอนด์ (ปลายทาง)
    • แพ็กเก็ตที่ 44: เซิร์ฟเวอร์แบ็กเอนด์รับทราบการได้รับข้อความ Client Hello จากผู้ประมวลผลข้อความแล้ว
    • แพ็กเก็ตที่ 45: เซิร์ฟเวอร์แบ็กเอนด์ส่งข้อความ Server Hello พร้อมใบรับรองของเซิร์ฟเวอร์นั้น
    • Packet #46: ผู้ประมวลผลข้อความรับทราบการรับข้อความ Server Hello และใบรับรอง

    • แพ็คเก็ตที่ 47: ผู้ประมวลผลข้อความจะส่งข้อความ FIN, ACK ตามด้วย RST, ACK ในแพ็กเก็ตที่ 48

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

    • คุณกลับไปตรวจสอบแพ็กเกจ #45 และดูสายใบรับรองที่ส่งโดยเซิร์ฟเวอร์แบ็กเอนด์ได้

      ( ดูรูปภาพขนาดใหญ่ขึ้น)

    • ในตัวอย่างนี้ คุณจะเห็นว่าเซิร์ฟเวอร์ได้ส่งใบรับรอง Leaf ที่มี common name (CN) = mocktarget.apigee.net ตามด้วยใบรับรองกลางที่มี CN= GTS CA 1D4 และใบรับรองรูทที่มี CN = GTX Root R1

    หากคุณแน่ใจว่าการตรวจสอบการรับรองของเซิร์ฟเวอร์ล้มเหลว ให้ไปที่ระยะที่ 2: เปรียบเทียบใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์กับใบรับรองที่จัดเก็บไว้ใน Truststore ของผู้ประมวลผลข้อความ

ระยะที่ 2

ระยะที่ 2: เปรียบเทียบใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์และใบรับรองที่จัดเก็บไว้ใน Truststore ของผู้ประมวลผลข้อความ

  1. กำหนดเชนใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์
  2. กำหนดใบรับรองที่จัดเก็บไว้ใน Truststore ของผู้ประมวลผลข้อความโดยใช้ขั้นตอนต่อไปนี้

    1. รับชื่ออ้างอิง Truststore จากองค์ประกอบ TrustStore ในส่วน SSLInfo ใน TargetEndpoint

      มาดูตัวอย่างส่วน SSLInfo ในการกำหนดค่า TargetEndpoint กัน

      <TargetEndpoint name="default">
...
   <HTTPTargetConnection>
      <Properties />
      <SSLInfo>
         <Enabled>true</Enabled>
         <ClientAuthEnabled>true</ClientAuthEnabled>
         <KeyStore>ref://myKeystoreRef</KeyStore>
         <KeyAlias>myKey</KeyAlias>
         <TrustStore>
            ref://myCompanyTrustStoreRef
         </TrustStore>
      </SSLInfo>
   </HTTPTargetConnection>
   ...
</TargetEndpoint>
    2. ในตัวอย่างข้างต้น ชื่อการอ้างอิง TrustStore คือ myCompanyTruststoreRef

    3. ใน Edge UI ให้เลือกสภาพแวดล้อม > การอ้างอิง จดชื่อในคอลัมน์ข้อมูลอ้างอิงสำหรับข้อมูลอ้างอิงของ Trustedstore ที่เฉพาะเจาะจง นี่จะเป็นชื่อ Truststore ของคุณ

      ( ดูรูปภาพขนาดใหญ่ขึ้น)

    4. ในตัวอย่างข้างต้น ชื่อ Truststore คือ

      myCompanyTruststoreRef: myCompanyTruststore

  3. รับใบรับรองที่จัดเก็บไว้ใน Truststore (ที่กำหนดในขั้นตอนก่อนหน้า) โดยใช้ API ต่อไปนี้

    1. รับใบรับรองทั้งหมดสำหรับคีย์สโตร์หรือ Truststore API นี้จะแสดงใบรับรองทั้งหมดใน Truststore ที่เฉพาะเจาะจง

      ผู้ใช้ Public Cloud

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"

      ผู้ใช้ Private Cloud

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"

      สถานที่:

      • ORGANIZATION_NAME คือชื่อองค์กร
      • ENVIRONMENT_NAME คือชื่อสภาพแวดล้อม
      • KEYSTORE_NAME คือชื่อของคีย์สโตร์
      • มีการตั้งค่า $TOKEN เป็นโทเค็นเพื่อการเข้าถึง OAuth 2.0 ตามที่อธิบายไว้ในรับโทเค็นเพื่อการเข้าถึง OAuth 2.0
      • ตัวเลือก curl ที่ใช้ในตัวอย่างนี้อธิบายไว้ในหัวข้อ Use curl

      ตัวอย่างเอาต์พุต

      ใบรับรองจากตัวอย่าง Truststore myCompanyTruststore มีดังนี้ 

      [
  "serverCert"
]

    2. รับรายละเอียดใบรับรองสำหรับใบรับรองเฉพาะจากคีย์สโตร์หรือ Truststore API นี้จะแสดงข้อมูลเกี่ยวกับใบรับรองที่เฉพาะเจาะจงใน Truststore ที่เฉพาะเจาะจง

      ผู้ใช้ Public Cloud

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"

      ผู้ใช้ Private Cloud

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#>/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"

      สถานที่:

      • ORGANIZATION_NAME คือชื่อองค์กร
      • ENVIRONMENT_NAME คือชื่อสภาพแวดล้อม
      • KEYSTORE_NAME คือชื่อของคีย์สโตร์
      • CERT_NAME คือชื่อของใบรับรอง
      • มีการตั้งค่า $TOKEN เป็นโทเค็นเพื่อการเข้าถึง OAuth 2.0 ตามที่อธิบายไว้ในรับโทเค็นเพื่อการเข้าถึง OAuth 2.0
      • ตัวเลือก curl ที่ใช้ในตัวอย่างนี้อธิบายไว้ในหัวข้อ Use curl

      ตัวอย่างเอาต์พุต

      รายละเอียดของ serverCert จะแสดงหัวเรื่องและผู้ออกบัตรดังนี้

      ใบรับรอง Leaf/Entity:

      "subject": "CN=mocktarget.apigee.net",
"issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",

      ใบรับรองกลาง:

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
"issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",

  4. ยืนยันว่าใบรับรองเซิร์ฟเวอร์จริงที่ได้รับในขั้นตอนที่ 1 และใบรับรองที่จัดเก็บไว้ใน Truststore ที่ได้รับในขั้นตอนที่ 3 ตรงกัน หากไม่ตรงกัน ปัญหาก็เกิดจากสาเหตุนี้

    จากตัวอย่างที่แสดงด้านบน มาดูใบรับรองทีละ 1 รายการกัน

    1. ใบรับรอง Leaf:

      จากเซิร์ฟเวอร์แบ็กเอนด์ ให้ทำดังนี้

      s:/CN=mocktarget.apigee.net
i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4

      จาก Truststore ของผู้ประมวลผลข้อความ (ไคลเอ็นต์)

      "subject": "CN=mocktarget.apigee.net",
"issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",

      ใบรับรอง Leaf ที่เก็บไว้ใน Truststore ตรงกับใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์

    2. ใบรับรองกลาง:

      จากเซิร์ฟเวอร์แบ็กเอนด์ ให้ทำดังนี้

      s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

      จาก Truststore ของผู้ประมวลผลข้อความ (ไคลเอ็นต์)

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
"issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",

      ใบรับรองกลางที่เก็บไว้ใน Truststore ตรงกับใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์

    3. ใบรับรองรูท:

      จากเซิร์ฟเวอร์แบ็กเอนด์ ให้ทำดังนี้

      s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

      ไม่พบใบรับรองรูทใน Truststore ของผู้ประมวลผลข้อความโดยสมบูรณ์

    4. เนื่องจากไม่พบใบรับรองรูทใน Truststore ตัวประมวลผลข้อความจึงแสดงข้อยกเว้นต่อไปนี้

      sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

      และแสดงผล 503 Service Unavailable ที่มีรหัสข้อผิดพลาด messaging.adaptors.http.flow.SslHandshakeFailed ไปยังแอปพลิเคชันไคลเอ็นต์

ความละเอียด

  1. ตรวจสอบว่าคุณมีเชนใบรับรองที่เหมาะสมและสมบูรณ์ของเซิร์ฟเวอร์แบ็กเอนด์
  2. หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ ให้ทำตามวิธีการใน อัปเดตใบรับรอง TLS สำหรับระบบคลาวด์เพื่ออัปเดตใบรับรองเป็น Truststore ของผู้ประมวลผลข้อมูลข้อความของ Apigee Edge
  3. หากคุณเป็นผู้ใช้ Private Cloud ให้ทำตามวิธีการใน อัปเดตใบรับรอง TLS สำหรับ Private Cloud เพื่ออัปเดตใบรับรองเป็น Truststore ของผู้ประมวลผลข้อมูลข้อความของ Apigee Edge

สาเหตุ: FQDN ในใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์และชื่อโฮสต์ในปลายทางเป้าหมายไม่ตรงกัน

หากเซิร์ฟเวอร์แบ็กเอนด์แสดงเชนใบรับรองที่มี FQDN ซึ่งไม่ตรงกับชื่อโฮสต์ที่ระบุในปลายทางเป้าหมาย กระบวนการข้อความของ Apigee Edge จะแสดงข้อผิดพลาด SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

การวินิจฉัย

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

    ตัวอย่าง TargetEndpoint

    <TargetEndpoint name="default">
   …
   <HTTPTargetConnection>
      <Properties />
      <SSLInfo>
         <Enabled>true</Enabled>
         <TrustStore>ref://myTrustStoreRef</TrustStore>
      </SSLInfo>
      <URL>https://backend.company.com/resource</URL>
   </HTTPTargetConnection>
</TargetEndpoint>

    ในตัวอย่างข้างต้น ชื่อโฮสต์ของเซิร์ฟเวอร์แบ็กเอนด์คือ backend.company.com

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

    openssl s_client -connect BACKEND_SERVER_HOST_NAME>:PORT_#>

    เช่น

    openssl s_client -connect backend.company.com:443

    ตรวจสอบส่วน Certificate chain และจดบันทึก FQDN ที่ระบุเป็นส่วนหนึ่งของ CN ในหัวข้อของใบรับรอง Leaf 

    Certificate chain
 0 s:/CN=backend.apigee.net
   i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
 1 s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
 2 s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

    ในตัวอย่างข้างต้น FQDN ของเซิร์ฟเวอร์แบ็กเอนด์คือ backend.apigee.net

  3. หากชื่อโฮสต์ของเซิร์ฟเวอร์แบ็กเอนด์ที่ได้รับจากขั้นตอนที่ 1 และ FQDN ที่ได้รับขั้นตอนที่ 2 ไม่ตรงกัน แสดงว่าเป็นสาเหตุของข้อผิดพลาด
  4. ในตัวอย่างที่กล่าวถึงข้างต้น ชื่อโฮสต์ในปลายทางเป้าหมายคือ backend.company.com แต่ชื่อ FQDN ในใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์คือ backend.apigee.net คุณจะได้รับข้อผิดพลาดนี้เนื่องจากไม่ตรงกัน

ความละเอียด

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

FQDN ถูกต้อง

อัปเดตคีย์สโตร์ของเซิร์ฟเวอร์แบ็กเอนด์ด้วย FQDN ที่ถูกต้อง เชนใบรับรองที่ถูกต้องและสมบูรณ์

  1. หากคุณไม่มีใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์ที่มี FQDN ที่ถูกต้อง ให้จัดหาใบรับรองที่เหมาะสมจาก CA (ผู้ออกใบรับรอง) ที่เหมาะสม

  2. ตรวจสอบว่าคุณมีห่วงโซ่ใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์ที่ถูกต้องและครบถ้วน

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

เซิร์ฟเวอร์แบ็กเอนด์ที่ถูกต้อง

อัปเดตปลายทางเป้าหมายด้วยชื่อโฮสต์ของเซิร์ฟเวอร์แบ็กเอนด์ที่ถูกต้อง

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

  2. บันทึกการเปลี่ยนแปลงพร็อกซี API

    ในตัวอย่างที่กล่าวถึงข้างต้น หากระบุชื่อโฮสต์ของเซิร์ฟเวอร์แบ็กเอนด์ไม่ถูกต้อง คุณจะแก้ไขได้โดยใช้ FQDN จากใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์ นั่นคือ backend.apigee.net ดังนี้

    <TargetEndpoint name="default">
   …
   <HTTPTargetConnection>
      <Properties />
      <SSLInfo>
         <Enabled>true</Enabled>
         <TrustStore>ref://myTrustStoreRef</TrustStore>
      </SSLInfo>
      <URL>https://backend.apigee.net/resource</URL>
   </HTTPTargetConnection>
</TargetEndpoint>

สาเหตุ: ใบรับรองไม่ถูกต้องหรือไม่สมบูรณ์หรือเชนใบรับรองที่แสดงโดยเซิร์ฟเวอร์แบ็กเอนด์

การวินิจฉัย

  1. รับเชนใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์โดยเรียกใช้คำสั่ง openssl กับชื่อโฮสต์ของเซิร์ฟเวอร์แบ็กเอนด์ดังนี้ 
    openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT_#

    สังเกต Certificate chain จากเอาต์พุตของคำสั่งข้างต้น

    ตัวอย่างเชนใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์จากเอาต์พุตคำสั่ง openssl

    Certificate chain
 0 s:/CN=mocktarget.apigee.net
   i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
 1 s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
  2. ตรวจสอบว่าคุณมีเชนใบรับรองที่ถูกต้องและสมบูรณ์ตามที่อธิบายไว้ในเชนใบรับรองการตรวจสอบ

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

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

ความละเอียด

อัปเดตคีย์สโตร์ของเซิร์ฟเวอร์แบ็กเอนด์ด้วยชุดใบรับรองที่ถูกต้องและสมบูรณ์:

  1. ตรวจสอบว่าคุณมีกลุ่มใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์ที่ถูกต้องและสมบูรณ์

  2. อัปเดตชุดใบรับรองที่ถูกต้องและสมบูรณ์ในคีย์สโตร์ของเซิร์ฟเวอร์แบ็กเอนด์

หากยังคงพบปัญหา ให้ไปที่ ต้องรวบรวมข้อมูลการวินิจฉัย

ต้องรวบรวมข้อมูลการวินิจฉัย

หากปัญหายังคงอยู่แม้ว่าจะทำตามวิธีการข้างต้นแล้ว ให้รวบรวมข้อมูลการวินิจฉัยต่อไปนี้และติดต่อทีมสนับสนุนของ Apigee Edge

  • หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ ให้ระบุข้อมูลต่อไปนี้
    • ชื่อองค์กร
    • ชื่อสภาพแวดล้อม
    • ชื่อพร็อกซี API
    • ใช้คำสั่ง curl ให้เสร็จสมบูรณ์เพื่อจำลองข้อผิดพลาด
    • ไฟล์การย้ายข้อมูลที่แสดงข้อผิดพลาด

    • เอาต์พุตของคำสั่ง openssl:

      openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT_#

    • แพ็กเก็ต TCP/IP ที่บันทึกในเซิร์ฟเวอร์แบ็กเอนด์
  • หากคุณเป็นผู้ใช้ Private Cloud โปรดระบุข้อมูลต่อไปนี้
    • สังเกตข้อความแสดงข้อผิดพลาดเสร็จสมบูรณ์
    • ชุดพร็อกซี API
    • ไฟล์การย้ายข้อมูลที่แสดงข้อผิดพลาด
    • บันทึกตัวประมวลผลข้อความ /opt/apigee/var/log/edge-message-processor/logs/system.log
    • เอาต์พุตของคำสั่ง openssl:
      openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT_#
    • แพ็กเก็ต TCP/IP ที่บันทึกในเซิร์ฟเวอร์แบ็กเอนด์หรือผู้ประมวลผลข้อมูลข้อความ
    • เอาต์พุตของ รับใบรับรองทั้งหมดสำหรับ Keystore หรือ Truststore API รวมถึงรายละเอียดของใบรับรองแต่ละรายการที่ได้รับโดยใช้ รับรายละเอียดใบรับรองจากคีย์สโตร์หรือ Truststore API

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