503 Dịch vụ Không khả dụng - Lỗi Bắt tay SSL

Giám sát API

Quy trình 1: Sử dụng tính năng Giám sát API

Cách chẩn đoán lỗi bằng tính năng Giám sát API:

1. Đăng nhập vào giao diện người dùng Apigee Edge với tư cách là người dùng có vai trò phù hợp.

2. Chuyển sang tổ chức mà bạn muốn điều tra vấn đề.

   
3. Chuyển đến trang Phân tích > Giám sát API > Điều tra.
4. Chọn khung thời gian cụ thể mà bạn nhận thấy lỗi.

5. Vẽ Mã lỗi theo Thời gian.

6. Chọn một ô có mã lỗi messaging.adaptors.http.flow.SslHandshakeFailed như minh hoạ bên dưới:

   ( xem hình ảnh lớn hơn)

   

7. Thông tin về mã lỗi messaging.adaptors.http.flow.SslHandshakeFailed sẽ xuất hiện như hình dưới đây:

   ( xem hình ảnh lớn hơn)

   

8. Nhấp vào Xem nhật ký rồi mở rộng hàng của yêu cầu không thực hiện được.

   ( xem hình ảnh lớn hơn)

   
9. Trong cửa sổ Nhật ký, hãy lưu ý những thông tin sau:
   • Mã thông báo yêu cầu
   • Mã trạng thái: 503
   • Nguồn lỗi: target
   • Mã lỗi: messaging.adaptors.http.flow.SslHandshakeFailed

Trace

Quy trình 2: Sử dụng công cụ Trace

Cách chẩn đoán lỗi bằng công cụ Trace (Theo dõi):

1. Bật phiên theo dõi và một trong hai
   • Chờ lỗi 503 Service Unavailable với mã lỗi messaging.adaptors.http.flow.SslHandshakeFailed xảy ra, hoặc
   • Nếu bạn có thể tái hiện vấn đề, hãy thực hiện lệnh gọi API để tái hiện vấn đề 503 Service Unavailable

2. Đảm bảo bạn đã bật chế độ Show all FlowInfos (Hiện tất cả FlowInfo):

   
3. Chọn một trong các yêu cầu không thực hiện được và kiểm tra dấu vết.
4. Điều hướng qua các giai đoạn khác nhau của dấu vết và xác định vị trí xảy ra lỗi.

5. Bạn thường sẽ thấy lỗi này sau giai đoạn Target Request Flow Started (Đã bắt đầu quy trình yêu cầu mục tiêu) như minh hoạ bên dưới:

   ( xem hình ảnh lớn hơn)

   
6. Ghi lại các giá trị sau đây từ dấu vết:
   • error: 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
   • Giá trị của lỗi 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 cho biết SSL Handshake không thành công, vì Trình xử lý thông báo của Apigee Edge không xác thực được chứng chỉ của máy chủ phụ trợ.
7. Chuyển đến Giai đoạn AX (Dữ liệu Analytics được ghi lại) trong dấu vết rồi nhấp vào giai đoạn đó.

8. Di chuyển xuống phần Phase Details Error Headers (Tiêu đề lỗi chi tiết theo giai đoạn) và xác định các giá trị của X-Apigee-fault-code và X-Apigee-fault-source, cũng như X-Apigee-Message-ID như minh hoạ dưới đây:

   ( xem hình ảnh lớn hơn)

   
9. Lưu ý các giá trị của X-Apigee-fault-code, X-Apigee-fault-source và X-Apigee-Message-ID:

Tiêu đề lỗi	Giá trị
X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
X-Apigee-fault-source	target
X-Apigee-Message-ID	MESSAGE_ID

NGINX

Quy trình 3: Sử dụng nhật ký truy cập NGINX

Cách chẩn đoán lỗi bằng nhật ký truy cập NGINX:

1. Nếu là người dùng Đám mây riêng, bạn có thể sử dụng nhật ký truy cập NGINX để xác định thông tin chính về 503 Service Unavailable HTTP.

2. Kiểm tra nhật ký truy cập NGINX:

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

3. Tìm xem có lỗi 503 nào với mã lỗi messaging.adaptors.http.flow.SslHandshakeFailed trong một khoảng thời gian cụ thể hay không (nếu vấn đề xảy ra trong quá khứ) hoặc có yêu cầu nào vẫn không thành công với 503 hay không.

4. Nếu bạn thấy bất kỳ lỗi 503 nào có X-Apigee-fault-code trùng khớp với giá trị của messaging.adaptors.http.flow.SslHandshakeFailed, thì hãy xác định giá trị của X-Apigee-fault-source.

   Ví dụ về lỗi 503 trong nhật ký truy cập của NGINX:

   ( xem hình ảnh lớn hơn)

   

   Mục nhập mẫu ở trên trong nhật ký truy cập NGINX có các giá trị sau cho X-Apigee-fault-code và X-Apigee-fault-source:

   Tiêu đề	Giá trị
   X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
   X-Apigee-fault-source	target

Nhật ký Trình xử lý tin nhắn

Quy trình 4: Sử dụng nhật ký của Trình xử lý tin nhắn

1. Xác định mã nhận dạng thông báo của một trong các yêu cầu không thành công bằng cách sử dụng tính năng Giám sát API, công cụ Theo dõi hoặc Nhật ký truy cập NGINX như được giải thích trong phần Các bước chẩn đoán thường gặp.

2. Tìm mã nhận dạng thông báo yêu cầu cụ thể trong nhật ký Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log). Bạn có thể thấy lỗi sau:

   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
   

   Lỗi trên cho biết quá trình bắt tay SSL không thành công giữa Trình xử lý thông báo và máy chủ phụ trợ.

   Sau đó, sẽ có một ngoại lệ với dấu vết ngăn xếp chi tiết như minh hoạ dưới đây:

   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>
     

   Xin lưu ý rằng lỗi bắt tay là do:

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

   Điều này cho biết Lệnh bắt tay SSL không thành công vì Trình xử lý thông báo của Apigee Edge không xác thực được chứng chỉ của máy chủ phụ trợ.

Giai đoạn 1

Giai đoạn 1: Xác định chuỗi chứng chỉ của máy chủ phụ trợ

Sử dụng một trong các phương thức sau để xác định chuỗi chứng chỉ của máy chủ phụ trợ:

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

Giai đoạn 2

Giai đoạn 2: So sánh chứng chỉ của máy chủ phụ trợ và các chứng chỉ được lưu trữ trong truststore của Trình xử lý thông báo

1. Xác định chuỗi chứng chỉ của máy chủ phụ trợ.
2. Xác định chứng chỉ được lưu trữ trong truststore của Trình xử lý thông báo bằng cách làm theo các bước sau:

   1. Lấy tên tham chiếu truststore từ phần tử TrustStore trong phần SSLInfo trong TargetEndpoint.

      Hãy xem một phần SSLInfo mẫu trong cấu hình 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. Trong ví dụ trên, tên tham chiếu TrustStore là myCompanyTruststoreRef.

   3. Trong giao diện người dùng Edge, hãy chọn Environments > References (Môi trường > Tham chiếu). Lưu ý tên trong cột Tham chiếu cho thông tin tham chiếu cụ thể về kho lưu trữ đáng tin cậy. Đây sẽ là tên kho lưu trữ đáng tin cậy của bạn.

      ( xem hình ảnh lớn hơn)

      

   4. Trong ví dụ trên, tên truststore là:

      myCompanyTruststoreRef: myCompanyTruststore

3. Lấy các chứng chỉ được lưu trữ trong truststore (xác định ở bước trước) bằng các API sau:

   1. Nhận tất cả chứng chỉ cho một kho khoá hoặc kho tin cậy. API này liệt kê tất cả các chứng chỉ trong kho lưu trữ đáng tin cậy cụ thể.

      Người dùng Đám mây công khai:

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

      Người dùng Đám mây riêng:

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

      Địa điểm:

      • ORGANIZATION_NAME là tên của tổ chức
      • ENVIRONMENT_NAME là tên của môi trường
      • KEYSTORE_NAME là tên của kho khoá
      • $TOKEN được đặt thành mã truy cập OAuth 2.0 của bạn như mô tả trong phần Lấy mã truy cập OAuth 2.0
      • Các lựa chọn curl được dùng trong ví dụ này được mô tả trong phần Sử dụng lệnh curl

      Đầu ra mẫu:

      Các chứng chỉ trong kho lưu trữ đáng tin cậy mẫu myCompanyTruststore là:

      [
        "serverCert"
      ]

   2. Nhận thông tin chi tiết về chứng chỉ cho chứng chỉ cụ thể từ Keystore hoặc Truststore. API này trả về thông tin về một chứng chỉ cụ thể trong kho lưu trữ đáng tin cậy cụ thể.

      Người dùng Đám mây công khai:

      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"
      

      Người dùng Đám mây riêng tư

      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"
      

      Địa điểm:

      • ORGANIZATION_NAME là tên của tổ chức
      • ENVIRONMENT_NAME là tên của môi trường
      • KEYSTORE_NAME là tên của kho khoá
      • CERT_NAME là tên của chứng chỉ
      • $TOKEN được đặt thành mã truy cập OAuth 2.0 của bạn như mô tả trong phần Lấy mã truy cập OAuth 2.0
      • Các lựa chọn curl được dùng trong ví dụ này được mô tả trong phần Sử dụng lệnh curl

      Đầu ra mẫu

      Thông tin chi tiết về serverCert cho thấy chủ đề và tổ chức phát hành như sau:

      Chứng chỉ thực thể/Chứng chỉ gốc:

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

      Chứng chỉ trung gian:

      "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. Xác minh rằng chứng chỉ máy chủ thực tế thu được ở bước 1 và chứng chỉ được lưu trữ trong truststore thu được ở bước 3 khớp với nhau. Nếu chúng không khớp nhau, thì đó là nguyên nhân gây ra vấn đề.

   Trong ví dụ nêu trên, hãy xem xét từng chứng chỉ một:

   1. Chứng chỉ lá:

      Từ máy chủ phụ trợ:

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

      Từ truststore của Message Processor (máy khách):

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

      Chứng chỉ gốc được lưu trữ trong truststore khớp với chứng chỉ của máy chủ phụ trợ.

   2. Chứng chỉ trung gian:

      Từ máy chủ phụ trợ:

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

      Từ truststore của Message Processor (máy khách):

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

      Chứng chỉ trung gian được lưu trữ trong truststore khớp với chứng chỉ của máy chủ phụ trợ.

   3. Chứng chỉ gốc:

      Từ máy chủ phụ trợ:

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

      Chứng chỉ gốc hoàn toàn bị thiếu trong truststore của Message Processor.

   4. Vì chứng chỉ gốc bị thiếu trong truststore, nên Message Processor sẽ gửi ngoại lệ sau:

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

      và trả về 503 Service Unavailable kèm theo mã lỗi messaging.adaptors.http.flow.SslHandshakeFailed cho các ứng dụng khách.

FQDN chính xác

Cập nhật kho khoá của máy chủ phụ trợ bằng FQDN chính xác, chuỗi chứng chỉ hợp lệ và đầy đủ:

1. Nếu bạn không có chứng chỉ của máy chủ phụ trợ có FQDN chính xác, hãy mua chứng chỉ phù hợp từ một CA (Tổ chức phát hành chứng chỉ) thích hợp.

2. Xác thực rằng bạn có một chuỗi chứng chỉ hợp lệ và đầy đủ của máy chủ phụ trợ.

3. Sau khi bạn có chuỗi chứng chỉ hợp lệ và hoàn chỉnh với FQDN chính xác của máy chủ phụ trợ trong chứng chỉ thực thể hoặc chứng chỉ gốc giống với tên máy chủ được chỉ định trong điểm cuối đích, hãy cập nhật kho khoá của phụ trợ bằng chuỗi chứng chỉ hoàn chỉnh.

Máy chủ phụ trợ chính xác

Cập nhật điểm cuối mục tiêu bằng tên máy chủ chính xác của máy chủ phụ trợ:

1. Nếu tên máy chủ được chỉ định không chính xác trong điểm cuối đích, hãy cập nhật điểm cuối đích để có tên máy chủ chính xác khớp với FQDN trong chứng chỉ của máy chủ phụ trợ.

2. Lưu các thay đổi đối với proxy API.

   Trong ví dụ được thảo luận ở trên, nếu tên máy chủ lưu trữ phụ trợ được chỉ định không chính xác, thì bạn có thể khắc phục bằng cách sử dụng FQDN trong chứng chỉ của máy chủ phụ trợ, tức là backend.apigee.net như sau:

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