Kegagalan Jabat Tangan TLS/SSL

Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X. info

Gejala

Kegagalan handshake TLS/SSL terjadi saat klien dan server tidak dapat melakukan komunikasi menggunakan protokol TLS/SSL. Jika error ini terjadi di Apigee Edge, aplikasi klien akan menerima status HTTP 503 dengan pesan Service Unavailable. Anda melihat error ini setelah panggilan API apa pun yang menyebabkan kegagalan handshake TLS/SSL.

Pesan Error

HTTP/1.1 503 Service Unavailable

Anda juga dapat melihat pesan error ini saat terjadi kegagalan handshake TLS/SSL:

Received fatal alert: handshake_failure

Kemungkinan penyebab

TLS (Transport Layer Security, yang pendahulunya adalah SSL) adalah teknologi keamanan standar untuk membuat link terenkripsi antara server web dan klien web, seperti browser atau aplikasi. Handshake adalah proses yang memungkinkan klien dan server TLS/SSL membuat serangkaian kunci rahasia yang dapat digunakan untuk berkomunikasi. Selama proses ini, klien dan server:

1. Menyetujui versi protokol yang akan digunakan.
2. Pilih algoritma kriptografi yang akan digunakan.
3. Mengautentikasi satu sama lain dengan bertukar dan memvalidasi sertifikat digital.

Jika handshake TLS/SSL berhasil, klien dan server TLS/SSL akan mentransfer data satu sama lain dengan aman. Jika tidak, jika terjadi kegagalan handshake TLS/SSL, koneksi akan dihentikan dan klien akan menerima error 503 Service Unavailable.

Kemungkinan penyebab kegagalan handshake TLS/SSL adalah:

Ketidakcocokan Protokol

Kegagalan handshake TLS/SSL terjadi jika protokol yang digunakan oleh klien tidak didukung oleh server baik pada koneksi masuk (northbound) atau keluar (southbound). Lihat juga Memahami koneksi utara dan selatan.

Diagnosis

1. Tentukan apakah error terjadi pada koneksi northbound atau southbound. Untuk panduan lebih lanjut tentang cara membuat penentuan ini, lihat Menentukan sumber masalah.
2. Jalankan utilitas tcpdump untuk mengumpulkan informasi lebih lanjut:
   • Jika Anda adalah pengguna Private Cloud, Anda dapat mengumpulkan data tcpdump di klien atau server yang relevan. Klien dapat berupa aplikasi klien (untuk koneksi masuk, atau utara) atau Message Processor (untuk koneksi keluar, atau selatan). Server dapat berupa Edge Router (untuk koneksi masuk, atau ke utara) atau server backend (untuk koneksi keluar, atau ke selatan) berdasarkan penentuan Anda dari Langkah 1.
   • Jika Anda adalah pengguna Cloud Publik, Anda dapat mengumpulkan data tcpdump hanya di aplikasi klien (untuk koneksi masuk, atau utara) atau server backend (untuk koneksi keluar, atau selatan), karena Anda tidak memiliki akses ke Edge Router atau Message Processor.

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

   Lihat data tcpdump untuk mengetahui informasi selengkapnya tentang penggunaan perintah tcpdump.
3. Analisis data tcpdump menggunakan alat Wireshark atau alat serupa.
4. Berikut contoh analisis tcpdump menggunakan Wireshark:
   • Dalam contoh ini, kegagalan handshake TLS/SSL terjadi antara Message Processor dan server backend (koneksi keluar, atau southbound).
   • Pesan #4 dalam output tcpdump di bawah menunjukkan bahwa Message Processor (Sumber) mengirim pesan "Client Hello" ke server backend (Tujuan).
     

     

   • Jika Anda memilih pesan Client Hello, pesan tersebut menunjukkan bahwa Message Processor menggunakan protokol TLSv1.2, seperti yang ditunjukkan di bawah:

     

   • Pesan #5 menunjukkan bahwa server backend mengonfirmasi pesan "Client Hello" dari Message Processor.
   • Server backend akan segera mengirim Fatal Alert : Close Notify ke Message Processor (pesan #6). Ini berarti Handshake TLS/SSL gagal dan koneksi akan ditutup.

   • Melihat lebih lanjut pesan #6 menunjukkan bahwa penyebab kegagalan handshake TLS/SSL adalah karena server backend hanya mendukung protokol TLSv1.0 seperti yang ditunjukkan di bawah ini:

     

   • Karena ada ketidakcocokan antara protokol yang digunakan oleh Pemroses Pesan dan server backend, server backend mengirim pesan: Fatal Alert Message: Close Notify.

Resolusi

Message Processor berjalan di Java 8 dan menggunakan protokol TLSv1.2 secara default. Jika server backend tidak mendukung protokol TLSv1.2, Anda dapat melakukan salah satu langkah berikut untuk menyelesaikan masalah ini:

1. Upgrade server backend Anda untuk mendukung protokol TLSv1.2. Ini adalah solusi yang direkomendasikan karena protokol TLSv1.2 lebih aman.
2. Jika Anda tidak dapat mengupgrade server backend Anda segera karena alasan tertentu, Anda dapat memaksa Pemroses Pesan untuk menggunakan protokol TLSv1.0 untuk berkomunikasi dengan server backend dengan mengikuti langkah-langkah berikut:
   1. Jika Anda tidak menentukan server target dalam definisi TargetEndpoint proxy, tetapkan elemen Protocol ke TLSv1.0 seperti yang ditunjukkan di bawah:

      <TargetEndpoint name="default">
       …
       <HTTPTargetConnection>
         <SSLInfo>
             <Enabled>true</Enabled>
             <Protocols>
                 <Protocol>TLSv1.0</Protocol>
             </Protocols>
         </SSLInfo>
         <URL>https://myservice.com</URL>
       </HTTPTargetConnection>
       …
      </TargetEndpoint>

   2. Jika Anda mengonfigurasi server target untuk proxy, gunakan Management API ini untuk menyetel protokol ke TLSv1.0 dalam konfigurasi server target tertentu.

Cipher Tidak Cocok

Anda dapat melihat kegagalan handshake TLS/SSL jika algoritma cipher suite yang digunakan oleh klien tidak didukung oleh server pada koneksi masuk (northbound) atau keluar (southbound) di Apigee Edge. Lihat juga Memahami koneksi utara dan selatan.

Diagnosis

1. Tentukan apakah error terjadi pada koneksi northbound atau southbound. Untuk panduan lebih lanjut tentang cara membuat keputusan ini, lihat Menentukan sumber masalah.
2. Jalankan utilitas tcpdump untuk mengumpulkan informasi lebih lanjut:
   • Jika Anda adalah pengguna Private Cloud, Anda dapat mengumpulkan data tcpdump di klien atau server yang relevan. Klien dapat berupa aplikasi klien (untuk koneksi masuk, atau utara) atau Message Processor (untuk koneksi keluar, atau selatan). Server dapat berupa Edge Router (untuk koneksi masuk, atau ke utara) atau server backend (untuk koneksi keluar, atau ke selatan) berdasarkan penentuan Anda dari Langkah 1.
   • Jika Anda adalah pengguna Cloud Publik, Anda dapat mengumpulkan data tcpdump hanya di aplikasi klien (untuk koneksi masuk, atau utara) atau server backend (untuk koneksi keluar, atau selatan), karena Anda tidak memiliki akses ke Edge Router atau Message Processor.

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

   Lihat data tcpdump untuk mengetahui informasi selengkapnya tentang penggunaan perintah tcpdump.
3. Analisis data tcpdump menggunakan alat Wireshark atau alat lain yang Anda kuasai.
4. Berikut contoh analisis output tcpdump menggunakan Wireshark:
   • Dalam contoh ini, kegagalan Handshake TLS/SSL terjadi antara aplikasi Klien dan Router Edge (koneksi ke utara). Output tcpdump dikumpulkan di router Edge.

   • Pesan #4 dalam output tcpdump di bawah menunjukkan bahwa aplikasi klien (sumber) mengirim pesan "Client Hello" ke Edge Router (tujuan).

     

   • Memilih pesan Client Hello menunjukkan bahwa aplikasi klien menggunakan protokol TLSv1.2.

     

   • Pesan #5 menunjukkan bahwa Edge Router mengonfirmasi pesan "Client Hello" dari aplikasi klien.
   • Router Edge akan segera mengirim Fatal Alert : Handshake Failure ke aplikasi klien (pesan #6). Ini berarti handshake TLS/SSL gagal dan koneksi akan ditutup.
   • Pesan #6 menunjukkan informasi berikut:
     • Edge Router mendukung protokol TLSv1.2. Artinya, protokol cocok antara aplikasi klien dan Edge Router.

     • Namun, router Edge masih mengirim Fatal Alert: Handshake Failure ke aplikasi klien seperti yang ditunjukkan pada screenshot di bawah:

       

   • Error ini dapat disebabkan oleh salah satu masalah berikut:
     • Aplikasi klien tidak menggunakan algoritma cipher suite yang didukung oleh Edge Router.
     • Edge Router diaktifkan untuk SNI, tetapi aplikasi klien tidak mengirimkan nama server.
   • Pesan #4 dalam output tcpdump mencantumkan algoritma cipher suite yang didukung oleh aplikasi klien, seperti yang ditunjukkan di bawah:

     

   • Daftar algoritma cipher suite yang didukung oleh Edge Router tercantum dalam file /opt/nginx/conf.d/0-default.conf. Dalam contoh ini, Edge Router hanya mendukung algoritma cipher suite Enkripsi Tinggi.
   • Aplikasi klien tidak menggunakan algoritma cipher suite Enkripsi Tinggi. Ketidakcocokan ini adalah penyebab kegagalan handshake TLS/SSL.
   • Karena Edge Router diaktifkan untuk SNI, scroll ke bawah ke pesan #4 di output tcpdump dan pastikan aplikasi klien mengirim nama server dengan benar, seperti yang ditunjukkan pada gambar di bawah:
     
     
     
   • Jika nama ini valid, Anda dapat menyimpulkan bahwa kegagalan handshake TLS/SSL terjadi karena algoritma cipher suite yang digunakan oleh aplikasi klien tidak didukung oleh Edge Router.

Resolusi

Anda harus memastikan bahwa klien menggunakan algoritma cipher suite yang didukung oleh server. Untuk menyelesaikan masalah yang dijelaskan di bagian Diagnostik sebelumnya, download dan instal paket Java Cryptography Extension (JCE) dan sertakan dalam penginstalan Java untuk mendukung algoritma cipher suite Enkripsi Tinggi.

Sertifikat Salah

Kegagalan handshake TLS/SSL terjadi jika Anda memiliki sertifikat yang salah di keystore/truststore, baik di koneksi masuk (northbound) atau keluar (southbound) di Apigee Edge. Lihat juga Memahami koneksi utara dan selatan.

Jika masalahnya adalah arah utara, Anda mungkin melihat pesan error yang berbeda-beda bergantung pada penyebabnya.

Bagian berikut mencantumkan contoh pesan error dan langkah-langkah untuk mendiagnosis dan menyelesaikan masalah ini.

Pesan error

Anda mungkin melihat pesan error yang berbeda-beda, bergantung pada penyebab kegagalan handshake TLS/SSL. Berikut adalah contoh pesan error yang mungkin Anda lihat saat memanggil 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

Kemungkinan penyebab

Penyebab umum masalah ini adalah:

Hostname Tidak Cocok

Diagnosis

1. Perhatikan nama host yang digunakan dalam URL yang ditampilkan oleh panggilan API Edge Management berikut:

   curl -v https://myorg.domain.com/v1/getinfo

   Contoh:

   curl -v https://api.enterprise.apigee.com/v1/getinfo

2. Dapatkan CN yang digunakan dalam sertifikat yang disimpan di keystore tertentu. Anda dapat menggunakan Edge Management API berikut untuk mendapatkan detail sertifikat:
   1. Dapatkan nama sertifikat di keystore:
      
      Jika Anda adalah pengguna Private Cloud, gunakan Management API sebagai berikut:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      Jika Anda adalah pengguna Cloud Publik, gunakan Management API sebagai berikut:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Dapatkan detail sertifikat di keystore menggunakan Edge Management API.
      
      Jika Anda adalah pengguna Private Cloud:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Jika Anda adalah pengguna Cloud Publik:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Contoh sertifikat::

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

      Nama subjek dalam sertifikat utama memiliki CN sebagai something.domain.com.

      Karena nama host yang digunakan dalam URL permintaan API (lihat langkah #1 di atas) dan nama subjek dalam sertifikat tidak cocok, Anda akan mengalami kegagalan handshake TLS/SSL.

Resolusi

Masalah ini dapat diselesaikan dengan salah satu dari dua cara berikut:

• Dapatkan sertifikat (jika Anda belum memilikinya) dengan CN subjek yang memiliki sertifikat wildcard, lalu upload rantai sertifikat lengkap yang baru ke keystore. Contoh:

  "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",

• Dapatkan sertifikat (jika Anda belum memilikinya) dengan CN subjek yang ada, tetapi gunakan your-org.your-domain sebagai nama alternatif subjek, lalu upload rantai sertifikat lengkap ke keystore.

Referensi

Keystore dan Truststore

Rantai sertifikat tidak lengkap atau salah

Diagnosis

1. Dapatkan CN yang digunakan dalam sertifikat yang disimpan di keystore tertentu. Anda dapat menggunakan Edge Management API berikut untuk mendapatkan detail sertifikat:
   1. Dapatkan nama sertifikat di keystore:
      
      Jika Anda adalah pengguna Private Cloud:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

      Jika Anda adalah pengguna Cloud Publik:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Dapatkan detail sertifikat di keystore:
      
      Jika Anda adalah pengguna Private Cloud:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Jika Anda adalah pengguna Cloud Publik:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

   3. Validasi sertifikat dan rantainya serta pastikan sertifikat tersebut mematuhi pedoman yang diberikan dalam artikel Cara kerja rantai sertifikat untuk memastikan sertifikat tersebut adalah rantai sertifikat yang valid dan lengkap. Jika rantai sertifikat yang disimpan di keystore tidak lengkap atau tidak valid, Anda akan melihat kegagalan handshake TLS/SSL.
   4. Grafik berikut menunjukkan contoh sertifikat dengan rantai sertifikat yang tidak valid, dengan sertifikat perantara dan root tidak cocok:

   Contoh sertifikat perantara dan root yang penerbit dan subjeknya tidak cocok

   
   

Resolusi

1. Dapatkan sertifikat (jika Anda belum memilikinya) yang mencakup rantai sertifikat yang lengkap dan valid.
2. Jalankan perintah openssl berikut untuk memverifikasi bahwa rantai sertifikat sudah benar dan lengkap:

   openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert

3. Upload rantai sertifikat yang divalidasi ke keystore.

Sertifikat yang kedaluwarsa atau tidak dikenal yang dikirim oleh server atau klien

Jika sertifikat yang salah/sudah habis masa berlakunya dikirim oleh server/klien di koneksi utara atau selatan, maka ujung lainnya (server/klien) akan menolak sertifikat tersebut sehingga menyebabkan kegagalan handshake TLS/SSL.

Diagnosis

1. Tentukan apakah error terjadi pada koneksi northbound atau southbound. Untuk panduan lebih lanjut tentang cara membuat penentuan ini, lihat Menentukan sumber masalah.
2. Jalankan utilitas tcpdump untuk mengumpulkan informasi lebih lanjut:
   • Jika Anda adalah pengguna Private Cloud, Anda dapat mengumpulkan data tcpdump di klien atau server yang relevan. Klien dapat berupa aplikasi klien (untuk koneksi masuk, atau utara) atau Message Processor (untuk koneksi keluar, atau selatan). Server dapat berupa Edge Router (untuk koneksi masuk, atau ke utara) atau server backend (untuk koneksi keluar, atau ke selatan) berdasarkan penentuan Anda dari Langkah 1.
   • Jika Anda adalah pengguna Cloud Publik, Anda dapat mengumpulkan data tcpdump hanya di aplikasi klien (untuk koneksi masuk, atau utara) atau server backend (untuk koneksi keluar, atau selatan), karena Anda tidak memiliki akses ke Edge Router atau Message Processor.

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

   Lihat data tcpdump untuk mengetahui informasi selengkapnya tentang penggunaan perintah tcpdump.
3. Analisis data tcpdump menggunakan Wireshark atau alat serupa.
4. Dari output tcpdump, tentukan host (klien atau server) yang menolak sertifikat selama langkah verifikasi.
5. Anda dapat mengambil sertifikat yang dikirim dari ujung lainnya dari output tcpdump, asalkan data tidak dienkripsi. Hal ini akan berguna untuk membandingkan apakah sertifikat ini cocok dengan sertifikat yang tersedia di truststore.
6. Tinjau contoh tcpdump untuk komunikasi SSL antara Message Processor dan server backend.

   Contoh tcpdump yang menampilkan error Sertifikat Tidak Diketahui

   
   

   1. Pemroses Pesan (klien) mengirim "Client Hello" ke server backend (server) dalam pesan #59.
   2. Server backend mengirim "Server Hello" ke Pemroses Pesan dalam pesan #61.
   3. Keduanya saling memvalidasi algoritma protokol dan cipher suite yang digunakan.
   4. Server backend mengirimkan pesan Certificate dan Server Hello Done ke Message Processor dalam pesan #68.
   5. Prosesor Pesan mengirimkan Pemberitahuan Fatal "Deskripsi: Sertifikat Tidak Diketahui" dalam pesan #70.
   6. Melihat lebih lanjut pesan #70, tidak ada detail tambahan selain pesan notifikasi seperti yang ditunjukkan di bawah ini:

      
      

   7. Tinjau pesan #68 untuk mendapatkan detail tentang sertifikat yang dikirim oleh server backend, seperti yang ditunjukkan pada grafik berikut:

      

   8. Sertifikat server backend dan seluruh rantainya tersedia di bagian "Certificates", seperti yang ditunjukkan pada gambar di atas.
7. Jika sertifikat ditemukan tidak dikenal oleh Router (arah utara) atau Message Processor (arah selatan) seperti dalam contoh yang diilustrasikan di atas, ikuti langkah-langkah berikut:
   1. Mendapatkan sertifikat dan rantainya yang disimpan di truststore tertentu. (Lihat konfigurasi host virtual untuk Router dan konfigurasi endpoint target untuk Message Processor). Anda dapat menggunakan API berikut untuk mendapatkan detail sertifikat:
      1. Mendapatkan nama sertifikat di truststore:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs

      2. Dapatkan detail sertifikat di truststore:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name

   2. Periksa apakah sertifikat yang disimpan di truststore Router (northbound) atau Message Processor (southbound) cocok dengan sertifikat yang disimpan di keystore aplikasi klien (northbound) atau server target (southbound), atau sertifikat yang diperoleh dari output tcpdump. Jika ada ketidakcocokan, itulah penyebab kegagalan handshake TLS/SSL.
8. Jika sertifikat ditemukan tidak dikenal oleh aplikasi klien (arah utara) atau server target (arah selatan), ikuti langkah-langkah berikut:
   1. Mendapatkan rantai sertifikat lengkap yang digunakan dalam sertifikat yang disimpan di keystore tertentu. (Lihat konfigurasi host virtual untuk Router dan konfigurasi endpoint target untuk Message Processor.) Anda dapat menggunakan API berikut untuk mendapatkan detail sertifikat:
      1. Mendapatkan nama sertifikat di keystore:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      2. Dapatkan detail sertifikat di keystore:
         

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
         

   2. Periksa apakah sertifikat yang disimpan di keystore Router (northbound) atau Message Processor (southbound) cocok dengan sertifikat yang disimpan di truststore aplikasi klien (northbound) atau server target (southbound), atau sertifikat yang diperoleh dari output tcpdump. Jika ada ketidakcocokan, maka itulah penyebab kegagalan handshake SSL.
9. Jika sertifikat yang dikirim oleh server/klien ditemukan telah habis masa berlakunya, maka klien/server penerima akan menolak sertifikat tersebut dan Anda akan melihat pesan peringatan berikut di tcpdump:

   Pemberitahuan (Level: Fatal, Deskripsi: Masa berlaku sertifikat telah habis)

10. Pastikan masa berlaku sertifikat di keystore host yang sesuai telah habis.

Resolusi

Untuk mengatasi masalah yang diidentifikasi dalam contoh di atas, upload sertifikat server backend yang valid ke trustore di Message Processor.

Tabel berikut merangkum langkah-langkah untuk menyelesaikan masalah, bergantung pada penyebab masalah.

SNI Diaktifkan Server

Kegagalan handshake TLS/SSL dapat terjadi saat klien berkomunikasi dengan Server yang Mengaktifkan Indikasi Nama Server (SNI), tetapi klien tidak mengaktifkan SNI. Hal ini dapat terjadi pada koneksi utara atau selatan di Edge.

Pertama, Anda perlu mengidentifikasi nama host dan nomor port server yang digunakan serta memeriksa apakah server tersebut mendukung SNI atau tidak.

Identifikasi server yang mendukung SNI

1. Jalankan perintah openssl dan coba hubungkan ke nama host server yang relevan (Edge Router atau server backend) tanpa meneruskan nama server, seperti yang ditunjukkan di bawah:

   openssl s_client -connect hostname:port

   Anda mungkin mendapatkan sertifikat dan terkadang Anda mungkin mengamati kegagalan handshake di perintah openssl, seperti yang ditunjukkan di bawah:
   

   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. Jalankan perintah openssl dan coba hubungkan ke nama host server yang relevan (Router Edge atau server backend) dengan meneruskan nama server seperti yang ditunjukkan di bawah:

   openssl s_client -connect hostname:port -servername hostname

3. Jika Anda mengalami kegagalan handshake pada langkah #1 atau mendapatkan sertifikat yang berbeda pada langkah #1 dan langkah #2, berarti Server yang ditentukan mendukung SNI.

Setelah mengidentifikasi bahwa server mendukung SNI, Anda dapat mengikuti langkah-langkah di bawah untuk memeriksa apakah kegagalan handshake TLS/SSL disebabkan oleh klien yang tidak dapat berkomunikasi dengan server SNI.

Diagnosis

1. Tentukan apakah error terjadi pada koneksi northbound atau southbound. Untuk panduan lebih lanjut tentang cara membuat penentuan ini, lihat Menentukan sumber masalah.
2. Jalankan utilitas tcpdump untuk mengumpulkan informasi lebih lanjut:
   • Jika Anda adalah pengguna Private Cloud, Anda dapat mengumpulkan data tcpdump di klien atau server yang relevan. Klien dapat berupa aplikasi klien (untuk koneksi masuk, atau utara) atau Message Processor (untuk koneksi keluar, atau selatan). Server dapat berupa Edge Router (untuk koneksi masuk, atau ke utara) atau server backend (untuk koneksi keluar, atau ke selatan) berdasarkan penentuan Anda dari Langkah 1.
   • Jika Anda adalah pengguna Cloud Publik, Anda dapat mengumpulkan data tcpdump hanya di aplikasi klien (untuk koneksi masuk, atau utara) atau server backend (untuk koneksi keluar, atau selatan), karena Anda tidak memiliki akses ke Edge Router atau Message Processor.

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

   Lihat data tcpdump untuk mengetahui informasi selengkapnya tentang penggunaan perintah tcpdump.
3. Analisis output tcpdump menggunakan Wireshark atau alat serupa.
4. Berikut adalah analisis contoh tcpdump menggunakan Wireshark:
   1. Dalam contoh ini, kegagalan handshake TLS/SSL terjadi antara Edge Message Processor dan server backend (koneksi ke selatan).
   2. Pesan #4 dalam output tcpdump di bawah menunjukkan bahwa Pemroses Pesan (sumber) mengirim pesan "Client Hello" ke server backend (tujuan).

      

   3. Memilih pesan "Client Hello" menunjukkan bahwa Message Processor menggunakan protokol TLSv1.2.

      

   4. Pesan #4 menunjukkan bahwa server backend mengonfirmasi pesan "Client Hello" dari Message Processor.
   5. Server backend akan segera mengirimkan Fatal Alert : Handshake Failure ke Message Processor (pesan #5). Ini berarti handshake TLS/SSL gagal dan koneksi akan ditutup.
   6. Tinjau pesan #6 untuk menemukan informasi berikut
      • Server backend mendukung protokol TLSv1.2. Artinya, protokol cocok antara Message Processor dan server backend.
      • Namun, server backend masih mengirim Fatal Alert: Handshake Failure ke Message Processor seperti yang ditunjukkan pada gambar di bawah:

        

   7. Error ini mungkin terjadi karena salah satu alasan berikut:
      • Message Processor tidak menggunakan algoritma cipher suite yang didukung oleh server backend.
      • Server backend mendukung SNI, tetapi aplikasi klien tidak mengirimkan nama server.
   8. Tinjau pesan #3 (Client Hello) di output tcpdump secara lebih mendetail. Perhatikan bahwa Extension: server_name tidak ada, seperti yang ditunjukkan di bawah:

      

   9. Hal ini mengonfirmasi bahwa Message Processor tidak mengirim server_name ke server backend yang mendukung SNI.
   10. Hal ini menyebabkan kegagalan handshake TLS/SSL dan alasan server backend mengirim Fatal Alert: Handshake Failure ke Message Processor.
5. Verifikasi bahwa jsse.enableSNIExtension property di system.properties disetel ke salah (false) di Pemroses Pesan untuk mengonfirmasi bahwa Pemroses Pesan tidak diaktifkan untuk berkomunikasi dengan server yang mendukung SNI.

Resolusi

Aktifkan Pemroses Pesan untuk berkomunikasi dengan server yang mendukung SNI dengan melakukan langkah-langkah berikut:

1. Buat file/opt/apigee/customer/application/message-processor.properties (jika belum ada).
2. Tambahkan baris berikut ke file ini: conf_system_jsse.enableSNIExtension=true
3. Ubah pemilik file ini menjadi apigee:apigee:

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

4. Mulai ulang Pemroses Pesan.

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

5. Jika Anda memiliki lebih dari satu Pemroses Pesan, ulangi langkah #1 hingga #4 di semua Pemroses Pesan.

Jika Anda tidak dapat menentukan penyebab kegagalan TLS/SSL Handshake dan memperbaiki masalahnya atau Anda memerlukan bantuan lebih lanjut, hubungi Dukungan Apigee Edge. Berikan detail lengkap tentang masalah tersebut beserta output tcpdump.