Lỗi giao tiếp TLS/SSL

Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến tài liệu về Apigee X. thông tin

Triệu chứng

Lỗi bắt tay TLS/SSL xảy ra khi ứng dụng và máy chủ không thể thiết lập hoạt động giao tiếp bằng giao thức TLS/SSL. Khi lỗi này xảy ra trong Apigee Edge, ứng dụng khách sẽ nhận được trạng thái HTTP 503 với thông báo Service Invalid (Dịch vụ không hoạt động). Bạn sẽ thấy lỗi này sau bất kỳ lệnh gọi API nào xảy ra lỗi bắt tay TLS/SSL.

Thông báo lỗi

HTTP/1.1 503 Service Unavailable

Bạn cũng có thể thấy thông báo lỗi này khi xảy ra lỗi bắt tay TLS/SSL:

Received fatal alert: handshake_failure

Các nguyên nhân có thể

TLS (Bảo mật tầng truyền tải có tiền thân là SSL) là công nghệ bảo mật tiêu chuẩn để thiết lập đường liên kết được mã hoá giữa máy chủ web và ứng dụng web, chẳng hạn như trình duyệt hoặc ứng dụng. Bắt tay là một quá trình cho phép máy khách và máy chủ TLS/SSL thiết lập một bộ khoá bí mật để giao tiếp. Trong quá trình này, ứng dụng và máy chủ:

  1. Đồng ý về phiên bản giao thức sẽ sử dụng.
  2. Chọn thuật toán mã hoá bạn muốn sử dụng.
  3. Xác thực lẫn nhau bằng cách trao đổi và xác thực chứng chỉ số.

Nếu quá trình bắt tay TLS/SSL thành công thì ứng dụng và máy chủ TLS/SSL sẽ chuyển dữ liệu cho nhau một cách an toàn. Ngược lại, nếu xảy ra lỗi bắt tay TLS/SSL, thì kết nối sẽ bị chấm dứt và ứng dụng sẽ gặp lỗi 503 Service Unavailable.

Các nguyên nhân có thể gây ra lỗi bắt tay TLS/SSL là:

Nguyên nhân Mô tả Người có thể thực hiện các bước khắc phục sự cố
Giao thức không khớp Giao thức mà ứng dụng sử dụng không được máy chủ hỗ trợ. Người dùng đám mây riêng tư và công khai
Bộ mật mã không khớp Bộ thuật toán mật mã mà ứng dụng sử dụng không được máy chủ hỗ trợ. Người dùng đám mây riêng tư và công khai
Chứng chỉ không chính xác Tên máy chủ trong URL mà ứng dụng sử dụng không khớp với tên trong chứng chỉ được lưu trữ ở phía máy chủ. Người dùng đám mây riêng tư và công khai
Chuỗi chứng chỉ không đầy đủ hoặc không hợp lệ được lưu trữ ở phía máy khách hoặc máy chủ. Người dùng đám mây riêng tư và công khai
Máy khách gửi một chứng chỉ không chính xác hoặc đã hết hạn đến máy chủ hoặc từ máy chủ đến ứng dụng. Người dùng đám mây riêng tư và công khai
Máy chủ hỗ trợ SNI Máy chủ phụ trợ đang bật Chỉ báo tên máy chủ (SNI); tuy nhiên, ứng dụng không thể giao tiếp với các máy chủ DEX. Chỉ người dùng Đám mây riêng tư

Giao thức không khớp

Lỗi bắt tay TLS/SSL sẽ xảy ra nếu giao thức mà ứng dụng sử dụng không được máy chủ hỗ trợ tại kết nối đến (hướng bắc) hoặc đi (hướng về). Hãy xem thêm bài viết Tìm hiểu về mối liên hệ giữa hướng bắc và nam.

Chẩn đoán

  1. Xác định xem lỗi xảy ra tại kết nối hướng bắc hay hướng về phía nam. Để biết thêm hướng dẫn về cách xác định điều này, hãy xem phần Xác định nguồn gốc vấn đề.
  2. Chạy tiện ích tcpdump để thu thập thêm thông tin:
    • Nếu là người dùng Đám mây riêng tư, bạn có thể thu thập dữ liệu tcpdump tại ứng dụng hoặc máy chủ liên quan. Ứng dụng có thể là ứng dụng khách (đối với kết nối đến hoặc kết nối hướng bắc) hoặc Bộ xử lý tin nhắn (đối với kết nối đi hoặc kết nối hướng nam). Máy chủ có thể là Bộ định tuyến cạnh (đối với kết nối đến hoặc hướng bắc) hoặc máy chủ phụ trợ (đối với kết nối đi hoặc kết nối hướng nam) dựa trên xác định của bạn trong Bước 1.
    • Nếu là người dùng Cloud công khai, thì bạn chỉ có thể thu thập dữ liệu tcpdump trên ứng dụng khách (đối với kết nối đến hoặc hướng bắc) hoặc máy chủ phụ trợ (đối với kết nối đi hoặc kết nối hướng nam) vì bạn không có quyền truy cập vào Bộ định tuyến Edge hoặc Bộ xử lý tin nhắn.
    tcpdump -i any -s 0 host IP address -w File name
    Xem dữ liệu tcpdump để biết thêm thông tin về cách sử dụng lệnh tcpdump.
  3. Phân tích dữ liệu tcpdump bằng công cụ Wireshark hoặc một công cụ tương tự.
  4. Dưới đây là bản phân tích mẫu về tcpdump bằng Wireshark:
    • Trong ví dụ này, lỗi bắt tay TLS/SSL đã xảy ra giữa Bộ xử lý thư và máy chủ phụ trợ (kết nối đi hoặc kết nối hướng nam).
    • Thông báo số 4 trong kết quả tcpdump dưới đây cho thấy Trình xử lý thông báo (Nguồn) đã gửi thông báo "Lời chào của ứng dụng khách" đến máy chủ phụ trợ (Đích).

    • Nếu bạn chọn thông báo Client Hello, thì thấy rằng Trình xử lý thông báo đang sử dụng giao thức TLS phiên bản 1.2, như minh hoạ dưới đây:

    • Thông báo số 5 cho biết máy chủ phụ trợ xác nhận thông báo "Lời chào của ứng dụng khách" từ Trình xử lý thông báo.
    • Máy chủ phụ trợ ngay lập tức gửi Fatal Alert : Close notifications (Cảnh báo nghiêm trọng: Đóng thông báo) cho Trình xử lý thông báo (thông báo số 6). Điều này có nghĩa là quá trình Giao tiếp qua TLS/SSL không thành công và kết nối sẽ bị đóng.

    • Xem xét kỹ hơn thông báo số 6 cho thấy nguyên nhân gây ra lỗi bắt tay TLS/SSL là do máy chủ phụ trợ chỉ hỗ trợ giao thức TLSv1.0 như sau:

    • Do không khớp giữa giao thức do Trình xử lý thông báo sử dụng và máy chủ phụ trợ, nên máy chủ phụ trợ đã gửi thông báo: Fatal Alert Message: Close (Thông báo đóng).

Độ phân giải

Bộ xử lý thư chạy trên Java 8 và sử dụng giao thức TLSv1.2 theo mặc định. Nếu máy chủ phụ trợ không hỗ trợ giao thức TLSv1.2, bạn có thể làm theo một trong các bước sau để giải quyết vấn đề này:

  1. Nâng cấp máy chủ phụ trợ của bạn để hỗ trợ giao thức TLSv1.2. Đây là một giải pháp được đề xuất vì giao thức TLS phiên bản 1.2 có tính bảo mật cao hơn.
  2. Nếu không thể nâng cấp máy chủ phụ trợ ngay lập tức vì lý do nào đó, bạn có thể buộc Bộ xử lý thông báo sử dụng giao thức TLSv1.0 để giao tiếp với máy chủ phụ trợ bằng cách làm theo các bước sau:
    1. Nếu bạn không chỉ định máy chủ mục tiêu trong định nghĩa TargetEndpoint của proxy, hãy đặt phần tử Protocol thành TLSv1.0 như minh hoạ bên dưới: 
      <TargetEndpoint name="default">
 …
 <HTTPTargetConnection>
   <SSLInfo>
       <Enabled>true</Enabled>
       <Protocols>
           <Protocol>TLSv1.0</Protocol>
       </Protocols>
   </SSLInfo>
   <URL>https://myservice.com</URL>
 </HTTPTargetConnection>
 …
</TargetEndpoint>
    2. Nếu bạn đã định cấu hình một máy chủ đích cho proxy của mình, hãy dùng API quản lý này để thiết lập giao thức thành TLSv1.0 trong cấu hình máy chủ mục tiêu cụ thể.

Mã mật mã không khớp

Bạn có thể thấy lỗi bắt tay TLS/SSL nếu thuật toán bộ mật mã mà ứng dụng sử dụng không được máy chủ hỗ trợ tại kết nối đến (hướng bắc) hoặc đi (hướng về) trong Apigee Edge. Hãy xem thêm bài viết Tìm hiểu về mối liên hệ giữa hướng bắc và nam.

Chẩn đoán

  1. Xác định xem lỗi xảy ra khi kết nối hướng bắc hay hướng nam. Để được hướng dẫn thêm về cách xác định này, hãy xem phần Xác định nguồn gốc vấn đề.
  2. Chạy tiện ích tcpdump để thu thập thêm thông tin:
    • Nếu là người dùng Đám mây riêng tư, bạn có thể thu thập dữ liệu tcpdump tại ứng dụng hoặc máy chủ liên quan. Ứng dụng có thể là ứng dụng khách (đối với kết nối đến hoặc kết nối hướng bắc) hoặc Bộ xử lý tin nhắn (đối với kết nối đi hoặc kết nối hướng nam). Máy chủ có thể là Bộ định tuyến cạnh (đối với kết nối đến hoặc hướng bắc) hoặc máy chủ phụ trợ (đối với kết nối đi hoặc kết nối hướng nam) dựa trên xác định của bạn trong Bước 1.
    • Nếu là người dùng Cloud công khai, thì bạn chỉ có thể thu thập dữ liệu tcpdump trên ứng dụng khách (đối với kết nối đến hoặc hướng bắc) hoặc máy chủ phụ trợ (đối với kết nối đi hoặc kết nối hướng nam) vì bạn không có quyền truy cập vào Bộ định tuyến Edge hoặc Bộ xử lý tin nhắn.
    tcpdump -i any -s 0 host IP address -w File name
    Xem dữ liệu tcpdump để biết thêm thông tin về cách sử dụng lệnh tcpdump.
  3. Phân tích dữ liệu tcpdump bằng công cụ Wireshark hoặc bất kỳ công cụ nào khác mà bạn quen thuộc.
  4. Dưới đây là bản phân tích mẫu về đầu ra tcpdump bằng Wireshark:
    • Trong ví dụ này, lỗi bắt tay TLS/SSL đã xảy ra giữa ứng dụng và bộ định tuyến Edge (kết nối hướng bắc). Đầu ra tcpdump được thu thập trên bộ định tuyến Edge.

    • Thông báo số 4 trong dữ liệu đầu ra tcpdump dưới đây cho thấy ứng dụng khách (nguồn) đã gửi thông báo "Client Hello" (Xin chào ứng dụng khách) đến Edge Bộ định tuyến (đích đến).

    • Khi chọn thông báo Client Hello, bạn sẽ thấy rằng ứng dụng đó đang sử dụng giao thức TLS phiên bản 1.2.

    • Thông báo số 5 cho biết Bộ định tuyến cạnh xác nhận thông báo "Client Hello" (Xin chào ứng dụng khách) từ ứng dụng.
    • Bộ định tuyến Edge ngay lập tức gửi một Cảnh báo nghiêm trọng : Lỗi bắt tay đến ứng dụng (thông báo số 6). Điều này có nghĩa là quá trình bắt tay TLS/SSL không thành công và kết nối sẽ bị đóng.
    • Sau khi xem xét kỹ hơn thông báo số 6, bạn sẽ thấy những thông tin sau:
      • Bộ định tuyến cạnh hỗ trợ giao thức TLSv1.2. Tức là giao thức này khớp với ứng dụng khách và Bộ định tuyến Edge.

      • Tuy nhiên, bộ định tuyến Edge vẫn gửi Cảnh báo nghiêm trọng: Lỗi bắt tay đến ứng dụng như trong ảnh chụp màn hình dưới đây:

    • Lỗi này có thể là do một trong những vấn đề sau:
      • Ứng dụng khách không sử dụng thuật toán bộ mật mã mà Bộ định tuyến Edge hỗ trợ.
      • Bộ định tuyến cạnh đã được bật DEX, nhưng ứng dụng khách không gửi tên máy chủ.
    • Thông báo số 4 trong kết quả tcpdump liệt kê các thuật toán bộ mật mã mà ứng dụng hỗ trợ, như minh hoạ dưới đây:

    • Danh sách các thuật toán bộ mật mã mà Bộ định tuyến Edge hỗ trợ được liệt kê trong tệp /opt/nginx/conf.d/0-default.conf. Trong ví dụ này, Bộ định tuyến Edge chỉ hỗ trợ các thuật toán của bộ mật mã Mã hoá cao.
    • Ứng dụng khách không sử dụng bất kỳ thuật toán nào của bộ mật mã Mã hoá cao. Lỗi không khớp này là nguyên nhân gây ra lỗi bắt tay TLS/SSL.
    • Vì Bộ định tuyến cạnh đã được kích hoạt bằng DEX, hãy cuộn xuống thông báo #4 trong đầu ra tcpdump và xác nhận rằng ứng dụng khách đang gửi đúng tên máy chủ, như minh hoạ trong hình dưới đây:


    • Nếu tên này hợp lệ, bạn có thể suy ra được rằng lỗi bắt tay TLS/SSL đã xảy ra vì các thuật toán của bộ mật mã mà ứng dụng dùng không được Bộ định tuyến Edge hỗ trợ.

Độ phân giải

Bạn phải đảm bảo rằng ứng dụng sử dụng những thuật toán bộ mật mã mà máy chủ hỗ trợ. Để giải quyết vấn đề được mô tả trong phần Chẩn đoán trước đó, hãy tải xuống và cài đặt gói Tiện ích mật mã học Java (JCE) và đưa gói này vào bản cài đặt Java để hỗ trợ các thuật toán của bộ mật mã Mã hoá cao.

Chứng chỉ không chính xác

Lỗi bắt tay TLS/SSL sẽ xảy ra nếu bạn có chứng chỉ không chính xác trong kho khoá/tin cậy, tại kết nối đến (hướng bắc) hoặc đi (hướng về) trong Apigee Edge. Hãy xem thêm bài viết Tìm hiểu về mối liên hệ giữa hướng bắc và nam.

Nếu vấn đề hướng về phía bắc, thì bạn có thể thấy các thông báo lỗi khác nhau tuỳ thuộc vào nguyên nhân cơ bản.

Các phần sau đây liệt kê các thông báo lỗi mẫu cũng như các bước chẩn đoán và giải quyết vấn đề này.

Thông báo lỗi

Bạn có thể thấy các thông báo lỗi khác nhau tuỳ thuộc vào nguyên nhân gây ra lỗi bắt tay TLS/SSL. Dưới đây là thông báo lỗi mẫu mà bạn có thể thấy khi gọi proxy 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

Các nguyên nhân có thể

Nguyên nhân điển hình dẫn đến vấn đề này là:

Nguyên nhân Mô tả Người có thể thực hiện các bước khắc phục sự cố
Tên máy chủ không khớp Tên máy chủ dùng trong URL và chứng chỉ trong kho khoá của bộ định tuyến không khớp. Ví dụ: lỗi không khớp sẽ xảy ra nếu tên máy chủ lưu trữ được dùng trong URL là myorg.domain.com trong khi chứng chỉ này có tên máy chủ trong CN là CN=something.domain.com.

 Người dùng Edge về dịch vụ đám mây riêng tư và công khai
Chuỗi chứng chỉ không đầy đủ hoặc không chính xác Chuỗi chứng chỉ không đầy đủ hoặc không chính xác. Chỉ dành cho người dùng Edge Private và Public Cloud
Chứng chỉ đã hết hạn hoặc không xác định do máy chủ hoặc ứng dụng gửi Máy chủ hoặc ứng dụng khách có một chứng chỉ đã hết hạn hoặc không xác định tại kết nối về hướng bắc hoặc hướng nam. Người dùng Edge Private Cloud và Edge Public Cloud

Tên máy chủ không khớp

Chẩn đoán

  1. Hãy lưu ý tên máy chủ dùng trong URL được lệnh gọi API quản lý Edge sau đây trả về: 
    curl -v https://myorg.domain.com/v1/getinfo
    Ví dụ: 
    curl -v https://api.enterprise.apigee.com/v1/getinfo
  2. Lấy CN dùng trong chứng chỉ được lưu trữ trong kho khoá cụ thể. Bạn có thể sử dụng các API Quản lý Edge sau đây để xem thông tin chi tiết về chứng chỉ:
    1. Lấy tên chứng chỉ trong kho khoá:

      Nếu bạn là người dùng Đám mây riêng tư, hãy sử dụng API Quản lý như sau:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      Nếu bạn là người dùng Cloud công khai, hãy sử dụng API Quản lý như sau:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
    2. Lấy thông tin chi tiết về chứng chỉ trong kho khoá bằng API Quản lý Edge.

      Nếu bạn là người dùng Đám mây riêng tư:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      Nếu bạn là người dùng Đám mây công cộng:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name

      Chứng chỉ mẫu::

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

      Tên chủ đề trong chứng chỉ chính có CN là something.domain.com.

      Do tên máy chủ được dùng trong URL yêu cầu API (tham khảo bước 1 ở trên) và tên chủ thể trong chứng chỉ không khớp nhau, nên bạn sẽ gặp lỗi bắt tay TLS/SSL.

Độ phân giải

Bạn có thể giải quyết vấn đề này theo một trong hai cách sau:

  • Lấy chứng chỉ (nếu bạn chưa có) trong đó CN đối tượng có chứng chỉ ký tự đại diện, sau đó tải chuỗi chứng chỉ hoàn chỉnh mới lên kho khoá. Ví dụ: 
    "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",
  • Lấy chứng chỉ (nếu bạn chưa có) với một môn học hiện có CN, nhưng sử dụng your-org.your-domain làm tên thay thế của chủ đề, sau đó tải chuỗi chứng chỉ hoàn chỉnh lên kho khoá.

Tài liệu tham khảo

Kho khoá và Kho lưu trữ tin cậy

Chuỗi chứng chỉ không hoàn chỉnh hoặc không chính xác

Chẩn đoán

  1. Lấy CN dùng trong chứng chỉ được lưu trữ trong kho khoá cụ thể. Bạn có thể sử dụng các API Quản lý Edge sau đây để xem thông tin chi tiết về chứng chỉ:
    1. Lấy tên chứng chỉ trong kho khoá:

      Nếu bạn là người dùng Đám mây riêng tư:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      Nếu bạn là người dùng Đám mây công cộng:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
    2. Xem thông tin chi tiết về chứng chỉ trong kho khoá:

      Nếu bạn là người dùng Đám mây riêng tư:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      Nếu bạn là người dùng Đám mây công cộng:
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
    3. Xác thực chứng chỉ và chuỗi chứng chỉ, đồng thời xác minh rằng chứng chỉ tuân thủ các nguyên tắc được cung cấp trong bài viết Cách hoạt động của chuỗi chứng chỉ nhằm đảm bảo chứng chỉ đó là một chuỗi chứng chỉ hợp lệ và hoàn chỉnh. Nếu chuỗi chứng chỉ được lưu trữ trong kho khoá chưa hoàn chỉnh hoặc không hợp lệ, thì bạn sẽ thấy lỗi bắt tay TLS/SSL.
    4. Hình ảnh sau đây cho thấy một chứng chỉ mẫu có chuỗi chứng chỉ không hợp lệ, trong đó chứng chỉ trung gian và gốc không khớp:

      5. Mẫu chứng chỉ trung gian và chứng chỉ gốc mà trong đó tổ chức phát hành và chủ thể không khớp


Độ phân giải

  1. Lấy một chứng chỉ (nếu bạn chưa có) có chuỗi chứng chỉ hoàn chỉnh và hợp lệ.
  2. Chạy lệnh openSSL sau đây để xác minh rằng chuỗi chứng chỉ là chính xác và hoàn chỉnh: 
    openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert
  3. Tải chuỗi chứng chỉ đã xác thực lên kho khoá.

Chứng chỉ đã hết hạn hoặc không xác định do máy chủ hoặc ứng dụng gửi

Nếu máy chủ/ứng dụng gửi một chứng chỉ không chính xác/đã hết hạn tại kết nối hướng bắc hoặc hướng nam, thì đầu bên kia (máy chủ/ứng dụng) sẽ từ chối chứng chỉ dẫn đến lỗi bắt tay TLS/SSL.

Chẩn đoán

  1. Xác định xem lỗi xảy ra tại kết nối hướng bắc hay hướng về phía nam. Để biết thêm hướng dẫn về cách xác định điều này, hãy xem phần Xác định nguồn gốc vấn đề.
  2. Chạy tiện ích tcpdump để thu thập thêm thông tin:
    • Nếu là người dùng Đám mây riêng tư, bạn có thể thu thập dữ liệu tcpdump tại ứng dụng hoặc máy chủ liên quan. Ứng dụng có thể là ứng dụng khách (đối với kết nối đến hoặc kết nối hướng bắc) hoặc Bộ xử lý tin nhắn (đối với kết nối đi hoặc kết nối hướng nam). Máy chủ có thể là Bộ định tuyến cạnh (đối với kết nối đến hoặc hướng bắc) hoặc máy chủ phụ trợ (đối với kết nối đi hoặc kết nối hướng nam) dựa trên xác định của bạn trong Bước 1.
    • Nếu là người dùng Cloud công khai, thì bạn chỉ có thể thu thập dữ liệu tcpdump trên ứng dụng khách (đối với kết nối đến hoặc hướng bắc) hoặc máy chủ phụ trợ (đối với kết nối đi hoặc kết nối hướng nam) vì bạn không có quyền truy cập vào Bộ định tuyến Edge hoặc Bộ xử lý tin nhắn.
    tcpdump -i any -s 0 host IP address -w File name
    Xem dữ liệu tcpdump để biết thêm thông tin về cách sử dụng lệnh tcpdump.
  3. Phân tích dữ liệu tcpdump bằng Wireshark hoặc một công cụ tương tự.
  4. Từ đầu ra tcpdump, hãy xác định máy chủ lưu trữ (ứng dụng hoặc máy chủ) đang từ chối chứng chỉ trong bước xác minh.
  5. Bạn có thể truy xuất chứng chỉ được gửi từ đầu bên kia từ đầu ra tcpdump, miễn là dữ liệu chưa được mã hoá. Bạn sẽ thấy một số thông tin hữu ích khi so sánh xem chứng chỉ này có khớp với chứng chỉ có trong Truststore hay không.
  6. Xem xét tcpdump mẫu để biết hoạt động giao tiếp SSL giữa Bộ xử lý thông báo và máy chủ phụ trợ.

    Mẫu tcpdump cho thấy lỗi không xác định của chứng chỉ


    1. Bộ xử lý thông báo (máy khách) gửi "Xin chào ứng dụng khách" đến máy chủ phụ trợ (máy chủ) trong thông báo #59.
    2. Máy chủ phụ trợ gửi "Server Hello" (Xin chào máy chủ) đến Bộ xử lý thông báo trong thông báo #61.
    3. Chúng xác thực cùng nhau giao thức và thuật toán bộ mật mã được sử dụng.
    4. Máy chủ phụ trợ gửi thông báo Chứng chỉ và Xin chào máy chủ đã hoàn tất cho Bộ xử lý thông báo trong thông báo #68.
    5. Bộ xử lý thông báo sẽ gửi Cảnh báo nghiêm trọng "Description: Certificate Unknown" (Thông báo số 70).
    6. Sau khi xem xét thông báo số 70, không có thông tin chi tiết bổ sung nào khác ngoài thông báo như dưới đây:


    7. Xem lại thông báo số 68 để biết thông tin chi tiết về chứng chỉ do máy chủ phụ trợ gửi, như trong hình sau:

    8. Chứng chỉ của máy chủ phụ trợ và chuỗi hoàn chỉnh của chứng chỉ đều có trong phần "Chứng chỉ" như minh hoạ trong hình trên.
  7. Nếu Bộ định tuyến (hướng bắc) hoặc Bộ xử lý thông báo (hướng nam) như trong ví dụ minh hoạ ở trên mà phát hiện chứng chỉ là không xác định:
    1. Lấy chứng chỉ và chuỗi chứng chỉ được lưu trữ trong kho tin cậy cụ thể. (Hãy tham khảo cấu hình máy chủ ảo cho Bộ định tuyến và cấu hình điểm cuối đích của Bộ xử lý thông báo). Bạn có thể sử dụng các API sau đây để xem thông tin chi tiết về chứng chỉ:
      1. Lấy tên chứng chỉ trong Truststore: 
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs
      2. Lấy thông tin chi tiết về chứng chỉ trong Truststore: 
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name
    2. Kiểm tra xem chứng chỉ được lưu trữ trong kho tin cậy của Bộ định tuyến (hướng bắc) hoặc Trình xử lý thông báo (hướng nam) có khớp với chứng chỉ được lưu trữ trong kho khoá của ứng dụng khách (hướng bắc) hoặc máy chủ mục tiêu (hướng nam) hay chứng chỉ được lấy từ đầu ra của tcpdump. Nếu kết quả không khớp, thì đó là nguyên nhân gây ra lỗi bắt tay TLS/SSL.
  8. Nếu ứng dụng khách (hướng bắc) hoặc máy chủ mục tiêu (hướng nam) phát hiện chứng chỉ là không xác định, hãy làm theo các bước sau:
    1. Lấy chuỗi chứng chỉ hoàn chỉnh dùng trong chứng chỉ được lưu trữ trong kho khoá cụ thể. (Hãy tham khảo cấu hình máy chủ ảo cho Bộ định tuyến và cấu hình điểm cuối đích của Bộ xử lý thông báo.) Bạn có thể dùng các API sau đây để lấy thông tin chi tiết về chứng chỉ:
      1. Lấy tên chứng chỉ trong kho khoá: 
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      2. Xem thông tin chi tiết về chứng chỉ trong kho khoá:
        curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
    2. Kiểm tra xem chứng chỉ được lưu trữ trong kho khoá của Bộ định tuyến (hướng bắc) hoặc Trình xử lý thông báo (hướng nam) có khớp với chứng chỉ được lưu trữ trong kho tin cậy của ứng dụng khách (hướng bắc) hoặc máy chủ mục tiêu (hướng nam) hay không, hoặc chứng chỉ được lấy từ đầu ra của tcpdump. Nếu kết quả không khớp, thì đó là nguyên nhân gây ra lỗi bắt tay SSL.
  9. Nếu chứng chỉ do máy chủ/ứng dụng gửi bị phát hiện đã hết hạn, thì ứng dụng/máy chủ nhận sẽ từ chối chứng chỉ và bạn sẽ thấy thông báo cảnh báo sau trong tcpdump:

    Cảnh báo (Cấp độ: Nghiêm trọng, Mô tả: Chứng chỉ đã hết hạn)

  10. Xác minh rằng chứng chỉ trong kho khoá của máy chủ lưu trữ thích hợp đã hết hạn.

Độ phân giải

Để giải quyết vấn đề xác định trong ví dụ trên, hãy tải chứng chỉ của máy chủ phụ trợ hợp lệ lên trustore trên Bộ xử lý thông báo.

Bảng sau đây tóm tắt các bước để giải quyết vấn đề tuỳ thuộc vào nguyên nhân của vấn đề.

Nguyên nhân Mô tả Độ phân giải
Chứng chỉ đã hết hạn NorthBound
  • Chứng chỉ được lưu trữ trên kho khoá của bộ định tuyến đã hết hạn.
  • Chứng chỉ được lưu trữ trên kho khoá của ứng dụng đã hết hạn (SSL 2 chiều).
 Tải chứng chỉ mới và chuỗi hoàn chỉnh của chứng chỉ lên kho khoá trên máy chủ lưu trữ thích hợp.
SouthBound
  • Chứng chỉ được lưu trữ trên kho khoá của Máy chủ mục tiêu đã hết hạn.
  • Chứng chỉ được lưu trữ trên kho khoá của Bộ xử lý thông báo đã hết hạn (SSL 2 chiều).
 Tải chứng chỉ mới và chuỗi hoàn chỉnh của chứng chỉ lên kho khoá trên máy chủ lưu trữ thích hợp.
Chứng chỉ không xác định NorthBound
  • Chứng chỉ được lưu trữ trên Truststore của ứng dụng khách không khớp với chứng chỉ của Bộ định tuyến.
  • Chứng chỉ được lưu trữ trên Truststore của bộ định tuyến không khớp với chứng chỉ của ứng dụng (SSL 2 chiều).
 Tải chứng chỉ hợp lệ lên Truststore trên máy chủ lưu trữ phù hợp.
SouthBound
  • Chứng chỉ được lưu trữ trên kho lưu trữ tin cậy của máy chủ đích không khớp với chứng chỉ của Trình xử lý thông báo.
  • Chứng chỉ được lưu trữ trên Truststore của Bộ xử lý thông báo không khớp với chứng chỉ của máy chủ đích (SSL 2 chiều).
 Tải chứng chỉ hợp lệ lên Truststore trên máy chủ lưu trữ phù hợp.

Máy chủ được bật SNI

Lỗi bắt tay TLS/SSL có thể xảy ra khi ứng dụng đang giao tiếp với Máy chủ Đã bật chỉ báo tên máy chủ (SNI), nhưng ứng dụng khách chưa được bật DEX. Điều này có thể xảy ra khi kết nối theo hướng bắc hoặc hướng nam trong Edge.

Trước tiên, bạn cần xác định tên máy chủ và số cổng của máy chủ đang được sử dụng, đồng thời kiểm tra xem máy chủ đó có được bật DEX hay không.

Nhận dạng máy chủ đã bật DDEX

  1. Thực thi lệnh openssl và cố gắng kết nối với tên máy chủ có liên quan (Edge Bộ định tuyến hoặc máy chủ phụ trợ) mà không chuyển tên máy chủ, như minh hoạ dưới đây: 
    openssl s_client -connect hostname:port
    Bạn có thể nhận được các chứng chỉ và đôi khi bạn có thể thấy lỗi bắt tay trong lệnh openSSL, như minh hoạ dưới đây:
    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. Thực thi lệnh openssl và cố gắng kết nối với tên máy chủ liên quan (bộ định tuyến cạnh hoặc máy chủ phụ trợ) bằng cách truyền tên máy chủ như đoạn mã bên dưới: 
    openssl s_client -connect hostname:port -servername hostname
  3. Nếu bạn gặp lỗi bắt tay ở bước 1 hoặc nhận được các chứng chỉ khác ở bước 1 và bước 2, thì tức là Máy chủ được chỉ định đang bật DEX.

Sau khi xác định rằng máy chủ đã bật DEX, bạn có thể làm theo các bước dưới đây để kiểm tra xem lỗi bắt tay TLS/SSL có phải là do ứng dụng không giao tiếp với máy chủ NNAPI hay không.

Chẩn đoán

  1. Xác định xem lỗi xảy ra tại kết nối hướng bắc hay hướng về phía nam. Để biết thêm hướng dẫn về cách xác định điều này, hãy xem phần Xác định nguồn gốc vấn đề.
  2. Chạy tiện ích tcpdump để thu thập thêm thông tin:
    • Nếu là người dùng Đám mây riêng tư, bạn có thể thu thập dữ liệu tcpdump tại ứng dụng hoặc máy chủ liên quan. Ứng dụng có thể là ứng dụng khách (đối với kết nối đến hoặc kết nối hướng bắc) hoặc Bộ xử lý tin nhắn (đối với kết nối đi hoặc kết nối hướng nam). Máy chủ có thể là Bộ định tuyến cạnh (đối với kết nối đến hoặc hướng bắc) hoặc máy chủ phụ trợ (đối với kết nối đi hoặc kết nối hướng nam) dựa trên xác định của bạn trong Bước 1.
    • Nếu là người dùng Cloud công khai, thì bạn chỉ có thể thu thập dữ liệu tcpdump trên ứng dụng khách (đối với kết nối đến hoặc hướng bắc) hoặc máy chủ phụ trợ (đối với kết nối đi hoặc kết nối hướng nam) vì bạn không có quyền truy cập vào Bộ định tuyến Edge hoặc Bộ xử lý tin nhắn.
    tcpdump -i any -s 0 host IP address -w File name
    Xem dữ liệu tcpdump để biết thêm thông tin về cách sử dụng lệnh tcpdump.
  3. Phân tích đầu ra tcpdump bằng Wireshark hoặc một công cụ tương tự.
  4. Dưới đây là phân tích mẫu về tcpdump bằng Wireshark:
    1. Trong ví dụ này, lỗi bắt tay TLS/SSL đã xảy ra giữa Bộ xử lý thông báo cạnh và máy chủ phụ trợ (kết nối hướng nam).
    2. Thông báo số 4 trong dữ liệu đầu ra tcpdump dưới đây cho thấy Trình xử lý thông báo (nguồn) đã gửi thông báo "Xin chào ứng dụng khách" đến máy chủ phụ trợ (đích).

    3. Khi chọn thông báo "Client Hello" (Xin chào ứng dụng khách), bạn sẽ biết rằng Trình xử lý thông báo đang sử dụng giao thức TLSv1.2.

    4. Thông báo số 4 cho biết máy chủ phụ trợ xác nhận thông báo "Lời chào của ứng dụng khách" từ Bộ xử lý thông báo.
    5. Máy chủ phụ trợ sẽ ngay lập tức gửi một Cảnh báo nghiêm trọng : Lỗi bắt tay đến Bộ xử lý thông báo (thông báo số 5). Điều này có nghĩa là giao thức bắt tay TLS/SSL không thành công và kết nối sẽ bị đóng.
    6. Xem lại thông báo số 6 để biết thông tin sau
      • Máy chủ phụ trợ không hỗ trợ giao thức TLSv1.2. Tức là giao thức khớp giữa Trình xử lý thông báo và máy chủ phụ trợ.
      • Tuy nhiên, máy chủ phụ trợ vẫn gửi Cảnh báo nghiêm trọng: Lỗi bắt tay đến Trình xử lý thông báo như minh hoạ trong hình dưới đây:

    7. Lỗi này có thể xảy ra vì một trong những lý do sau:
      • Trình xử lý thông báo không sử dụng các thuật toán bộ mật mã mà máy chủ phụ trợ hỗ trợ.
      • Máy chủ phụ trợ đang bật SafeFrame, nhưng ứng dụng khách không gửi tên máy chủ.
    8. Xem xét thông báo #3 (Xin chào ứng dụng khách) trong kết quả tcpdump để biết thêm chi tiết. Xin lưu ý rằng Extension: server_name bị thiếu, như minh hoạ dưới đây:

    9. Điều này xác nhận rằng Trình xử lý thông báo không gửi server_name tới máy chủ phụ trợ đã bật DEX.
    10. Đây là nguyên nhân gây ra lỗi bắt tay TLS/SSL và lý do khiến máy chủ phụ trợ gửi Cảnh báo nghiêm trọng: Lỗi bắt tay cho Trình xử lý thông báo.
  5. Xác minh rằng jsse.enableSNIExtension property trong system.properties được đặt thành false trên Bộ xử lý thông báo để xác nhận rằng Trình xử lý thông báo chưa được bật để giao tiếp với máy chủ đã bật DDEX.

Độ phân giải

Cho phép(các) Bộ xử lý thông báo giao tiếp với các máy chủ hỗ trợ KDDI bằng cách thực hiện các bước sau:

  1. Tạo tệp/opt/apigee/customer/application/message-processor.properties (nếu chưa có).
  2. Thêm dòng sau vào tệp này: conf_system_jsse.enableSNIExtension=true
  3. Chọn chủ sở hữu của tệp này cho apigee:apigee: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. Khởi động lại Bộ xử lý thư. 
    /opt/apigee/apigee-service/bin/apigee-service message-processor restart
  5. Nếu bạn có nhiều Bộ xử lý thông báo, hãy lặp lại các bước từ 1 đến 4 trên tất cả các Bộ xử lý thông báo.

Nếu bạn không thể xác định nguyên nhân gây ra lỗi giao tiếp TLS/SSL và khắc phục vấn đề, hoặc nếu bạn cần được hỗ trợ thêm, hãy liên hệ với Nhóm hỗ trợ API Apigee. Chia sẻ toàn bộ thông tin chi tiết về vấn đề đó cùng với kết quả tcpdump.