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

การตรวจสอบ API

ขั้นตอนที่ 1: การใช้การตรวจสอบ API

วิธีวินิจฉัยข้อผิดพลาดโดยใช้การตรวจสอบ API

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

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. ตรวจสอบว่าเปิดใช้แสดง FlowInfo ทั้งหมด แล้ว

   
3. เลือกคำขอที่ไม่สำเร็จรายการหนึ่งและตรวจสอบการติดตาม
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 ล้มเหลว เนื่องจาก Message Processor ของ Apigee Edge ไม่สามารถตรวจสอบความถูกต้องของเซิร์ฟเวอร์แบ็กเอนด์ ใบรับรอง
7. ไปที่ระยะ AX (Analytics Data Recorded) ในการติดตามและคลิก

8. เลื่อนลงไปที่ส่วนส่วนหัวข้อผิดพลาดเกี่ยวกับรายละเอียดเฟส และระบุ ของ 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

ส่วนหัวของข้อผิดพลาด	ค่า
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 ตรวจสอบใบรับรองของเซิร์ฟเวอร์แบ็กเอนด์ไม่ได้

ระยะที่ 1

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

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

openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT#

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

ระยะที่ 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 ให้เลือกสภาพแวดล้อม > ข้อมูลอ้างอิง จดชื่อใน คอลัมน์ข้อมูลอ้างอิงสำหรับข้อมูลอ้างอิง Truststore ที่เฉพาะเจาะจง นี่คือ ชื่อ Truststore

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

      

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

      myCompanyTruststoreRef: myCompanyTruststore

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

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

      ผู้ใช้ระบบคลาวด์สาธารณะ:

      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 รายการที่ใช้ในตัวอย่างนี้อธิบายไว้ใน ใช้ curl

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

      ใบรับรองจากตัวอย่าง Truststore myCompanyTruststore คือ:

      [
        "serverCert"
      ]

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

      ผู้ใช้ระบบคลาวด์สาธารณะ:

      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 รายการที่ใช้ในตัวอย่างนี้อธิบายไว้ใน ใช้ curl

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

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

      ใบแจ้ง/ใบรับรองหน่วยงาน:

      "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. ใบรับรอง Leaf:

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

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

      จาก Truststore (ไคลเอ็นต์) ของ Message Processor

      "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 (ไคลเอ็นต์) ของ Message Processor

      "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

      ไม่มีใบรับรองรูทใน Message Processor 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ไปยังลูกค้า แอปพลิเคชัน

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>