Ringkasan tentang terminasi TLS dan end-to-end TLS dengan Application Gateway

Keamanan Lapisan Transportasi (TLS), sebelumnya dikenal sebagai Secure Sockets Layer (SSL), adalah teknologi keamanan standar untuk membuat tautan terenkripsi antara server web dan browser. Tautan ini memastikan bahwa semua data yang dilewatkan antara server web dan browser tetap privat dan terenkripsi. Gateway aplikasi mendukung penghentian TLS di gateway serta enkripsi TLS ujung ke ujung.

Penting

Mulai 31 Agustus 2025, semua klien dan server backend yang berinteraksi dengan Azure Application Gateway harus menggunakan Keamanan Lapisan Transportasi (TLS) 1.2 atau yang lebih tinggi, karena dukungan untuk TLS 1.0 dan 1.1 akan dihentikan.

Penghentian TLS

Application Gateway mendukung penghentian TLS di gateway, setelah itu lalu lintas biasanya mengalir tanpa dienkripsi ke server ujung belakang. Ada sejumlah keuntungan melakukan penghentian TLS di gateway aplikasi:

• Peningkatan performa - Performa terbesar yang dicapai saat melakukan dekripsi TLS adalah berjabat tangan awal. Untuk meningkatkan performa, server yang melakukan dekripsi menyimpan dalam cache ID sesi TLS dan mengelola tiket sesi TLS. Jika ini dilakukan di gateway aplikasi, semua permintaan dari klien yang sama dapat menggunakan nilai yang di-cache. Jika itu dilakukan di server backend, maka setiap kali permintaan klien masuk ke server yang berbeda, klien harus mengaauthenticate ulang. Penggunaan tiket TLS dapat membantu mengurangi masalah ini, tetapi tidak didukung oleh semua klien dan mungkin sulit untuk dikonfigurasi dan dikelola.
• Pemanfaatan server backend yang lebih baik - Pemrosesan SSL/TLS membutuhkan CPU yang tinggi, dan menjadi lebih intensif seiring dengan peningkatan ukuran kunci. Menghapus pekerjaan ini dari server ujung belakang memungkinkan mereka untuk fokus pada hal yang paling efisien, mengirimkan konten.
• Perutean cerdas – Dengan mendekripsi lalu lintas, gateway aplikasi memiliki akses ke konten permintaan, seperti header, URI, dan sebagainya, dan dapat menggunakan data ini untuk merutekan permintaan.
• Manajemen sertifikat – Sertifikat hanya perlu dibeli dan diinstal pada gateway aplikasi dan tidak semua server ujung belakang. Ini menghemat waktu dan uang.

Untuk mengonfigurasi penghentian TLS, sertifikat TLS/SSL harus ditambahkan ke pendengar. Hal ini memungkinkan Application Gateway untuk mendekripsi lalu lintas masuk dan mengenkripsi lalu lintas respons ke klien. Sertifikat yang diberikan ke Application Gateway harus dalam format Personal Information Exchange (PFX), yang berisi kunci privat dan publik. Algoritma PFX yang didukung tercantum di fungsi PFXImportCertStore.

Penting

Sertifikat pada listener memerlukan seluruh rantai sertifikat untuk diunggah (sertifikat akar dari CA, sertifikat perantara, dan sertifikat daun) untuk membangun rantai kepercayaan.

Catatan

Gateway aplikasi tidak menyediakan kemampuan apa pun untuk membuat sertifikat baru atau mengirim permintaan sertifikat ke otoritas sertifikasi.

Agar sambungan TLS berfungsi, Anda perlu memastikan bahwa sertifikat TLS/SSL memenuhi kondisi berikut:

• Tanggal dan waktu saat ini berada dalam rentang tanggal "Valid dari" dan "Valid hingga" pada sertifikat.
• Bahwa "Nama Umum" (CN) sertifikat cocok dengan header host dari permintaan. Misalnya, jika klien membuat permintaan ke https://www.contoso.com/, maka CN harus www.contoso.com.

Jika Anda memiliki kesalahan dengan nama umum sertifikat backend (CN), lihat panduan pemecahan masalah kami.

Sertifikat didukung untuk penghentian TLS

Gateway aplikasi mendukung jenis sertifikat berikut:

• Sertifikat CA (Otoritas Sertifikat): Sertifikat CA adalah sertifikat digital yang dikeluarkan oleh otoritas sertifikat (CA)
• Sertifikat EV (Extended Validation/Validasi Diperpanjang): Sertifikat EV adalah sertifikat yang sesuai dengan pedoman sertifikat standar industri. Ini akan mengubah bilah pencari browser menjadi hijau dan menerbitkan nama perusahaan juga.
• Sertifikat Wildcard: Sertifikat ini mendukung berbagai subdomain yang didasarkan pada *.site.com, di mana subdomain Anda akan menggantikan *. Namun, tidak mendukung site.com, jadi jika pengguna mengakses situs web Anda tanpa mengetik "www" di depannya, sertifikat wildcard tidak akan menutupinya.
• Sertifikat yang Ditandatangani Sendiri: Browser klien tidak mempercayai sertifikat ini dan akan memperingatkan pengguna bahwa sertifikat layanan virtual bukan bagian dari rantai kepercayaan. Sertifikat yang ditandatangani sendiri dapat digunakan untuk pengujian atau lingkungan di mana administrator mengontrol klien dan dapat dengan aman melewati pemberitahuan keamanan browser. Beban kerja produksi tidak boleh menggunakan sertifikat yang ditandatangani sendiri.

Untuk informasi lebih lanjut, lihat konfigurasi penghentian TLS dengan gateway aplikasi.

Ukuran sertifikat

Periksa bagian Batas Application Gateway untuk mengetahui ukuran sertifikat TLS/SSL maksimum yang didukung.

Enkripsi TLS ujung-ke-ujung

Anda mungkin tidak ingin komunikasi yang tidak terenkripsi ke server ujung belakang. Anda mungkin memiliki persyaratan keamanan, persyaratan kepatuhan, atau aplikasi hanya dapat menerima sambungan yang aman. Azure Application Gateway memiliki enkripsi TLS ujung ke ujung untuk mendukung persyaratan ini.

TLS ujung ke ujung mengizinkan Anda mengenkripsi dan mengirimkan data sensitif dengan aman ke ujung belakang saat Anda menggunakan fitur penyeimbang muatan Lapisan-7 dari Application Gateway. Fitur ini mencakup afinitas sesi berbasis cookie, perutean berbasis URL, dukungan untuk perutean berdasarkan situs, kemampuan untuk menulis ulang atau memasukkan header X-Forwarded-*, dan sebagainya.

Saat dikonfigurasi dengan mode komunikasi TLS ujung ke ujung, Application Gateway menghentikan sesi TLS di gateway dan mendekripsi lalu lintas pengguna. Kemudian menerapkan aturan yang dikonfigurasi untuk memilih instans backend pool yang sesuai untuk merutekan lalu lintas. Application Gateway kemudian memulai sambungan TLS baru ke server backend dan mengenkripsi kembali data menggunakan sertifikat kunci publik server backend sebelum mengirimkan permintaan ke server backend. Setiap respons dari server web melalui proses yang sama kembali ke pengguna akhir. TLS ujung ke ujung diaktifkan dengan mengatur pengaturan protokol di Backend HTTP Setting ke HTTPS, yang kemudian diterapkan ke pool backend.

Pada gateway SKU Application Gateway v1, kebijakan TLS menerapkan versi TLS hanya untuk lalu lintas frontend dan cipher yang ditentukan untuk target frontend dan backend. Di Application Gateway v2 SKU, kebijakan TLS hanya berlaku untuk lalu lintas frontend. Koneksi TLS backend selalu dinegosiasikan menggunakan TLS 1.3, dan jika tidak tersedia, kembali ke TLS 1.2.

Application Gateway hanya berkomunikasi dengan server backend yang telah meletakkan sertifikat mereka dalam daftar putih dengan Application Gateway atau yang sertifikatnya ditandatangani oleh otoritas Sertifikasi (CA) yang terkenal dan CN dari sertifikat tersebut cocok dengan nama host pada pengaturan backend HTTP. Ini termasuk layanan Azure tepercaya seperti Azure App Service/Web Apps dan Azure API Management.

Jika sertifikat anggota di kumpulan backend tidak ditandatangani oleh otoritas CA terkenal, maka setiap instans di kumpulan backend dengan TLS end to end diaktifkan harus dikonfigurasi dengan sertifikat untuk memungkinkan komunikasi yang aman. Penambahan sertifikat memastikan bahwa gateway aplikasi hanya berkomunikasi dengan instans backend yang diketahui. Ini semakin mengamankan komunikasi ujung ke ujung.

Catatan

Sertifikat yang ditambahkan ke Pengaturan HTTP Ujung Belakang untuk mengautentikasi server ujung belakang dapat sama dengan sertifikat yang ditambahkan ke pendengar untuk penghentian TLS di gateway aplikasi atau berbeda untuk keamanan yang ditingkatkan.

Dalam contoh ini, permintaan yang menggunakan TLS1.2 dirutekan ke server ujung belakang di Pool1 menggunakan TLS ujung ke ujung.

TLS ujung ke ujung dan perizinan pendaftaran sertifikat

Application Gateway hanya berkomunikasi dengan server backend yang telah meletakkan sertifikat mereka dalam daftar putih dengan Application Gateway atau yang sertifikatnya ditandatangani oleh otoritas Sertifikasi (CA) yang terkenal dan CN dari sertifikat tersebut cocok dengan nama host pada pengaturan backend HTTP. Ada beberapa perbedaan dalam proses pengaturan TLS ujung ke ujung sehubungan dengan versi Application Gateway yang digunakan. Bagian berikut menjelaskan versi satu per satu.

Protokol end-to-end TLS dengan SKU v1

Untuk mengaktifkan TLS ujung ke ujung dengan server backend dan agar Application Gateway dapat merutekan permintaan ke mereka, pemeriksaan kesehatan harus berhasil dan mengembalikan respons positif.

Untuk pemeriksaan kesehatan HTTPS, Application Gateway v1 SKU menggunakan sertifikat autentikasi yang sama persis (kunci publik dari sertifikat server ujung belakang dan bukan sertifikat akar) untuk diunggah ke pengaturan HTTP.

Hanya sambungan ke backend yang diketahui dan diizinkan yang diperbolehkan. Ujung belakang yang tersisa dianggap tidak sehat oleh pemeriksaan kesehatan. Sertifikat yang ditandatangani sendiri hanya untuk tujuan pengujian dan tidak direkomendasikan untuk beban kerja produksi. Sertifikat tersebut harus diizinkan terdaftar dengan gateway aplikasi seperti yang dijelaskan dalam langkah-langkah sebelumnya sebelum dapat digunakan.

Catatan

Autentikasi dan penyiapan sertifikat akar tepercaya tidak diperlukan untuk layanan Azure tepercaya seperti Azure App Service. Mereka dianggap tepercaya secara default.

TLS dari ujung ke ujung dengan SKU v2

Sertifikat Autentikasi sudah tidak digunakan dan digantikan oleh Sertifikat Akar Tepercaya di Application Gateway SKU v2. Fungsi mereka mirip dengan Sertifikat Autentikasi dengan beberapa perbedaan utama:

• Sertifikat yang ditandatangani oleh otoritas CA terkenal yang CN-nya cocok dengan nama host di pengaturan backend HTTP tidak memerlukan langkah tambahan agar TLS end to end berfungsi.

  Misalnya, jika sertifikat ujung belakang dikeluarkan oleh CA terkenal dan memiliki CN contoso.com, dan bidang host pengaturan http ujung belakang juga diatur ke contoso.com, maka tidak ada langkah tambahan yang diperlukan. Anda dapat mengatur pengaturan protokol HTTP backend ke HTTPS, dan pemeriksaan kesehatan, serta jalur data, akan diaktifkan dengan TLS. Jika Anda menggunakan Azure App Service atau layanan web Azure lainnya sebagai backend Anda, maka layanan ini juga dipercaya secara implisit dan tidak ada langkah lebih lanjut yang diperlukan untuk TLS end-to-end.

Catatan

Agar sertifikat TLS/SSL dapat dipercaya, sertifikat server belakang tersebut harus diterbitkan oleh Otoritas Sertifikat (CA) yang terkenal. Jika sertifikat tidak diterbitkan oleh CA tepercaya, gateway aplikasi kemudian akan memeriksa untuk melihat apakah sertifikat CA penerbit dikeluarkan oleh CA tepercaya, dan seterusnya hingga CA tepercaya ditemukan (pada saat itu sambungan aman yang tepercaya akan dibuat) atau tidak ada CA tepercaya yang dapat ditemukan (pada saat itu gateway aplikasi akan menandai backend tidak sehat). Oleh karena itu, sebaiknya sertifikat server backend berisi CA root dan intermediate.

• Jika sertifikat server ujung belakang ditandatangani sendiri, atau ditandatangani oleh CA/perantara yang tidak dikenal, maka sertifikat akar tepercaya harus diunggah untuk mengaktifkan TLS ujung ke ujung di Application Gateway v2. Application Gateway hanya akan berkomunikasi dengan backend yang sertifikat root dari sertifikat servernya cocok dengan salah satu daftar sertifikat root tepercaya di pengaturan http backend yang terkait dengan kumpulan tersebut.

• Selain kecocokan sertifikat akar, Application Gateway v2 juga memvalidasi jika pengaturan Host yang ditentukan di pengaturan http ujung belakang cocok dengan nama umum (CN) yang diberikan oleh sertifikat TLS/SSL server ujung belakang. Saat mencoba membuat sambungan TLS ke backend, Application Gateway v2 mengatur ekstensi Indikasi Nama Server (SNI) ke host yang ditentukan dalam pengaturan http backend.

• Jika pilih hostname dari target backend dipilih alih-alih bidang Host dalam pengaturan http backend, maka header SNI selalu diatur ke FQDN kumpulan backend dan CN pada sertifikat TLS/SSL server backend harus sesuai dengan FQDN-nya. Anggota backend dengan IP tidak didukung dalam skenario ini.

• Sertifikat akar adalah sertifikat akar yang telah dikodekan dalam base64 dari sertifikat server backend.

Perbedaan SNI pada SKU v1 dan v2

Seperti yang disebutkan sebelumnya, Application Gateway menghentikan lalu lintas TLS dari klien di Application Gateway Listener (sebut saja sambungan ujung depan), mendekripsi lalu lintas, menerapkan aturan yang diperlukan untuk menentukan server ujung belakang tempat permintaan harus diteruskan, dan menetapkan sesi TLS baru dengan server ujung belakang (sebut saja sambungan ujung belakang).

Tabel berikut memberikan garis luar perbedaan SNI antara SKU v1 dan v2 dalam hal sambungan ujung depan dan belakang.

Sambungan TLS ujung depan (klien ke gateway aplikasi)

Skenario	v1	v2
Jika klien menentukan header SNI dan semua pendengar multi-situs diaktifkan dengan tanda "Memerlukan SNI"	Mengembalikan sertifikat yang sesuai dan jika situs tidak ada (sesuai dengan server_name), koneksi diatur ulang.	Mengembalikan sertifikat yang sesuai jika tersedia, jika tidak, mengembalikan sertifikat pendengar HTTPS pertama sesuai dengan urutan yang ditentukan oleh aturan perutean permintaan yang terkait dengan pendengar HTTPS
Jika klien tidak menentukan header SNI dan jika semua header multi-situs diaktifkan dengan "Memerlukan SNI"	Atur ulang sambungannya	Mengembalikan sertifikat pendengar HTTPS pertama sesuai dengan urutan yang ditentukan oleh aturan perutean permintaan yang terkait dengan pendengar HTTPS
Jika klien tidak menentukan header SNI dan ada pendengar bawaan yang dikonfigurasi dengan sertifikat	Kembalikan sertifikat yang dikonfigurasi di pendengar dasar ke klien (sertifikat default atau fallback)	Mengembalikan sertifikat pendengar HTTPS dengan aturan perutean prioritas tertinggi. Sertifikat pendengar dasar tidak digunakan sebagai cadangan.

Penting

Perilaku sertifikat default SKU V2: Saat klien tersambung tanpa header SNI (misalnya, menggunakan alamat IP), Application Gateway V2 tidak kembali ke sertifikat pendengar dasar. Sebaliknya, selalu digunakan sertifikat dari pendengar HTTPS yang aturan pengalihan permintaannya memiliki prioritas tertinggi (nomor prioritas terendah). Perilaku ini berbeda dari SKU V1, yang mengembalikan sertifikat listener dasar sebagai cadangan.

Petunjuk

Mengontrol sertifikat default dengan lubang SNI: Untuk mencegah Application Gateway V2 mengekspos sertifikat situs produksi saat klien terhubung dengan alamat IP tanpa SNI, Anda dapat mengonfigurasi "lubang SNI":

1. Buat pendengar HTTPS multi-situs dengan nama host tiruan yang tidak cocok dengan situs nyata apa pun (misalnya, sni-hole.invalid).
2. Unggah sertifikat yang ditandatangani sendiri ke pendengar ini.
3. Buat aturan perutean permintaan terkait dengan pendengar ini dan tetapkan prioritas tertinggi (nomor prioritas terendah) di antara semua aturan Anda.

Dengan konfigurasi ini, koneksi apa pun tanpa header SNI yang cocok menerima sertifikat yang ditandatangani sendiri alih-alih sertifikat situs yang valid. Ini mencegah koneksi khusus IP mendapatkan informasi tentang situs yang dihosting.

Sambungan TLS ujung belakang (gateway aplikasi ke server ujung belakang)

Untuk pemeriksaan lalu lintas

Skenario	v1	v2
Ketika FQDN atau SNI dikonfigurasi	Atur sebagai FQDN dari pool backend. Sesuai RFC 6066, alamat IPv4 dan IPv6 harfiah tidak diizinkan dalam nama host SNI.	Nilai SNI diatur berdasarkan jenis validasi TLS di Pengaturan Backend. 1. Validasi lengkap – Pelacak menggunakan SNI dalam urutan prioritas berikut: a) Nama host Pemindaian Kesehatan Kustom b) Nama host Pengaturan Backend (sesuai nilai Diganti atau Pilih dari server backend) 2. Dapat dikonfigurasi Gunakan SNI tertentu: Alat pemeriksa menggunakan hostname tetap ini untuk validasi. Lewati SNI: Tidak melakukan validasi Nama Subjek.
Ketika FQDN atau SNI TIDAK dikonfigurasi (hanya alamat IP yang tersedia)	SNI (nama_server) tidak akan disetel. Catatan: Dalam hal ini, server backend harus dapat mengembalikan sertifikat default/fallback dan ini harus diperbolehkan tercantum dalam pengaturan HTTP di bawah sertifikat autentikasi. Jika tidak ada sertifikat default atau cadangan yang dikonfigurasi di server backend dan SNI diperlukan, server mungkin akan mengatur ulang sambungan dan menyebabkan kegagalan pengujian.	Jika Probe Kustom atau Pengaturan Latar Belakang menggunakan alamat IP di bidang nama host, SNI tidak ditentukan, sesuai dengan RFC 6066. Ini termasuk kasus di mana alat pemeriksa default menggunakan 127.0.0.1.

Untuk lalu lintas langsung

Skenario	v1	v2
Saat FQDN atau SNI tersedia	SNI diatur menggunakan FQDN dari server backend.	Nilai SNI diatur berdasarkan jenis validasi TLS di Pengaturan Backend. 1. Validasi lengkap – SNI ditetapkan sesuai dengan urutan prioritas berikut: a) Nama host Pengaturan Backend (sesuai dengan nilai yang Diganti atau Diambil dari server backend) b) Header host permintaan klien masuk 2. Dapat dikonfigurasi Gunakan SNI tertentu: Menggunakan nama host tetap ini untuk validasi. Lewati SNI: Tidak melakukan validasi Nama Subjek.
Ketika FQDN atau SNI TIDAK tersedia (hanya alamat IP yang tersedia)	SNI tidak akan ditetapkan sesuai RFC 6066 jika entri kumpulan backend bukan FQDN	SNI tidak akan ditetapkan sesuai RFC 6066.

Langkah berikutnya

Setelah mempelajari tentang TLS ujung ke ujung, buka Konfigurasi TLS ujung ke ujung dengan menggunakan Application Gateway with PowerShell untuk membuat gateway aplikasi menggunakan TLS ujung ke ujung.