Lỗi giao tiếp TLS/SSL

Bạn đang xem tài liệu về Apigee Edge.
Truy cập vào tài liệu Apigee X. thông tin

Dấu hiệu

Lỗi bắt tay TLS/SSL xảy ra khi máy khách và máy chủ không thể thiết lập 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 kèm theo thông báo Dịch vụ không có sẵn. 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, tiền thân là SSL) là công nghệ bảo mật tiêu chuẩn để thiết lập một đường liên kết được mã hoá giữa máy chủ web và máy khách web, chẳng hạn như trình duyệt hoặc ứng dụng. Bắt tay là một quy 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 mà chúng có thể giao tiếp. Trong quá trình này, máy khách và máy chủ sẽ:

1. Thống nhất về phiên bản giao thức sẽ sử dụng.
2. Chọn thuật toán mã hoá sẽ được 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 cơ chế bắt tay TLS/SSL thành công, thì máy khách và máy chủ TLS/SSL sẽ truyền dữ liệu cho nhau một cách an toàn. Nếu không, nếu xảy ra lỗi bắt tay TLS/SSL, kết nối sẽ bị chấm dứt và máy khách sẽ nhận được lỗi 503 Service Unavailable.

Các nguyên nhân có thể dẫn đến lỗi bắt tay TLS/SSL là:

Giao thức không khớp

Lỗi bắt tay TLS/SSL xảy ra nếu giao thức mà máy khách sử dụng không được máy chủ hỗ trợ ở kết nối đến (hướng bắc) hoặc đi (hướng nam). Xem thêm phần Tìm hiểu về các kết nối hướng bắc và hướng nam.

Chẩn đoán

1. Xác định xem lỗi xảy ra ở kết nối theo hướng bắc hay theo hướng nam. Để biết thêm hướng dẫn về cách xác định vấn đề này, hãy xem phần Xác định nguồn gốc của 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, bạn có thể thu thập dữ liệu tcpdump tại máy khách hoặc máy chủ có liên quan. Ứng dụng khách có thể là ứng dụng khách (đối với các kết nối đến hoặc kết nối hướng bắc) hoặc Trình xử lý thông báo (đối với các kết nối đi hoặc kết nối hướng nam). Máy chủ có thể là Bộ định tuyến biên (đối với các kết nối đến hoặc kết nối hướng bắc) hoặc máy chủ phụ trợ (đối với các kết nối đi hoặc kết nối hướng nam) dựa trên quyết định của bạn ở Bước 1.
   • Nếu là người dùng Đám mây công cộng, bạn chỉ có thể thu thập dữ liệu tcpdump trên ứng dụng khách (đối với các kết nối đến hoặc kết nối hướng bắc) hoặc máy chủ phụ trợ (đối với các 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 biên hoặc Trình xử lý thông báo.

   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. Sau đây là một ví dụ về phân tích tcpdump bằng Wireshark:
   • Trong ví dụ này, lỗi bắt tay TLS/SSL xảy ra giữa Trình xử lý thông báo và máy chủ phụ trợ (kết nối đi hoặc kết nối phía nam).
   • Thông báo số 4 trong đầu ra tcpdump bên dưới cho thấy Trình xử lý thông báo (Nguồn) đã gửi thông báo "Xin chào khách hàng" đến máy chủ phụ trợ (Đích đến).
     

     

   • Nếu bạn chọn thông báo Client Hello, thông báo này cho biết Trình xử lý thông báo đang sử dụng giao thức TLSv1.2, như minh hoạ bên dưới:

     

   • Thông báo số 5 cho biết máy chủ phụ trợ xác nhận thông báo "Client Hello" từ Trình xử lý thông báo.
   • Máy chủ phụ trợ sẽ ngay lập tức gửi Fatal Alert : Close Notify đến Message Processor (thông báo số 6). Điều này có nghĩa là TLS/SSL Handshake 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ư minh hoạ dưới đây:

     

   • Vì có sự không khớp giữa giao thức mà 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 Notify (Thông báo cảnh báo nghiêm trọng: Đóng thông báo).

Độ phân giải

Trình xử lý thông báo 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, thì bạn có thể thực hiện 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ợ để hỗ trợ giao thức TLSv1.2. Đây là giải pháp nên dùng vì giao thức TLSv1.2 an toàn hơn.
2. Nếu không thể nâng cấp máy chủ phụ trợ ngay lập tức vì một lý do nào đó, thì bạn có thể buộc Trình 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ột máy chủ đích 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, hãy dùng API quản lý này để đặt giao thức thành TLSv1.0 trong cấu hình máy chủ đích cụ thể.

Thuật toán mật mã không khớp

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

Chẩn đoán

1. Xác định xem lỗi xảy ra ở kết nối theo hướng bắc hay theo hướng nam. Để biết thêm hướng dẫn về cách xác định, hãy xem phần Xác định nguồn gốc của 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, bạn có thể thu thập dữ liệu tcpdump tại máy khách hoặc máy chủ có liên quan. Ứng dụng khách có thể là ứng dụng khách (đối với các kết nối đến hoặc kết nối hướng bắc) hoặc Trình xử lý thông báo (đối với các kết nối đi hoặc kết nối hướng nam). Máy chủ có thể là Bộ định tuyến biên (đối với các kết nối đến hoặc kết nối hướng bắc) hoặc máy chủ phụ trợ (đối với các kết nối đi hoặc kết nối hướng nam) dựa trên quyết định của bạn ở Bước 1.
   • Nếu là người dùng Đám mây công cộng, bạn chỉ có thể thu thập dữ liệu tcpdump trên ứng dụng khách (đối với các kết nối đến hoặc kết nối hướng bắc) hoặc máy chủ phụ trợ (đối với các 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 biên hoặc Trình xử lý thông báo.

   tcpdump -i any -s 0 host IP address -w File name
   

   Hãy 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 dùng.
4. Sau đây là mẫu phân tích đầ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 Client và bộ định tuyến Edge (kết nối theo chiều bắc). Đầu ra tcpdump được thu thập trên bộ định tuyến Edge.

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

     

   • Việc chọn thông báo Client Hello cho thấy ứng dụng khách đang sử dụng giao thức TLSv1.2.

     

   • Thông báo số 5 cho thấy Bộ định tuyến biên thừa nhận thông báo "Client Hello" từ ứng dụng khách.
   • Bộ định tuyến Edge sẽ gửi ngay Cảnh báo nghiêm trọng : Lỗi bắt tay đến ứng dụng khách (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.
   • 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 biên hỗ trợ giao thức TLSv1.2. Điều này có nghĩa là giao thức khớp giữa ứng dụng và Bộ định tuyến biên.

     • 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 khách như minh hoạ trong ảnh chụp màn hình bên dưới:

       

   • 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 các bộ thuật toán mật mã được Edge Router hỗ trợ.
     • Bộ định tuyến biên có hỗ trợ SNI, nhưng ứng dụng khách không gửi tên máy chủ.
   • Thông báo số 4 trong đầu ra tcpdump liệt kê các bộ thuật toán mật mã mà ứng dụng khách hỗ trợ, như minh hoạ dưới đây:

     

   • Danh sách các bộ thuật toán mật mã mà Bộ định tuyến biên hỗ trợ được liệt kê trong tệp /opt/nginx/conf.d/0-default.conf. Trong ví dụ này, Edge Router chỉ hỗ trợ các thuật toán bộ thuật toán 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 trong bộ thuật toán mật mã Mã hoá cấp cao. Sự không khớp này là nguyên nhân gây ra lỗi bắt tay TLS/SSL.
   • Vì Edge Router có hỗ trợ SNI, hãy di chuyển xuống thông báo số 4 trong đầu ra tcpdump và xác nhận rằng ứng dụng khách đang gửi tên máy chủ một cách chính xác, như minh hoạ trong hình bên dưới:
     
     
     
   • Nếu tên này hợp lệ, bạn có thể suy luận rằng lỗi bắt tay TLS/SSL đã xảy ra vì các thuật toán bộ mật mã mà ứng dụng khách sử dụng không được Edge Router hỗ trợ.

Độ phân giải

Bạn phải đảm bảo rằng ứng dụng sử dụng các bộ thuật toán mật mã do 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 Java Cryptography Extension (JCE) rồi đưa gói này vào quá trình cài đặt Java để hỗ trợ các bộ thuật toán mật mã Mã hoá cấp cao.

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

Lỗi bắt tay TLS/SSL xảy ra nếu bạn có chứng chỉ không chính xác trong kho khoá/kho tin cậy, ở kết nối đến (hướng bắc) hoặc đi (hướng nam) trong Apigee Edge. Xem thêm phần Tìm hiểu về các kết nối hướng bắc và hướng nam.

Nếu vấn đề là theo hướng bắc, thì bạn có thể thấy nhiều 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ê ví dụ về thông báo lỗi và các bước để chẩn đoán cũng như giải quyết vấn đề này.

Thông báo lỗi

Bạn có thể thấy nhiều 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à một thông báo lỗi mẫu mà bạn có thể thấy khi gọi một 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ể

Các nguyên nhân thường gặp dẫn đến vấn đề này là:

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

Chẩn đoán

1. Lưu ý tên máy chủ lưu trữ được dùng trong URL do lệnh gọi Edge Management API 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 được 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, 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 Đám mây 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 Edge Management API.
      
      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.

      Vì 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, 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 bằng một trong hai cách sau:

• Lấy một chứng chỉ (nếu bạn chưa có) trong đó CN của chủ đề 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 một chứng chỉ (nếu bạn chưa có) có CN chủ đề hiện tại, nhưng hãy 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ữ đáng tin cậy

Chuỗi chứng chỉ không đầy đủ hoặc không chính xác

Chẩn đoán

1. Lấy CN được 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:
      

      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. Lấy 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ỉ để đảm bảo đó 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á không đầy đủ 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à chứng chỉ gốc không khớp:

   Chứng chỉ gốc và chứng chỉ trung gian mẫu trong đó nhà phát hành và chủ đề không khớp

   
   

Độ phân giải

1. Lấy một chứng chỉ (nếu bạn chưa có) bao gồm một chuỗi chứng chỉ hoàn chỉnh và hợp lệ.
2. Chạy lệnh openssl sau để 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 máy khách gửi

Nếu máy chủ/máy khách 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 kia (máy chủ/máy khách) 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 ở kết nối theo hướng bắc hay theo hướng nam. Để biết thêm hướng dẫn về cách xác định vấn đề này, hãy xem phần Xác định nguồn gốc của 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, bạn có thể thu thập dữ liệu tcpdump tại máy khách hoặc máy chủ có liên quan. Ứng dụng khách có thể là ứng dụng khách (đối với các kết nối đến hoặc kết nối hướng bắc) hoặc Trình xử lý thông báo (đối với các kết nối đi hoặc kết nối hướng nam). Máy chủ có thể là Bộ định tuyến biên (đối với các kết nối đến hoặc kết nối hướng bắc) hoặc máy chủ phụ trợ (đối với các kết nối đi hoặc kết nối hướng nam) dựa trên quyết định của bạn ở Bước 1.
   • Nếu là người dùng Đám mây công cộng, bạn chỉ có thể thu thập dữ liệu tcpdump trên ứng dụng khách (đối với các kết nối đến hoặc kết nối hướng bắc) hoặc máy chủ phụ trợ (đối với các 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 biên hoặc Trình xử lý thông báo.

   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ủ (máy khách 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 kia từ đầu ra tcpdump, miễn là dữ liệu không được mã hoá. Điều này sẽ 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 thông tin liên lạc SSL giữa Trình xử lý tin nhắn và máy chủ phụ trợ.

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

   
   

   1. Trình xử lý thông báo (máy khách) sẽ gửi "Client Hello" đến máy chủ phụ trợ (máy chủ) trong thông báo số 59.
   2. Máy chủ phụ trợ gửi "Server Hello" đến Trình xử lý thông báo trong thông báo #61.
   3. Chúng cùng xác thực giao thức và các thuật toán bộ thuật toán mật mã được dùng.
   4. Máy chủ phụ trợ sẽ gửi thông báo Chứng chỉ và Server Hello Done đến Trình xử lý thông báo trong thông báo số 68.
   5. Message Processor gửi Cảnh báo nghiêm trọng "Description: Certificate Unknown" trong thông báo số 70.
   6. Xem xét kỹ hơn thông báo số 70, không có thông tin chi tiết nào khác ngoài thông báo cảnh báo như minh hoạ bên dưới:

      
      

   7. Xem 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ư minh hoạ trong hình sau:

      

   8. Chứng chỉ của máy chủ phụ trợ và toàn bộ chuỗi của chứng chỉ đó đều có trong phần "Certificates" (Chứng chỉ), như minh hoạ trong hình trên.
7. Nếu Bộ định tuyến (hướng bắc) hoặc Trình xử lý thông báo (hướng nam) phát hiện thấy chứng chỉ không xác định như trong ví dụ minh hoạ ở trên, hãy làm theo các bước sau:
   1. Lấy chứng chỉ và chuỗi của chứng chỉ đó được lưu trữ trong truststore cụ thể. (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 mục tiêu cho Trình xử lý thông báo). Bạn có thể dùng các API sau để 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 truststore 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ủ đích (hướng nam) hay không, hoặc chứng chỉ thu được từ đầu ra tcpdump. Nếu có sự 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ủ đích (hướng nam) không nhận dạng được chứng chỉ, hãy làm theo các bước sau:
   1. Lấy chuỗi chứng chỉ hoàn chỉnh được dùng trong chứng chỉ được lưu trữ trong kho khoá cụ thể. (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 mục tiêu cho Trình xử lý thông báo.) Bạn có thể dùng các API sau để xem 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. Lấy 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 lưu trữ đáng tin cậy của ứng dụng khách (hướng bắc) hoặc máy chủ đích (hướng nam) hay không, hoặc chứng chỉ thu được từ đầu ra tcpdump. Nếu có sự 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ủ/máy khách gửi được phát hiện là đã hết hạn, thì máy khách/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 (Mức độ: Nghiêm trọng, Nội dung 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 đề được xác định trong ví dụ trên, hãy tải chứng chỉ hợp lệ của máy chủ phụ trợ lên trustore trên Trình 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 gây ra vấn đề.

Máy chủ đã bật SNI

Lỗi bắt tay TLS/SSL có thể xảy ra khi máy khách đang giao tiếp với một Máy chủ đã bật Chỉ báo tên máy chủ (SNI), nhưng máy khách chưa bật SNI. Điều này có thể xảy ra ở kết nối 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ó bật SNI hay không.

Xác định máy chủ đã bật SNI

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 (Bộ định tuyến Edge hoặc máy chủ phụ trợ) mà không truyề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 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à thử kết nối với tên máy chủ có liên quan (Bộ định tuyến biên hoặc máy chủ phụ trợ) bằng cách truyền tên máy chủ như minh hoạ dưới đây:

   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 nhau ở bước 1 và bước 2, thì điều đó cho thấy Máy chủ được chỉ định đã bật SNI.

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

Chẩn đoán

1. Xác định xem lỗi xảy ra ở kết nối theo hướng bắc hay theo hướng nam. Để biết thêm hướng dẫn về cách xác định vấn đề này, hãy xem phần Xác định nguồn gốc của 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, bạn có thể thu thập dữ liệu tcpdump tại máy khách hoặc máy chủ có liên quan. Ứng dụng khách có thể là ứng dụng khách (đối với các kết nối đến hoặc kết nối hướng bắc) hoặc Trình xử lý thông báo (đối với các kết nối đi hoặc kết nối hướng nam). Máy chủ có thể là Bộ định tuyến biên (đối với các kết nối đến hoặc kết nối hướng bắc) hoặc máy chủ phụ trợ (đối với các kết nối đi hoặc kết nối hướng nam) dựa trên quyết định của bạn ở Bước 1.
   • Nếu là người dùng Đám mây công cộng, bạn chỉ có thể thu thập dữ liệu tcpdump trên ứng dụng khách (đối với các kết nối đến hoặc kết nối hướng bắc) hoặc máy chủ phụ trợ (đối với các 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 biên hoặc Trình xử lý thông báo.

   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. Sau đây là ví dụ về việc phân tích tcpdump bằng Wireshark:
   1. Trong ví dụ này, lỗi bắt tay TLS/SSL xảy ra giữa Trình xử lý thông báo Edge và máy chủ phụ trợ (kết nối hướng nam).
   2. Thông báo số 4 trong đầu ra tcpdump bên dưới cho thấy Trình xử lý thông báo (nguồn) đã gửi thông báo "Xin chào khách hàng" đến máy chủ phụ trợ (đích đến).

      

   3. Việc chọn thông báo "Client Hello" cho thấy 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 "Client Hello" từ Trình xử lý thông báo.
   5. Máy chủ phụ trợ sẽ ngay lập tức gửi Cảnh báo nghiêm trọng : Lỗi bắt tay đến Trình xử lý thông báo (thông báo số 5). Điều này có nghĩa là cơ chế bắt tay TLS/SSL không thành công và kết nối sẽ bị đóng.
   6. Xem xét thông báo số 6 để biết những thông tin sau
      • Máy chủ phụ trợ có hỗ trợ giao thức TLSv1.2. Điều này có nghĩa 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 Fatal Alert: Handshake Failure (Cảnh báo nghiêm trọng: Lỗi bắt tay) đến Message Processor (Trình xử lý thông báo) như minh hoạ trong hình bên dưới:

        

   7. Lỗi này có thể xảy ra vì một trong những lý do sau:
      • Message Processor không sử dụng các bộ thuật toán mật mã mà máy chủ phụ trợ hỗ trợ.
      • Máy chủ phụ trợ đã bật SNI, nhưng ứng dụng khách không gửi tên máy chủ.
   8. Xem xét kỹ hơn thông báo số 3 (Client Hello) trong đầu ra tcpdump. Xin lưu ý rằng Tiện ích: 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 đến máy chủ phụ trợ có SNI.
   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 Fatal Alert: Handshake Failure (Cảnh báo nghiêm trọng: Lỗi bắt tay) đến Message Processor (Bộ 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 Trình xử lý thông báo để xác nhận rằng Trình xử lý thông báo không được bật để giao tiếp với máy chủ có SNI.

Độ phân giải

Cho phép(các) Trình xử lý thông báo giao tiếp với các máy chủ đã bật SNI 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. Thay đổi chủ sở hữu của tệp này thành apigee:apigee:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. Khởi động lại Trình xử lý tin nhắn.

   /opt/apigee/apigee-service/bin/apigee-service message-processor restart

5. Nếu bạn có nhiều Bộ xử lý tin nhắn, hãy lặp lại các bước từ 1 đến 4 trên tất cả Bộ xử lý tin nhắn.

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