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 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 ứng dụng nhận được trạng thái HTTP 503 với thông báo Service Available. Bạn 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 cho thiết lập 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 quy trình cho phép máy khách và máy chủ TLS/SSL thiết lập một tập hợp khoá bí mật các khoá mà chúng có thể giao tiếp. Trong quá trình này, máy khách và máy chủ:

1. Đồng ý với phiên bản của giao thức cần sử dụng.
2. Chọn thuật toán mật mã sẽ 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ỉ kỹ thuật số.

Nếu 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 từng khác một cách an toàn. Ngược lại, nếu xảy ra lỗi bắt tay TLS/SSL, kết nối sẽ bị chấm dứt và ứng dụng nhận được lỗi 503 Service Unavailable.

Các nguyên nhân có thể gây ra 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 được ứng dụng sử dụng không được hỗ trợ bởi máy chủ tại kết nối đến (theo hướng bắc) hoặc đi (hướng về phía nam). Xem thêm Hiểu sự kết nối giữa hướng bắc và hướng nam.

Chẩn đoán

1. Xác định xem lỗi xảy ra tại hướng bắc chuẩn hay kết nối hướng về phía nam. Để được hướng dẫn thêm về cách làm xác định, xem Xác định nguồn gốc của vấn đề.
2. Chạy 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 tcpdump tại máy khách hoặc máy chủ có liên quan. Ứng dụng có thể là ứng dụng khách (đối với ứng dụng khách đến, hoặc các kết nối về hướng bắc) hoặc Thông báo Bộ xử lý (dành cho 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 Edge (đối với kết nối đến hoặc hướng bắc) hoặc máy chủ phụ trợ (đối với các kết nối đi hoặc về hướng nam) dựa trên quyết định của bạn trong Bước 1.
   • Nếu là người dùng Cloud Public, bạn có thể thu thập tcpdump chỉ dữ liệu trên ứng dụng khách (cho các kết nối đến hoặc hướng bắc) hoặc máy chủ phụ trợ (cho các kết nối đi hoặc về hướng nam) vì bạn có không có quyền truy cập vào Edge Router hoặc Message Processor.

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

   Xem tcpdump để biết thêm thông tin về cách sử dụng 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à 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 Trình xử lý thư và máy chủ phụ trợ (kết nối đi hoặc hướng về phía nam).
   • Thông báo số 4 trong dữ liệu đầu ra tcpdump dưới đây cho biết rằng Trình xử lý thông báo (Nguồn) đã gửi một "Xin chào khách hàng" thông báo đến máy chủ phụ trợ (Đích).
     

     

   • Nếu bạn chọn thông báo Client Hello, điều đó cho thấy rằng Trình xử lý thông báo đang sử dụng Giao thức TLSv1.2, như trình bày dưới đây:

     

   • Thông báo số 5 cho biết máy chủ phụ trợ xác nhận "Xin chào ứng dụng khách" tin nhắn từ Trình xử lý thư.
   • Máy chủ phụ trợ sẽ ngay lập tức gửi Cảnh báo nghiêm trọng : Đóng thông báo đến Trình xử lý tin nhắn (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.

   • 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ư hình dưới đây:

     

   • Do có sự 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ợ, máy chủ phụ trợ đã gửi thông báo: 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 phần phụ trợ không hỗ trợ TLSv1.2 giao thức, sau đó bạn có thể thực hiện một trong các bước sau đây để 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ì thì giao thức TLSv1.2 an toàn hơn.
2. Nếu vì lý do nào đó mà bạn không thể nâng cấp ngay máy chủ phụ trợ, thì bạn có thể buộc Bộ xử lý thư sử dụng giao thức TLSv1.0 để giao tiếp 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, thì hãy đặt phần tử Protocol sang 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, sau đó hãy sử dụng API quản lý này để đặt giao thức thành TLSv1.0 trong cấu hình máy chủ mục tiêu.

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 thuật toán bộ thuật toán mật mã mà ứng dụng sử dụng không được máy chủ hỗ trợ khi kết nối đến (theo hướng bắc) hoặc đi (đi hướng nam) trong Apigee Edge. Xem thêm Hiểu sự kết nối giữa hướng bắc và hướng nam.

Chẩn đoán

1. Xác định xem lỗi có xảy ra tại kết nối theo hướng bắc hoặc 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 Xác định nguồn gốc vấn đề.
2. Chạy 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 tcpdump tại máy khách hoặc máy chủ có liên quan. Ứng dụng có thể là ứng dụng khách (đối với ứng dụng khách đến, hoặc các kết nối về hướng bắc) hoặc Thông báo Bộ xử lý (dành cho 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 Edge (đối với kết nối đến hoặc hướng bắc) hoặc máy chủ phụ trợ (đối với các kết nối đi hoặc về hướng nam) dựa trên quyết định của bạn trong Bước 1.
   • Nếu là người dùng Cloud Public, bạn có thể thu thập tcpdump chỉ dữ liệu trên ứng dụng khách (cho các kết nối đến hoặc hướng bắc) hoặc máy chủ phụ trợ (cho các kết nối đi hoặc về hướng nam) vì bạn có không có quyền truy cập vào Edge Router hoặc Message Processor.

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

   Xem 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, đã xảy ra lỗi Giao thức bắt tay TLS/SSL giữa Ứng dụng khách và Bộ định tuyến Edge (kết nối hướng bắc). Dữ liệu đầu ra tcpdump đã được thu thập trên Edge bộ định tuyến.

   • Thông báo số 4 trong dữ liệu đầu ra tcpdump dưới đây cho biết rằng ứng dụng khách (nguồn) đã gửi một "Xin chào khách hàng" nội dung đến Bộ định tuyến cạnh (đích).

     

   • Chọn thông báo Client Hello cho biết ứng dụng khách đang sử dụng Giao thức TLSv1.2.

     

   • Thông báo số 5 cho biết Bộ định tuyến cạnh xác nhận "Xin chào ứng dụng khách" tin nhắn từ ứng dụng khách.
   • Bộ định tuyến Edge gửi ngay một Cảnh báo nghiêm trọng : Lỗi bắt tay tới ứ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ỹ thông báo số 6, bạn sẽ thấy những thông tin sau:
     • Bộ định tuyến Edge hỗ trợ giao thức TLSv1.2. Điều này có nghĩa là giao thức khớp với giữa ứ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: Bắt tay Không thể đối với ứ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 các vấn đề sau:
     • Ứng dụng khách không sử dụng các thuật toán bộ thuật toán mật mã được Máy định tuyến cạnh.
     • Bộ định tuyến Edge được bật SNI nhưng ứng dụng khách không gửi tên máy chủ.
   • Thông báo số 4 trong dữ liệu đầu ra của tcpdump liệt kê các thuật toán của bộ thuật toán mật mã mà ứng dụng hỗ trợ ứng dụng, như được hiển thị dưới đây:

     

   • Danh sách các thuật toán bộ mật mã được 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, Edge Router chỉ hỗ trợ các thuật toán của 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á cao. Sự không khớp này là nguyên nhân dẫn đến Lỗi bắt tay TLS/SSL.
   • Vì Bộ định tuyến cạnh được bật SNI, hãy cuộ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ủ chính xác, như được thể hiện 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 do thuật toán của bộ mật mã được ứng dụng sử dụng không được hỗ trợ bởi Máy định tuyến cạnh.

Độ phân giải

Bạn phải đảm bảo rằng khách hàng sử dụng các thuật toán bộ thuật toán mật mã được máy chủ hỗ trợ. Để giải quyết vấn đề được mô tả trong phần trước Chẩn đoán, tải xuống và cài đặt Gói Tiện ích mã hoá Java (JCE) và đưa vào gói Java để hỗ trợ các thuật toán của bộ thuật toán mật mã Mã hoá 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á/đáng tin cậy, khi kết nối đến (đi hướng bắc) hoặc đi (đi hướng nam) trong Apigee Edge. Xem thêm Hiểu sự kết nối giữa hướng bắc và hướng nam.

Nếu vấn đề là theo hướng hướng về hướng 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 và các bước để chẩn đoán và giải quyết vấn đề này vấn đề.

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ể

Dưới đây là những nguyên nhân điển hình dẫn đến vấn đề này:

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

Chẩn đoán

1. Lưu ý tên máy chủ được sử dụng trong URL được lệnh gọi API quản lý Edge sau 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 sau đây là các API quản lý Edge để biết 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 Public, 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 đối tượng trong chứng chỉ chính có CN là something.domain.com.

      Do tên máy chủ được sử dụng trong URL yêu cầu API (tham khảo bước#1 ở trên) và chủ đề tên trong chứng chỉ không khớp, thì 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 chứng chỉ (nếu bạn chưa có chứng chỉ) trong đó tiêu đề CN có ký tự đại diện chứng chỉ, 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ó chứng chỉ) với chủ đề hiện có là CN, nhưng hãy sử dụng your-org.your-domain làm tên thay thế của chủ đề, sau đó tải toàn bộ chuỗi chứng chỉ vào kho khoá.

Tài liệu tham khảo

Kho khoá và Truststores

Chuỗi chứng chỉ chưa 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 sau đây là các API quản lý Edge để biết 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. 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 của chứng chỉ cũng như xác minh chứng chỉ tuân thủ theo các nguyên tắc nêu trong bài viết Cách hoạt động của chuỗi chứng chỉ để đảm bảo chuỗi chứng chỉ đó là hợp lệ và hoàn chỉnh chuỗi chứng chỉ. Nếu chuỗi chứng chỉ được lưu trữ trong kho khoá là không hoàn chỉnh hoặc không hợp lệ, thì bạn sẽ thấy giao thức bắt tay TLS/SSL lỗi.
   4. Hình ảnh dưới đây hiển thị 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 với nhau:

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

   
   

Độ phân giải

1. Lấy chứng chỉ (nếu bạn chưa có chứng chỉ) bao gồm chuỗi chứng chỉ.
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 thà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á.

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

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

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

   Xem 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 công cụ tương tự.
4. Từ đầu ra tcpdump, 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 sẽ không được mã hoá. Điều này sẽ rất hữu ích khi so sánh xem chứng chỉ này có khớp với chứng chỉ có sẵn trong kho tin cậy.
6. Xem lại tcpdump mẫu về hoạt động giao tiếp SSL giữa Trình xử lý thư và máy chủ phụ trợ.

   Mẫu tcpdump cho thấy lỗi Certificate Unknown

   
   

   1. Trình xử lý tin nhắn (máy khách) gửi thông báo "Xin chào ứng dụng" đế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" (Xin chào máy chủ) đến Trình xử lý thư trong thư #61.
   3. Hai thuật toán này xác thực lẫn nhau đối với giao thức và thuật toán bộ thuật toán mật mã được sử dụng.
   4. Máy chủ phụ trợ gửi thông báo Chứng chỉ và thông báo Hello Done (Xong) của máy chủ cho Bộ xử lý tin nhắn trong tin nhắn số 68.
   5. Bộ xử lý tin nhắn gửi Cảnh báo nghiêm trọng "Description: Certificate Không xác định" trong thông báo số 70.
   6. Khi xem xét kỹ thông báo số 70, không có thông tin chi tiết nào khác so với thông báo cảnh báo như được hiển thị 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ỉ mà phần phụ trợ gửi máy chủ, như được thể hiện trong hình sau:

      

   8. Chứng chỉ của máy chủ phụ trợ và chuỗi đầy đủ của máy chủ phụ trợ đều có sẵn trong trường "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 bộ định tuyến không xác định được chứng chỉ Bộ xử lý thư (theo hướng nam) như trong ví dụ minh hoạ ở trên, sau đó đi theo các các bước:
   1. Lấy chứng chỉ và chuỗi của chứng chỉ được lưu trữ trong kho tin cậy cụ thể. (Tham khảo đối với cấu hình máy chủ ảo cho Bộ định tuyến và cấu hình điểm cuối đích cho Trình xử lý thư). Bạn có thể sử dụng các API sau để lấy thông tin chi tiết về chứng chỉ:
      1. Lấy tên chứng chỉ trong kho tin cậy:

         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 kho tin cậy:

         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ó được lưu trữ trong kho tin cậy của Bộ định tuyến (hướng hướng bắc) hay không Trình xử lý thư (hướng về phía nam) khớp với chứng chỉ được lưu trữ trong kho khoá của ứng dụng khách (hướng hướng bắc) hoặc máy chủ mục tiêu (hướng về phía nam) hoặc giá trị nhận được từ dữ liệu đầu ra tcpdump. Nếu thông tin không khớp, thì đó là nguyên nhân dẫn đến lỗi bắt tay TLS/SSL.
8. Nếu ứng dụng khách (theo hướng bắc) phát hiện thấy chứng chỉ không xác định hoặc máy chủ mục tiêu (hướng về phía nam), sau đó 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á. (Tham khảo cấu hình máy chủ ảo của Bộ định tuyến và điểm cuối đích cho Trình xử lý thư.) Bạn có thể sử dụng các API sau để lấy thông tin chi tiết của 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 (theo hướng bắc) hay Trình xử lý thư (hướng về phía nam) khớp với chứng chỉ được lưu trữ trong kho tin cậy của ứng dụng khách (theo hướng bắc) hoặc máy chủ mục tiêu (hướng về phía nam) hoặc một máy chủ lấy từ dữ liệu đầu ra tcpdump. Nếu thông tin không khớp, thì đó là nguyên nhân gây ra lỗi SSL không bắt tay được.
9. Nếu chứng chỉ do máy chủ/ứng dụng gửi đi được phát hiện là đã hết hạn thì trình nhận máy khách/máy chủ từ chối chứng chỉ và bạn thấy thông báo cảnh báo sau trong tcpdump:

   Cảnh báo (Cấp độ: 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 đề đã xác định trong ví dụ trên, hãy tải tệp chứng chỉ cho trustore trên Bộ xử lý thư.

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 vấn đề.

Đã bật SNI Máy chủ

Lỗi bắt tay TLS/SSL có thể xảy ra khi máy khách đang giao tiếp với Máy chủ Đã bật chỉ báo tên (SNI) Máy chủ nhưng ứng dụng khách chưa được bật SNI. Điều này có thể xảy ra tại hướng bắc hoặc kết nối theo 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 và kiểm tra xem nó có đượ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 (Edge Bộ định tuyến 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 chứng chỉ và đôi khi có thể thấy lỗi bắt tay trong lệnh openssl, như được hiển thị 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ủ có liên quan (Bộ định tuyến cạnh hoặc máy chủ phụ trợ) bằng cách chuyể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 chứng chỉ khác nhau ở bước 1 và bước 2, thì nó chỉ ra rằng Máy chủ được chỉ định đã được bật SNI.

Sau khi xác định rằng máy chủ đã được 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ông thể giao tiếp hay không máy chủ SNI.

Chẩn đoán

1. Xác định xem lỗi xảy ra tại hướng bắc chuẩn hay kết nối hướng về phía nam. Để được hướng dẫn thêm về cách làm xác định, xem Xác định nguồn gốc của vấn đề.
2. Chạy 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 tcpdump tại máy khách hoặc máy chủ có liên quan. Ứng dụng có thể là ứng dụng khách (đối với ứng dụng khách đến, hoặc các kết nối về hướng bắc) hoặc Thông báo Bộ xử lý (dành cho 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 Edge (đối với kết nối đến hoặc hướng bắc) hoặc máy chủ phụ trợ (đối với các kết nối đi hoặc về hướng nam) dựa trên quyết định của bạn trong Bước 1.
   • Nếu là người dùng Cloud Public, bạn có thể thu thập tcpdump chỉ dữ liệu trên ứng dụng khách (cho các kết nối đến hoặc hướng bắc) hoặc máy chủ phụ trợ (cho các kết nối đi hoặc về hướng nam) vì bạn có không có quyền truy cập vào Edge Router hoặc Message Processor.

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

   Xem 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 đầu ra tcpdump bằng Wireshark hoặc công cụ tương tự.
4. Dưới đây là bản 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 Thông báo Edge Bộ xử lý và máy chủ phụ trợ (kết nối theo hướng nam).
   2. Thông báo số 4 trong dữ liệu đầu ra tcpdump dưới đây cho biết rằng Trình xử lý thông báo (nguồn) đã gửi "Xin chào khách hàng" thông báo đến máy chủ phụ trợ (đích).

      

   3. Chọn "Xin chào khách hàng" Thông báo cho biết Thông báo Bộ xử lý đ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 "Xin chào ứng dụng" tin nhắn từ Trình xử lý tin nhắn.
   5. Máy chủ phụ trợ ngay lập tức gửi Cảnh báo nghiêm trọng : Bắt tay Lỗi với Trình xử lý thư (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 lại thông báo số 6 để khám phá 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 được so 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: Bắt tay Lỗi đối với Trình xử lý thư 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ư không sử dụng các thuật toán bộ thuật toán mật mã được hỗ trợ bởi máy chủ phụ trợ.
      • Máy chủ phụ trợ đã được bật SNI nhưng ứng dụng khách không gửi tên máy chủ.
   8. Xem lại thông báo số 3 (Xin chào ứng dụng) trong dữ liệu đầu ra tcpdump để biết thêm thông tin chi tiết. 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ư đã không gửi server_name đến máy chủ phụ trợ đã bật SNI.
   10. Đây là nguyên nhân gây ra lỗi bắt tay TLS/SSL và lý do chương trình phụ trợ máy chủ gửi Cảnh báo nghiêm trọng: Lỗi bắt tay đến Thông báo Bộ xử lý.
5. Xác minh rằng jsse.enableSNIExtension property trong system.properties được đặt thành false trên Trình xử lý thư để 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 SNI.

Độ phân giải

Cho phép(các) Trình xử lý thư 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/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ỉ định 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 Trình xử lý thư.

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

5. Nếu bạn có nhiều Trình xử lý thư, 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 thể xác định nguyên nhân gây ra lỗi Giao thức bắt tay TLS/SSL và khắc phục vấn đề hoặc bạn cần hỗ trợ thêm, hãy liên hệ với Hỗ trợ Apigee Edge. Chia sẻ toàn bộ thông tin chi tiết về vấn đề cùng với dữ liệu đầu ra tcpdump.