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. Ketika error ini terjadi di Apigee Edge, aplikasi klien akan menerima status HTTP 503 dengan pesan Service Available (Layanan Tidak Tersedia). Anda melihat error ini setelah panggilan API apa pun saat kegagalan handshake TLS/SSL terjadi.

Pesan Error

HTTP/1.1 503 Service Unavailable

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

Received fatal alert: handshake_failure

Kemungkinan penyebab

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

1. Setujui versi protokol yang akan digunakan.
2. Pilih algoritma kriptografi yang akan digunakan.
3. Lakukan autentikasi satu sama lain dengan menukarkan 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:

Cause	Deskripsi	Siapa yang dapat melakukan langkah-langkah pemecahan masalah
Protokol tidak cocok	Protokol yang digunakan oleh klien tidak didukung oleh server.	Pengguna Cloud Pribadi dan Publik
Cipher Suite tidak cocok	Cipher suite yang digunakan oleh klien tidak didukung oleh server.	Pengguna Cloud Pribadi dan Publik
Sertifikat Salah	Nama host di URL yang digunakan oleh klien tidak cocok dengan nama host di sertifikat yang disimpan di sisi server.	Pengguna Cloud Pribadi dan Publik
	Rantai sertifikat yang tidak lengkap atau tidak valid disimpan di sisi klien atau server.	Pengguna Cloud Pribadi dan Publik
	Sertifikat yang salah atau habis masa berlakunya dikirim oleh klien ke server atau dari server ke klien.	Pengguna Cloud Pribadi dan Publik
Server yang Mendukung SNI	Server backend mengaktifkan Server Name Indication (SNI); tetapi klien tidak dapat berkomunikasi dengan server SNI.	Khusus pengguna Private Cloud

Protokol Ketidakcocokan

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

Diagnosis

1. Tentukan apakah error terjadi di koneksi northbound atau southbound. Untuk panduan lebih lanjut terkait 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 koneksi utara) atau Pemroses Pesan (untuk koneksi keluar atau arah selatan). Server dapat berupa Router Edge (untuk koneksi masuk atau ke utara) atau server backend (untuk koneksi keluar atau arah 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 ke utara) atau server backend (untuk koneksi keluar atau menuju selatan), karena Anda tidak memiliki akses ke Router Edge atau Pemroses Pesan.

   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 yang serupa.
4. Berikut ini contoh analisis tcpdump menggunakan Wireshark:
   • Dalam contoh ini, kegagalan handshake TLS/SSL terjadi antara Pemroses Pesan dan server backend (koneksi keluar atau arah selatan).
   • Pesan #4 dalam output tcpdump di bawah menunjukkan bahwa Pemroses Pesan (Sumber) mengirim pesan "Client Hello" ke server backend (Tujuan).
     

     

   • Jika Anda memilih pesan Client Hello, ini akan menunjukkan bahwa Pemroses Pesan menggunakan protokol TLSv1.2, seperti yang ditunjukkan di bawah:

     

   • Pesan #5 menunjukkan bahwa server backend mengonfirmasi pesan "Client Hello" dari Pemroses Pesan.
   • Server backend segera mengirimkan Fatal Alert : Close Notify ke Pemroses Pesan (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 bahwa server backend hanya mendukung protokol TLSv1.0 seperti yang ditunjukkan di bawah ini:

     

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

Resolusi

Prosesor Pesan 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. Mengupgrade server backend agar mendukung protokol TLSv1.2. Ini adalah solusi yang direkomendasikan karena protokol TLSv1.2 lebih aman.
2. Jika Anda tidak dapat mengupgrade server backend dengan segera karena alasan tertentu, Anda dapat memaksa Message Processor 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 ini:

      <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.

Ketidakcocokan Cipher

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

Diagnosis

1. Tentukan apakah error terjadi di koneksi northbound atau southbound. Untuk panduan lebih lanjut terkait 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 koneksi utara) atau Pemroses Pesan (untuk koneksi keluar atau arah selatan). Server dapat berupa Router Edge (untuk koneksi masuk atau ke utara) atau server backend (untuk koneksi keluar atau arah 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 ke utara) atau server backend (untuk koneksi keluar atau menuju selatan), karena Anda tidak memiliki akses ke Router Edge atau Pemroses Pesan.

   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 ketahui.
4. Berikut adalah contoh analisis output tcpdump menggunakan Wireshark:
   • Dalam contoh ini, kegagalan Handshake TLS/SSL terjadi antara aplikasi Klien dan router Edge (koneksi utara). Output tcpdump dikumpulkan di router Edge.

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

     

   • Jika pesan Client Hello dipilih, aplikasi klien akan menggunakan protokol TLSv1.2.

     

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

     • Namun, router Edge tetap mengirimkan Peringatan Fatal: Handshake Failure ke aplikasi klien seperti yang ditunjukkan pada screenshot di bawah:

       

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

     

   • Daftar algoritma cipher suite yang didukung oleh Router Edge 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 mana pun. Ketidakcocokan ini menyebabkan kegagalan handshake TLS/SSL.
   • Karena Router Edge mendukung SNI, scroll ke bawah ke pesan #4 di output tcpdump dan pastikan bahwa 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 telah terjadi karena algoritma cipher suite yang digunakan oleh aplikasi klien tidak didukung oleh Router Edge.

Resolusi

Anda harus memastikan bahwa klien menggunakan algoritma cipher suite yang didukung oleh server. Untuk mengatasi masalah yang dijelaskan di bagian Diagnosis 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 dalam keystore/truststore, baik saat koneksi masuk (arah utara) atau keluar (batas selatan) di Apigee Edge. Lihat juga Memahami koneksi arah utara dan selatan.

Jika masalahnya berada di arah utara, Anda mungkin akan melihat pesan error yang berbeda bergantung pada penyebab utamanya.

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

Pesan error

Anda mungkin melihat pesan error yang berbeda, 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 untuk masalah ini adalah:

Cause	Deskripsi	Siapa yang dapat melakukan langkah-langkah pemecahan masalah
Ketidakcocokan Nama Host	Nama host yang digunakan di URL dan sertifikat di keystore router tidak cocok. Misalnya, ketidakcocokan terjadi jika nama host yang digunakan dalam URL adalah myorg.domain.com, sedangkan sertifikat memiliki nama host di CN-nya sebagai CN=something.domain.com.	Pengguna Cloud Pribadi dan Publik Edge
Rantai sertifikat Tidak Lengkap atau Salah	Rantai sertifikat tidak lengkap atau salah.	Khusus pengguna Edge Private dan Public Cloud
Sertifikat yang dikirim oleh server atau klien tidak diketahui atau habis masa berlakunya	Sertifikat yang habis masa berlakunya atau tidak diketahui dikirim oleh server atau klien di arah utara atau koneksi arah selatan.	Pengguna Edge Private Cloud dan Edge Public Cloud

Nama host Tidak Cocok

Diagnosis

1. Perhatikan nama host yang digunakan di URL yang ditampilkan oleh panggilan Edge management API berikut:

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

   Misalnya:

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

2. Dapatkan CN yang digunakan dalam sertifikat yang disimpan di keystore tertentu. Anda dapat menggunakan API pengelolaan Edge 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) dari CN subjek yang memiliki sertifikat karakter pengganti, 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 subjek CN yang sudah 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 API pengelolaan Edge 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 bahwa sertifikat tersebut mematuhi panduan yang diberikan dalam artikel Cara kerja rantai sertifikat untuk memastikan sertifikat tersebut valid dan lengkap rantai sertifikat. Jika rantai sertifikat yang disimpan di keystore tidak lengkap atau tidak valid, Anda akan melihat kegagalan handshake TLS/SSL.
   4. Grahpic berikut menunjukkan contoh sertifikat dengan rantai sertifikat yang tidak valid, dengan intermediate dan root certificate tidak cocok:

   Contoh intermediate dan root certificate jika penerbit dan subjek tidak cocok

   
   

Resolusi

1. Dapatkan sertifikat (jika Anda belum memilikinya) yang berisi 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 dikirim oleh server atau klien tidak berlaku atau tidak diketahui

Jika sertifikat yang salah/habis masa berlakunya dikirim oleh server/klien di koneksi arah utara atau selatan, maka pihak satunya (server/klien) akan menolak sertifikat yang menyebabkan kegagalan handshake TLS/SSL.

Diagnosis

1. Tentukan apakah error terjadi di koneksi northbound atau southbound. Untuk panduan lebih lanjut terkait 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 koneksi utara) atau Pemroses Pesan (untuk koneksi keluar atau arah selatan). Server dapat berupa Router Edge (untuk koneksi masuk atau ke utara) atau server backend (untuk koneksi keluar atau arah 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 ke utara) atau server backend (untuk koneksi keluar atau menuju selatan), karena Anda tidak memiliki akses ke Router Edge atau Pemroses Pesan.

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

   Lihat data tcpdump untuk mengetahui informasi selengkapnya tentang penggunaan perintah tcpdump.
3. Lakukan analisis data tcpdump menggunakan Wireshark atau alat yang 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 lain dari output tcpdump, asalkan data tidak dienkripsi. Hal ini akan berguna untuk dibandingkan apakah sertifikat ini cocok dengan sertifikat yang tersedia di truststore.
6. Tinjau contoh tcpdump untuk komunikasi SSL antara Pemroses Pesan dan server backend.

   Contoh tcpdump yang menampilkan error Certificate Unknown

   
   

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

      
      

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

      

   8. Sertifikat server backend dan rantai lengkapnya tersedia di bawah bagian "Sertifikat", seperti ditunjukkan dalam gambar di atas.
7. Jika sertifikat diketahui tidak diketahui oleh Router (arah utara) atau Pemroses Pesan (batas selatan) seperti dalam contoh yang digambarkan di atas, ikuti langkah-langkah berikut:
   1. Mendapatkan sertifikat dan rantainya yang disimpan di truststore tertentu. (Lihat konfigurasi host virtual untuk konfigurasi Router dan endpoint target untuk Pemroses Pesan). Anda dapat menggunakan API berikut untuk mendapatkan detail sertifikat:
      1. Dapatkan 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 (arah utara) atau Pemroses Pesan (batas selatan) cocok dengan sertifikat yang disimpan di keystore aplikasi klien (arah utara) atau server target (batas selatan), atau sertifikat yang diperoleh dari output tcpdump. Jika ada ketidakcocokan, maka itulah penyebab kegagalan handshake TLS/SSL.
8. Jika sertifikat diketahui tidak diketahui oleh aplikasi klien (arah utara) atau server target (batas selatan), ikuti langkah-langkah berikut:
   1. Dapatkan rantai sertifikat lengkap yang digunakan dalam sertifikat yang disimpan di keystore tertentu. (Lihat konfigurasi host virtual untuk konfigurasi Router dan endpoint target untuk Pemroses Pesan.) Anda dapat menggunakan API berikut untuk mendapatkan detail sertifikat:
      1. Dapatkan 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 dalam keystore Router (arah utara) atau Pemroses Pesan (batas selatan) cocok dengan sertifikat yang disimpan di truststore aplikasi klien (arah utara) atau server target (batas selatan), atau yang diperoleh dari output tcpdump. Jika ada ketidakcocokan, maka itulah penyebab kegagalan handshake SSL.
9. Jika sertifikat yang dikirim oleh server/klien diketahui telah habis masa berlakunya, klien/server penerima akan menolak sertifikat tersebut dan Anda akan melihat pesan pemberitahuan berikut di tcpdump:

   Peringatan (Level: Fatal, Deskripsi: Sertifikat sudah tidak berlaku)

10. Verifikasi bahwa sertifikat di keystore host yang sesuai sudah tidak berlaku.

Resolusi

Untuk menyelesaikan masalah yang diidentifikasi dalam contoh di atas, upload sertifikat server backend yang valid ke wali pada Pemroses Pesan.

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

Cause	Deskripsi	Resolusi
Sertifikat yang Habis Masa Berlakunya	NorthBound Sertifikat yang disimpan di keystore router sudah tidak berlaku. Sertifikat yang disimpan di keystore aplikasi klien sudah tidak berlaku (SSL 2 arah).	Upload sertifikat baru dan rantai lengkapnya ke keystore di host yang sesuai.
	SouthBound Sertifikat yang disimpan di keystore Server Target sudah tidak berlaku. Masa berlaku sertifikat yang disimpan di keystore Pemroses Pesan sudah berakhir (SSL 2 arah).	Upload sertifikat baru dan rantai lengkapnya ke keystore di host yang sesuai.
Sertifikat Tidak Dikenal	NorthBound Sertifikat yang disimpan di truststore aplikasi klien tidak cocok dengan sertifikat Router. Sertifikat yang disimpan di truststore router tidak cocok dengan sertifikat aplikasi klien (SSL 2 arah).	Upload sertifikat yang valid ke truststore di host yang sesuai.
	SouthBound Sertifikat yang disimpan di truststore server target tidak cocok dengan sertifikat Pemroses Pesan. Sertifikat yang disimpan di truststore Pemroses Pesan tidak cocok dengan sertifikat server target (SSL 2 arah).	Upload sertifikat yang valid ke truststore di host yang sesuai.

Server yang Diaktifkan oleh SNI

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

Pertama, Anda perlu mengidentifikasi nama host dan nomor port server yang digunakan dan memeriksa apakah SNI diaktifkan 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 melihat kegagalan handshake dalam perintah openssl, seperti yang ditunjukkan di bawah ini:
   

   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 ini:

   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, ini menunjukkan bahwa Server yang ditentukan telah mengaktifkan SNI.

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

Diagnosis

1. Tentukan apakah error terjadi di koneksi northbound atau southbound. Untuk panduan lebih lanjut terkait 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 koneksi utara) atau Pemroses Pesan (untuk koneksi keluar atau arah selatan). Server dapat berupa Router Edge (untuk koneksi masuk atau ke utara) atau server backend (untuk koneksi keluar atau arah 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 ke utara) atau server backend (untuk koneksi keluar atau menuju selatan), karena Anda tidak memiliki akses ke Router Edge atau Pemroses Pesan.

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

   Lihat data tcpdump untuk mengetahui informasi selengkapnya tentang penggunaan perintah tcpdump.
3. Lakukan analisis output tcpdump menggunakan Wireshark atau alat yang serupa.
4. Berikut ini contoh analisis tcpdump menggunakan Wireshark:
   1. Dalam contoh ini, kegagalan handshake TLS/SSL terjadi antara Pemroses Pesan Edge dan server backend (koneksi 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" akan menunjukkan bahwa Pemroses Pesan menggunakan protokol TLSv1.2.

      

   4. Pesan #4 menunjukkan bahwa server backend mengonfirmasi pesan "Client Hello" dari Pemroses Pesan.
   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 tersebut cocok antara Pemroses Pesan dan server backend.
      • Namun, server backend masih mengirimkan Fatal Alert: Handshake Failure ke Pemroses Pesan seperti yang ditunjukkan pada gambar di bawah:

        

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

      

   9. Hal ini mengonfirmasi bahwa Pemroses Pesan tidak mengirim server_name ke server backend yang mendukung SNI.
   10. Hal ini menyebabkan kegagalan handshake TLS/SSL dan merupakan alasan server backend mengirim Fatal Alert: Handshake Failure ke Pemroses Pesan.
5. Verifikasi bahwa jsse.enableSNIExtension property dalam system.properties disetel ke salah (false) pada 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 dalam file ini: conf_system_jsse.enableSNIExtension=true
3. Pilih pemilik file ini ke 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 sampai #4 pada semua Pemroses Pesan.

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