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

การตรวจสอบ API

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

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

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

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

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

5. พล็อตรหัสข้อบกพร่องเทียบกับเวลา

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

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

   

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

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

   

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

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

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

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-source:

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

บันทึกของ Message Processor

ขั้นตอนที่ 4: การใช้บันทึกของ Message Processor

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

2. ค้นหารหัสข้อความคำขอที่เฉพาะเจาะจงในบันทึกของ Message Processor (/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 ไม่สำเร็จระหว่าง Message Processor กับเซิร์ฟเวอร์แบ็กเอนด์

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

   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 ไม่สำเร็จเนื่องจาก Message Processor ของ 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 ของ Message Processor

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

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

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

      จากเซิร์ฟเวอร์แบ็กเอนด์

      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",

      ใบรับรองลีดที่จัดเก็บไว้ใน 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

      ไม่มีใบรับรองรูทใน Truststore ของ Message Processor เลย

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

      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 ที่ถูกต้องของ เซิร์ฟเวอร์แบ็กเอนด์ในใบรับรองแบบลีฟหรือใบรับรองเอนทิตีที่เหมือนกับชื่อโฮสต์ ที่ระบุไว้ในปลายทางเป้าหมาย ให้อัปเดตที่เก็บคีย์ของแบ็กเอนด์ด้วย ห่วงโซ่ใบรับรองที่สมบูรณ์

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

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

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>