HTTPS ke IP privat: identitas sertifikat atau nama host?
IP privat dapat menjadi identitas TLS yang valid jika sertifikat menyatakannya. Pilih antara SAN IP dan nama host yang stabil, lalu rencanakan perubahan alamat.
Layanan Anda di https://10.60.0.25 dapat memiliki TLS terautentikasi bahkan tanpa nama DNS. Alamat itu adalah identitas yang harus divalidasi klien, dan sertifikat harus menjelaskannya dengan tepat. Keputusannya adalah apakah alamat itu cukup stabil untuk menjadi identitas, atau apakah nama host akan lebih mudah dirawat. VPN menjawab keterjangkauan; bukan menjawab ini.
Benahi identitas dan kepercayaannya, dan URL berbasis IP adalah rancangan yang sah.
Apa yang sebenarnya divalidasi klien
Klien membandingkan identitas referensi di URL dengan nama alternatif subjek sertifikat. Untuk alamat IP, itu berarti entri iPAddress yang sama dengan alamat tersebut. Nama umum yang ramah bukan pengganti.
RFC 9525 memisahkan identitas alamat IP dari nama DNS dan menetapkan aturan pencocokan. Menaruh alamat hanya di label subjek, atau sebagai entri bertipe DNS, tidak menghasilkan kecocokan. Itu sebabnya SAN adalah bidang yang harus diperiksa saat peringatan muncul.
Kepercayaan adalah pemeriksaan kedua yang independen. Kecocokan nama tidak memperbaiki rantai yang tidak dipercaya, sertifikat kedaluwarsa, atau sertifikat yang diterbitkan untuk tujuan lain.
Keputusan satu: apakah alamat cukup stabil untuk menjadi identitas
Jika alamat tetap sepanjang masa penerapan, sertifikat SAN IP itu sederhana dan jujur. Jika layanan dapat berpindah, setiap perpindahan menjadi penggantian sertifikat dan pembaruan klien yang terkoordinasi.
Nama host yang stabil mengurangi keterikatan itu. Klien memakai nama, DNS yang disetujui memetakannya ke alamat saat ini, dan perubahan alamat tidak lagi menjadi perubahan identitas. Sertifikat tetap perlu diperbarui, tetapi URL tidak berubah.
Entri file hosts yang dikelola dapat menyediakan pemetaan di lingkungan kecil. Itu menambah tanggung jawab distribusi; tidak menggantikan verifikasi TLS.
Keputusan dua: bagaimana klien akan memercayai penerbit
Untuk CA privat, distribusikan jangkar kepercayaan ke perangkat yang dituju melalui mekanisme yang disetujui. Jangan melatih pengguna untuk melewati peringatan atau memasang sertifikat yang diberikan halaman masuk. Jika Anda ingin sertifikat yang dipercaya publik, periksa aturan penerbit saat ini untuk alamat privat sebelum merencanakan berdasarkan itu. Sebagian besar penerbit publik tidak akan memvalidasi IP privat sebagai identitas publik.
Tinjau browser atau aplikasi yang sebenarnya. Penyimpanan kepercayaan dan perilaku validasinya lebih penting daripada dokumentasi sertifikat umum sistem operasi. Periksa di perangkat sebenarnya, bukan hanya di konsol.
Gateway VPN mungkin bukan mesin yang menjalankan aplikasi web, jadi jangan menganggap sertifikat terowongan ada hubungannya dengan yang ini.
Rencanakan perubahan alamat sebelum terjadi
Jika 10.60.0.25 menjadi 10.60.0.40, sertifikat lama tidak lagi menjelaskan URL. Rencanakan penggantian dan pembaruan klien bersama-sama, dan jangan pernah menonaktifkan verifikasi selama perpindahan.
Pilih identitas yang akan diketik pengguna atau dikonfigurasi aplikasi, lalu selaraskan penerbitan, kepercayaan, penerapan, dan pembaruan di sekitarnya. Halaman yang dapat dijangkau dengan peringatan yang diabaikan bukan hasil yang sama dengan layanan yang identitasnya divalidasi klien.