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

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 tautan terenkripsi antara server web dan klien web, seperti {i>browser<i} atau aplikasi. Handshake adalah proses yang memungkinkan klien dan server TLS/SSL menetapkan serangkaian rahasia kunci yang dapat mereka gunakan 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 bertukar dan memvalidasi sertifikat digital.

Jika handshake TLS/SSL berhasil, klien dan server TLS/SSL akan mentransfer data ke masing-masing lainnya dengan aman. Sebaliknya, jika kegagalan handshake TLS/SSL terjadi, koneksi akan dihentikan dan klien menerima error 503 Service Unavailable.

Kemungkinan penyebab kegagalan handshake TLS/SSL adalah:

Protokol Ketidakcocokan

Kegagalan handshake TLS/SSL terjadi jika protokol yang digunakan oleh klien tidak didukung oleh server baik pada koneksi masuk (arah utara) atau keluar ({i>outhbound<i}). Lihat juga Memahami koneksi arah utara dan selatan.

Diagnosis

1. Tentukan apakah error terjadi di arah utara atau southbound. Untuk panduan lebih lanjut tentang cara membuat tekad, lihat Menentukan sumber masalah.
2. Jalankan utilitas tcpdump untuk mengumpulkan informasi lebih lanjut:
   • Jika Anda adalah pengguna Private Cloud, maka Anda dapat mengumpulkan tcpdump data pada klien atau server yang relevan. Klien dapat berupa aplikasi klien (untuk koneksi masuk, atau koneksi ke arah utara) atau paket Message Pemroses (untuk koneksi keluar atau selatan). Server dapat berupa {i>Router<i} Edge (pada koneksi masuk, atau utara) atau server backend (untuk koneksi keluar, atau selatan) berdasarkan penentuan Anda dari Langkah 1.
   • Jika Anda adalah pengguna Cloud Publik, maka Anda dapat mengumpulkan tcpdump data hanya pada aplikasi klien (untuk koneksi masuk, atau menuju utara) atau server backend (untuk koneksi keluar, atau 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 informasi selengkapnya tentang penggunaan tcpdump perintah.
3. Menganalisis data tcpdump menggunakan alat Wireshark atau alat serupa.
4. Berikut adalah contoh analisis dari 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 ini menunjukkan bahwa Pemroses Pesan (Sumber) mengirim "Klien Halo" ke server backend (Destination).
     

     

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

     

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

   • Melihat lebih jauh ke pesan #6 menunjukkan bahwa penyebab kegagalan handshake TLS/SSL adalah 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 Beri tahu.

Resolusi

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

1. Upgrade server backend Anda untuk mendukung protokol TLSv1.2. Ini adalah solusi yang direkomendasikan sebagai protokol TLSv1.2 lebih aman.
2. Jika Anda tidak dapat segera mengupgrade server backend karena beberapa alasan, Anda dapat memaksa Prosesor 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, setel elemen Protocol menjadi 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 Anda, lalu gunakan API pengelolaan ini untuk menetapkan protokol ke TLSv1.0 di bagian konfigurasi server target.

Ketidakcocokan Cipher

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

Diagnosis

1. Menentukan apakah kesalahan terjadi pada koneksi arah utara atau arah selatan. Untuk panduan lebih lanjut terkait cara melakukan penentuan ini, lihat Menentukan sumber masalah.
2. Jalankan utilitas tcpdump untuk mengumpulkan informasi lebih lanjut:
   • Jika Anda adalah pengguna Private Cloud, maka Anda dapat mengumpulkan tcpdump data pada klien atau server yang relevan. Klien dapat berupa aplikasi klien (untuk koneksi masuk, atau koneksi ke arah utara) atau paket Message Pemroses (untuk koneksi keluar atau selatan). Server dapat berupa {i>Router<i} Edge (pada koneksi masuk, atau utara) atau server backend (untuk koneksi keluar, atau selatan) berdasarkan penentuan Anda dari Langkah 1.
   • Jika Anda adalah pengguna Cloud Publik, maka Anda dapat mengumpulkan tcpdump data hanya pada aplikasi klien (untuk koneksi masuk, atau menuju utara) atau server backend (untuk koneksi keluar, atau 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 informasi selengkapnya tentang penggunaan perintah tcpdump.
3. Menganalisis data tcpdump menggunakan alat Wireshark atau alat lain yang Anda kenal.
4. Berikut adalah contoh analisis output tcpdump menggunakan Wireshark:
   • Dalam contoh ini, kegagalan Handshake TLS/SSL terjadi antara aplikasi Klien dan Router edge (koneksi menuju utara). Output tcpdump dikumpulkan di Edge {i>router<i} tambahan.

   • Pesan #4 dalam output tcpdump di bawah ini menunjukkan bahwa aplikasi klien (sumber) mengirim "Klien Halo" ke Router Edge (tujuan).

     

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

     

   • Pesan #5 menunjukkan bahwa Router Edge mengonfirmasi "Client Hello" pesan dari aplikasi klien.
   • Router Edge segera mengirimkan Peringatan Fatal : Kegagalan Handshake ke aplikasi klien (pesan #6). Ini berarti handshake TLS/SSL gagal dan koneksi akan ditutup.
   • Melihat lebih lanjut pesan #6 akan menampilkan informasi berikut:
     • Edge Router mendukung protokol TLSv1.2. Ini berarti bahwa protokol tersebut cocok dengan antara aplikasi klien dan Router Edge.

     • Namun, router Edge masih mengirimkan Peringatan Fatal: Berjabatan Gagal pada 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 Router Edge.
     • Router Edge telah mengaktifkan SNI, tetapi aplikasi klien tidak mengirimkan nama server.
   • Pesan #4 dalam output tcpdump mencantumkan algoritma cipher suite yang didukung oleh klien aplikasi, seperti yang ditunjukkan di bawah ini:

     

   • Daftar algoritma cipher suite yang didukung oleh Edge Router tercantum dalam File /opt/nginx/conf.d/0-default.conf. Dalam contoh ini, Router Edge hanya mendukung algoritma cipher suite Enkripsi Tinggi.
   • Aplikasi klien tidak menggunakan algoritma cipher suite Enkripsi Tinggi apa pun. Ketidakcocokan ini adalah penyebab Kegagalan handshake TLS/SSL.
   • Karena Router Edge mendukung SNI, scroll ke bawah ke pesan #4 dalam output tcpdump dan mengkonfirmasi bahwa aplikasi klien mengirimkan nama server dengan benar, seperti ditunjukkan dalam gambar di bawah ini:
     
     
     
   • 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 Router Edge.

Resolusi

Anda harus memastikan bahwa klien menggunakan algoritma cipher suite yang didukung oleh server. Untuk mengatasi masalah yang dijelaskan di atas bagian diagnosis, download dan instal Java Cryptography Extension (JCE) dan menyertakannya dalam paket 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 pada koneksi masuk (arah utara) atau keluar (tujuh) di Apigee Edge. Lihat juga Memahami koneksi arah utara dan selatan.

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

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

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:

Nama host Ketidakcocokan

Diagnosis

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

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

   Contoh:

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

2. Minta 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 digunakan dalam URL permintaan API (lihat langkah#1 di atas) dan 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) yang subjek CN memiliki karakter pengganti sertifikat, lalu mengunggah 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 file lengkap rantai sertifikat ke keystore.

Referensi

Keystore dan Truststores

Rantai sertifikat yang tidak lengkap atau salah

Diagnosis

1. Minta 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 verifikasi bahwa sertifikat tersebut mematuhinya dengan panduan yang diberikan dalam artikel Cara kerja rantai sertifikat untuk memastikannya valid dan lengkap dalam rantai sertifikat. Jika rantai sertifikat yang disimpan di keystore tidak lengkap atau tidak valid, maka Anda melihat handshake TLS/SSL gagal.
   4. Grahpic berikut menunjukkan contoh sertifikat dengan rantai sertifikat yang tidak valid, jika intermediate certificate dan root certificate tidak cocok:

   Contoh intermediate dan root certificate tempat penerbit dan subjek tidak cocok

   
   

Resolusi

1. Dapatkan sertifikat (jika Anda belum memilikinya) yang menyertakan sertifikat lengkap dan valid dalam rantai sertifikat.
2. Jalankan perintah openssl berikut untuk memastikan rantai sertifikat sudah benar dan selesai:

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

3. Upload rantai sertifikat yang divalidasi ke keystore.

Sudah tidak berlaku atau tidak diketahui sertifikat yang dikirim oleh server atau klien

Jika sertifikat yang salah/sudah tidak berlaku dikirim oleh server/klien baik di jalur utara atau di koneksi arah selatan, maka pihak lainnya (server/klien) akan menolak sertifikat yang menyebabkan kegagalan handshake TLS/SSL.

Diagnosis

1. Tentukan apakah error terjadi di arah utara atau southbound. Untuk panduan lebih lanjut tentang cara membuat tekad, lihat Menentukan sumber masalah.
2. Jalankan utilitas tcpdump untuk mengumpulkan informasi lebih lanjut:
   • Jika Anda adalah pengguna Private Cloud, maka Anda dapat mengumpulkan tcpdump data pada klien atau server yang relevan. Klien dapat berupa aplikasi klien (untuk koneksi masuk, atau koneksi ke arah utara) atau paket Message Pemroses (untuk koneksi keluar atau selatan). Server dapat berupa {i>Router<i} Edge (pada koneksi masuk, atau utara) atau server backend (untuk koneksi keluar, atau selatan) berdasarkan penentuan Anda dari Langkah 1.
   • Jika Anda adalah pengguna Cloud Publik, maka Anda dapat mengumpulkan tcpdump data hanya pada aplikasi klien (untuk koneksi masuk, atau menuju utara) atau server backend (untuk koneksi keluar, atau 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 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 tahap verifikasi.
5. Anda bisa mengambil sertifikat yang dikirim dari ujung lain dari output tcpdump, asalkan data tidak dienkripsi. Ini akan berguna untuk membandingkan 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 menunjukkan error Certificate Unknown

   
   

   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 memvalidasi protokol dan algoritma cipher suite yang digunakan.
   4. Server backend mengirim pesan {i>Certificate <i}dan {i>Server Hello Done<i} ke Pemroses Pesan dalam pesan #68.
   5. Pemroses Pesan mengirimkan Pemberitahuan Fatal "Deskripsi: Sertifikat Tidak diketahui" dalam pesan #70.
   6. Melihat lebih jauh ke pesan #70, tidak ada detail tambahan lainnya daripada pesan peringatan seperti yang ditampilkan di bawah ini:

      
      

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

      

   8. Sertifikat server backend dan rantai lengkapnya tersedia di bawah "Sertifikat" , seperti yang ditampilkan dalam gambar di atas.
7. Jika sertifikat diketahui tidak diketahui, baik oleh {i>Router<i} (ke arah utara) atau Pemroses Pesan (southbound) seperti pada contoh yang diilustrasikan di atas, kemudian ikuti langkah:
   1. Dapatkan sertifikat dan rantainya yang disimpan di truststore tertentu. (Silakan merujuk ke konfigurasi {i>host<i} virtual untuk {i>Router<i} dan konfigurasi endpoint target untuk Message Processor). Anda bisa 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 disimpan di truststore Router (arah utara) atau Pemroses Pesan (southbound) cocok dengan sertifikat yang disimpan di keystore aplikasi klien (arah utara) atau server target (selatan), atau kunci yang diperoleh dari output tcpdump. Jika ada ketidakcocokan, maka itulah penyebab kegagalan handshake TLS/SSL.
8. Jika sertifikat diketahui tidak diketahui oleh aplikasi klien (ke arah utara) atau server target (ke arah selatan), lalu ikuti langkah-langkah berikut:
   1. Dapatkan rantai sertifikat lengkap yang digunakan dalam sertifikat yang disimpan dalam direktori keystore. (Lihat konfigurasi host virtual untuk Router dan endpoint target untuk Pemroses Pesan.) Anda bisa 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 disimpan di keystore Router (arah utara) atau Pemroses Pesan (southbound) cocok dengan sertifikat yang disimpan di truststore milik aplikasi klien (arah utara) atau server target (ke selatan), atau yang yang diperoleh dari output tcpdump. Jika ada ketidakcocokan, maka itulah penyebab SSL kegagalan handshake.
9. Jika sertifikat yang dikirim oleh server/klien didapati telah kedaluwarsa, maka klien/server menolak sertifikat dan Anda akan melihat pesan peringatan berikut tcpdump:

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

10. Pastikan masa berlaku sertifikat dalam keystore host yang sesuai sudah berakhir.

Resolusi

Untuk mengatasi masalah yang diidentifikasi di contoh di atas, upload server backend yang valid sertifikat ke pengawas pada {i>Message Processor<i}.

Tabel berikut meringkas langkah-langkah untuk mengatasi masalah tersebut, bergantung pada penyebab masalah.

SNI Aktif Penskalaan otomatis

Kegagalan handshake TLS/SSL dapat terjadi saat klien berkomunikasi dengan Server Indikasi Nama (SNI) Aktif Server, tetapi klien tidak mengaktifkan SNI. Ini dapat terjadi baik di arah utara atau koneksi ke arah selatan di Edge.

Pertama, Anda perlu mengidentifikasi {i>host<i} dan nomor porta server yang digunakan dan periksa apakah apakah SNI-nya aktif atau tidak.

Identifikasi server dengan SNI aktif

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

   openssl s_client -connect hostname:port
   

   Anda mendapatkan sertifikat dan terkadang Anda mungkin mengamati kegagalan {i>handshake <i}di perintah openssl, seperti 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 {i>handshake <i}di langkah #1 atau mendapatkan sertifikat berbeda pada langkah #1 dan langkah #2, berarti Server tersebut telah mengaktifkan SNI.

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

Diagnosis

1. Tentukan apakah error terjadi di arah utara atau southbound. Untuk panduan lebih lanjut tentang cara membuat tekad, lihat Menentukan sumber masalah.
2. Jalankan utilitas tcpdump untuk mengumpulkan informasi lebih lanjut:
   • Jika Anda adalah pengguna Private Cloud, maka Anda dapat mengumpulkan tcpdump data pada klien atau server yang relevan. Klien dapat berupa aplikasi klien (untuk koneksi masuk, atau koneksi ke arah utara) atau paket Message Pemroses (untuk koneksi keluar atau selatan). Server dapat berupa {i>Router<i} Edge (pada koneksi masuk, atau utara) atau server backend (untuk koneksi keluar, atau selatan) berdasarkan penentuan Anda dari Langkah 1.
   • Jika Anda adalah pengguna Cloud Publik, maka Anda dapat mengumpulkan tcpdump data hanya pada aplikasi klien (untuk koneksi masuk, atau menuju utara) atau server backend (untuk koneksi keluar, atau 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 informasi selengkapnya tentang penggunaan perintah tcpdump.
3. Analisis output tcpdump menggunakan Wireshark atau alat serupa.
4. Berikut adalah contoh analisis tcpdump menggunakan Wireshark:
   1. Dalam contoh ini, kegagalan handshake TLS/SSL terjadi antara Pesan Edge Prosesor dan server backend (koneksi ke selatan).
   2. Pesan #4 dalam output tcpdump di bawah ini menunjukkan bahwa Pemroses Pesan (sumber) dikirim "Client Hello" ({i>Client Hello<i}) ke server backend (destination).

      

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

      

   4. Pesan #4 menunjukkan bahwa server backend menerima "Client Hello" pesan dari Pemroses Pesan.
   5. Server backend segera mengirimkan Peringatan Fatal : Handshake Kegagalan ke Pemroses Pesan (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. Ini berarti bahwa protokol cocok antara Pemroses Pesan dan server backend.
      • Namun, server backend masih mengirimkan Peringatan Fatal: Handshake Kegagalan pada Pemroses Pesan seperti yang ditunjukkan pada gambar di bawah:

        

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

      

   9. Ini mengkonfirmasi bahwa Pemroses Pesan tidak mengirim server_name ke server backend yang mendukung SNI.
   10. Ini adalah penyebab kegagalan handshake TLS/SSL dan alasan bahwa backend server mengirimkan pesan Fatal Alert: Handshake Failure ke Pesan Pemroses.
5. Verifikasi bahwa jsse.enableSNIExtension property di system.properties disetel ke false pada Pemroses Pesan untuk mengonfirmasi bahwa Pemroses Pesan tidak diaktifkan untuk berkomunikasi dengan server yang mengaktifkan SNI.

Resolusi

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

1. Membuat /opt/apigee/customer/application/message-processor.properties (jika belum ada).
2. Tambahkan baris berikut ke dalam file ini: conf_system_jsse.enableSNIExtension=true
3. Tag 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. Bila 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 Anda memerlukan bantuan lebih lanjut, hubungi Dukungan Apigee Edge. Bagikan detail lengkap tentang masalah tersebut beserta output tcpdump.