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:
- Setujui versi protokol yang akan digunakan.
- Pilih algoritma kriptografi yang akan digunakan.
- 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:
Cause | Deskripsi | Siapa yang dapat melakukan langkah-langkah pemecahan masalah |
---|---|---|
Ketidakcocokan protokol | 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 dalam sertifikat disimpan di ujung server. | Pengguna Cloud Pribadi dan Publik |
Rantai sertifikat yang tidak lengkap atau tidak valid akan disimpan di akhir klien atau server. | Pengguna Cloud Pribadi dan Publik | |
Sertifikat yang salah atau sudah tidak berlaku dikirim oleh klien ke server atau dari server kepada klien. | Pengguna Cloud Pribadi dan Publik | |
Server Dengan SNI | Server backend mengaktifkan Server Name Indication (SNI); Namun, 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 pada koneksi masuk (arah utara) atau keluar ({i>outhbound<i}). Lihat juga Memahami koneksi arah utara dan selatan.
Diagnosis
- Tentukan apakah error terjadi di arah utara atau southbound. Untuk panduan lebih lanjut tentang cara membuat tekad, lihat Menentukan sumber masalah.
- 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.
Lihat data tcpdump untuk informasi selengkapnya tentang penggunaantcpdump -i any -s 0 host IP address -w File name
tcpdump
perintah. - Jika Anda adalah pengguna Private Cloud, maka Anda dapat mengumpulkan
- Menganalisis data
tcpdump
menggunakan alat Wireshark atau alat serupa. - 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:
- Upgrade server backend Anda untuk mendukung protokol TLSv1.2. Ini adalah solusi yang direkomendasikan sebagai protokol TLSv1.2 lebih aman.
- 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:
- Jika Anda tidak menentukan server target dalam definisi TargetEndpoint proxy, setel
elemen
Protocol
menjadiTLSv1.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>
- Jika Anda mengonfigurasi server target untuk proxy Anda, lalu gunakan API pengelolaan ini untuk menetapkan protokol ke TLSv1.0 di bagian konfigurasi server target.
- Jika Anda tidak menentukan server target dalam definisi TargetEndpoint proxy, setel
elemen
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
- Menentukan apakah kesalahan terjadi pada koneksi arah utara atau arah selatan. Untuk panduan lebih lanjut terkait cara melakukan penentuan ini, lihat Menentukan sumber masalah.
- 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.
Lihat data tcpdump untuk informasi selengkapnya tentang penggunaan perintahtcpdump -i any -s 0 host IP address -w File name
tcpdump
. - Jika Anda adalah pengguna Private Cloud, maka Anda dapat mengumpulkan
- Menganalisis data
tcpdump
menggunakan alat Wireshark atau alat lain yang Anda kenal. - 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.
- Dalam contoh ini, kegagalan Handshake TLS/SSL terjadi antara aplikasi Klien dan
Router edge (koneksi menuju utara). Output
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:
Cause | Deskripsi | Siapa yang dapat melakukan langkah-langkah pemecahan masalah |
Ketidakcocokan Nama Host |
Nama host yang digunakan dalam URL dan sertifikat di keystore router tidak
yang cocok. Misalnya, ketidakcocokan terjadi jika nama host yang digunakan dalam URL adalah myorg.domain.com saat
sertifikat memiliki nama host di CN-nya sebagai CN=something.domain.com.
|
Pengguna Edge Private Cloud dan Public Cloud |
Sertifikat tidak lengkap atau Salah jaringan bisnis | Rantai sertifikat tidak lengkap atau salah. | Khusus pengguna Edge Private dan Public Cloud |
Sertifikat yang habis masa berlakunya atau tidak diketahui yang dikirim oleh server atau klien | Sertifikat yang kedaluwarsa atau tidak dikenal dikirim oleh server atau klien baik di arah utara atau di koneksi yang mengarah ke selatan. | Pengguna Edge Private Cloud dan Edge Public Cloud |
Nama host Ketidakcocokan
Diagnosis
- Perhatikan nama host yang digunakan di URL yang ditampilkan oleh panggilan API pengelolaan Edge berikut:
Contoh:curl -v https://myorg.domain.com/v1/getinfo
curl -v https://api.enterprise.apigee.com/v1/getinfo
- Minta CN yang digunakan dalam sertifikat yang disimpan di keystore tertentu. Anda dapat menggunakan
API pengelolaan Edge berikut untuk mendapatkan detail sertifikat:
-
Dapatkan nama sertifikat di keystore:
Jika Anda adalah pengguna Private Cloud, gunakan Management API sebagai berikut:
Jika Anda adalah pengguna Cloud Publik, gunakan Management API sebagai berikut:curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
-
Dapatkan detail sertifikat di keystore menggunakan Edge management API.
Jika Anda adalah pengguna Private Cloud:
Jika Anda adalah pengguna Cloud Publik:curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
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.
-
Dapatkan nama sertifikat di keystore:
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
Rantai sertifikat yang tidak lengkap atau salah
Diagnosis
- Minta CN yang digunakan dalam sertifikat yang disimpan di keystore tertentu. Anda dapat menggunakan
API pengelolaan Edge berikut untuk mendapatkan detail sertifikat:
-
Dapatkan nama sertifikat di keystore:
Jika Anda adalah pengguna Private Cloud:
Jika Anda adalah pengguna Cloud Publik:curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
-
Dapatkan detail sertifikat di keystore:
Jika Anda adalah pengguna Private Cloud:
Jika Anda adalah pengguna Cloud Publik:curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
- 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.
- 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
-
Dapatkan nama sertifikat di keystore:
Resolusi
- Dapatkan sertifikat (jika Anda belum memilikinya) yang menyertakan sertifikat lengkap dan valid dalam rantai sertifikat.
- Jalankan perintah openssl berikut untuk memastikan rantai sertifikat sudah benar dan
selesai:
openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert
- 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
- Tentukan apakah error terjadi di arah utara atau southbound. Untuk panduan lebih lanjut tentang cara membuat tekad, lihat Menentukan sumber masalah.
- 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.
Lihat data tcpdump untuk informasi selengkapnya tentang penggunaan perintahtcpdump -i any -s 0 host IP address -w File name
tcpdump
. - Jika Anda adalah pengguna Private Cloud, maka Anda dapat mengumpulkan
- Analisis data
tcpdump
menggunakan Wireshark atau alat serupa. - Dari output
tcpdump
, tentukan host (klien atau server) yang menolak sertifikat selama tahap verifikasi. - 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. - Tinjau contoh
tcpdump
untuk komunikasi SSL antara Pemroses Pesan dan server backend.Contoh
tcpdump
yang menunjukkan error Certificate Unknown
- Pemroses Pesan (klien) mengirim "Client Hello" ke server backend (server) dalam pesan #59.
- Server backend mengirim "Server Hello" ke Pemroses Pesan dalam pesan #61.
- Keduanya memvalidasi protokol dan algoritma cipher suite yang digunakan.
- Server backend mengirim pesan {i>Certificate <i}dan {i>Server Hello Done<i} ke Pemroses Pesan dalam pesan #68.
- Pemroses Pesan mengirimkan Pemberitahuan Fatal "Deskripsi: Sertifikat Tidak diketahui" dalam pesan #70.
- Melihat lebih jauh ke pesan #70, tidak ada detail tambahan lainnya
daripada pesan peringatan seperti yang ditampilkan di bawah ini:
- Tinjau pesan #68 untuk mendapatkan detail tentang sertifikat yang dikirim oleh backend server, seperti yang ditunjukkan dalam grafik berikut:
- Sertifikat server backend dan rantai lengkapnya tersedia di bawah "Sertifikat" , seperti yang ditampilkan dalam gambar di atas.
- 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:
- 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:
-
Dapatkan nama sertifikat di truststore:
curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs
-
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
-
Dapatkan nama sertifikat di truststore:
- 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.
- 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:
- Jika sertifikat diketahui tidak diketahui oleh aplikasi klien (ke arah utara)
atau server target (ke arah selatan), lalu ikuti langkah-langkah berikut:
- 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:
-
Dapatkan nama sertifikat di keystore:
curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
-
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
-
Dapatkan nama sertifikat di keystore:
- 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.
- 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:
- 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)
- 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.
Cause | Deskripsi | Resolusi |
Sertifikat Sudah Tidak Berlaku |
NorthBound
|
Upload sertifikat baru dan rantai lengkapnya ke keystore di {i>host<i}. |
SouthBound
|
Upload sertifikat baru dan rantai lengkapnya ke keystore di {i>host<i}. | |
Sertifikat Tidak Dikenal |
NorthBound
|
Upload sertifikat yang valid ke truststore pada host yang sesuai. |
SouthBound
|
Upload sertifikat yang valid ke truststore pada host yang sesuai. |
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
- 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: Anda mendapatkan sertifikat dan terkadang Anda mungkin mengamati kegagalan {i>handshake <i}di perintah openssl, seperti di bawah ini:openssl s_client -connect hostname:port
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
- 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
- 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
- Tentukan apakah error terjadi di arah utara atau southbound. Untuk panduan lebih lanjut tentang cara membuat tekad, lihat Menentukan sumber masalah.
- 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.
Lihat data tcpdump untuk informasi selengkapnya tentang penggunaan perintahtcpdump -i any -s 0 host IP address -w File name
tcpdump
. - Jika Anda adalah pengguna Private Cloud, maka Anda dapat mengumpulkan
- Analisis output
tcpdump
menggunakan Wireshark atau alat serupa. - Berikut adalah contoh analisis
tcpdump
menggunakan Wireshark:- Dalam contoh ini, kegagalan handshake TLS/SSL terjadi antara Pesan Edge Prosesor dan server backend (koneksi ke selatan).
- Pesan #4 dalam output
tcpdump
di bawah ini menunjukkan bahwa Pemroses Pesan (sumber) dikirim "Client Hello" ({i>Client Hello<i}) ke server backend (destination). - Memilih "Client Hello" menunjukkan bahwa Message Prosesor menggunakan protokol TLSv1.2.
- Pesan #4 menunjukkan bahwa server backend menerima "Client Hello" pesan dari Pemroses Pesan.
- Server backend segera mengirimkan Peringatan Fatal : Handshake Kegagalan ke Pemroses Pesan (pesan #5). Ini berarti handshake TLS/SSL gagal dan koneksi akan ditutup.
- 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:
- 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.
- Tinjau pesan #3 (Client Hello) dalam output
tcpdump
secara lebih mendetail. Perhatikan bahwa Ekstensi: server_name tidak ada, seperti yang ditampilkan di bawah ini: - Ini mengkonfirmasi bahwa Pemroses Pesan tidak mengirim server_name ke server backend yang mendukung SNI.
- Ini adalah penyebab kegagalan handshake TLS/SSL dan alasan bahwa backend server mengirimkan pesan Fatal Alert: Handshake Failure ke Pesan Pemroses.
- Verifikasi bahwa
jsse.enableSNIExtension property
disystem.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:
- Membuat
/opt/apigee/customer/application/message-processor.properties
(jika belum ada). - Tambahkan baris berikut ke dalam file ini:
conf_system_jsse.enableSNIExtension=true
- Tag pemilik file ini ke
apigee:apigee
:chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
- Mulai ulang Pemroses Pesan.
/opt/apigee/apigee-service/bin/apigee-service message-processor restart
- 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
.