OpenVPN verify-x509-name: subject, name, dan name-prefix

Baca dulu jenis pencocokannya, baru teksnya: sebuah verify-x509-name direktif bisa tampak benar namun tetap menerima sertifikat yang tidak ingin Anda percayai. Dua baris dengan teks yang diharapkan sama tetapi jenis berbeda adalah dua persyaratan berbeda. Baca jenisnya dulu, lalu teksnya. Perlakukan direktif ini sebagai satu syarat tambahan pada koneksi, bukan sebagai seluruh pemeriksaan.

Apa yang sebenarnya dinyatakan opsi ini

Direktif ini menyebut identitas yang harus dibawa sertifikat pihak lain. Bila perbandingan gagal, OpenVPN membatalkan handshake dan tidak ada terowongan yang naik. Semua hal lain di profil tetap berlaku: sertifikat harus berantai ke CA tepercaya dan pemeriksaan peran harus lolos, jadi ini syarat tambahan, bukan pengganti. Profil yang memenuhi ekspektasi nama tetapi gagal pada pemeriksaan peran tetap rusak, dan log biasanya mengatakannya.

Ini juga berbeda dari validasi nama host yang dilakukan peramban. Peramban mencocokkan nama dengan nama alternatif subject menurut aturan tumpukan TLS-nya, sedangkan OpenVPN membandingkan satu bidang sertifikat dengan jenis yang Anda pilih. Karena itu menempelkan nama host gaya peramban ke dalam direktif dapat menghasilkan ketidakcocokan meski sertifikat benar-benar mencakup layanan tersebut.

subject: seluruh nama terbedakan, karakter demi karakter

Bila tidak ada jenis yang ditulis, bawaannya subject, dan nilai yang diharapkan harus mereproduksi seluruh subject DN sertifikat. Urutan bidang, pemisah, spasi, dan escaping semuanya diperhitungkan, karena perbandingan berjalan pada string sebagaimana dikodekan. Jika jenisnya dibiarkan kosong, Anda memilih yang paling ketat dari ketiga perbandingan. Tidak ada langkah normalisasi yang menyelamatkan perbedaan kosmetik. Itu layak diketahui sebelum pembaruan pertama, bukan sesudahnya.

Keketatan itu rapuh antar pembaruan. CA yang menyusun ulang atribut, menyisipkan bidang tambahan, atau mengubah cara escaping suatu nilai menghasilkan string baru untuk mesin yang sama, dan direktif yang berfungsi bertahun-tahun mulai gagal pada penerbitan berikutnya. Menyimpan DN yang diterima dalam catatan perubahan membuat pembaruan berikutnya menjadi selisih. Bila operator menerbitkan DN lengkap dan menjamin bentuknya, subject adalah pilihan wajar; di tempat lain bidang yang lebih sempit lebih mudah dijaga benar.

name: satu bidang, biasanya nama umum

Jenis name membandingkan satu bidang subject. Kecuali profil menyatakan lain, bidang itu adalah nama umum, dan nilai yang diharapkan tepat bidang itu, bukan DN di sekitarnya.

Jebakannya adalah sertifikat modern tidak selalu menaruh nama layanan di CN. Banyak yang membawanya di nama alternatif subject dan membiarkan CN kosong atau umum, sehingga sertifikat yang diterima peramban tetap bisa gagal pada perbandingan ini. Periksa sertifikat yang benar-benar diterbitkan untuk Anda sebelum menulis ekspektasi, dan pastikan bidang mana yang dipilih profil. CN kosong yang dibandingkan dengan nama adalah ketidakcocokan, bukan kecelakaan konfigurasi.

name-prefix: lebar secara desain, jadi batasi cakupannya

Ekspektasi berjenis name-prefix cocok dengan awal bidang yang dipilih. Itu nyaman untuk skema penamaan dan berbahaya untuk apa pun yang dibagi.

Dengan vpn.example sebagai ekspektasi, baik vpn.example.com maupun vpn.example.net akan lolos, asalkan sisa rantainya tepercaya. Keluasan itulah fiturnya, dan juga bagian yang perlu dibenarkan secara tertulis. Prefiks wajar bila CA dan skema penamaannya milik Anda, dan jauh lebih lemah bila CA publik menerbitkan dalam pola yang sama. Jika skema butuh keluwesan, batasi di CA alih-alih memperlebar pemeriksaan klien.

Pilih jenis dari pengenalnya, lalu buktikan

Bekerjalah mundur dari identitas yang dimaksud operator. Bila ia menerbitkan DN lengkap dan menjaganya stabil, subject menyatakan itu. Bila ia menyebut layanan dengan nama umum, gunakan name. Bila ia memiliki skema penamaan dan menerima seluruh ruangnya, name-prefix menyatakannya secara eksplisit.

Pembaruan adalah tempat direktif ini diuji. Bandingkan identitas yang disetujui dengan sertifikat baru, bukan dengan berkas lama, karena alamat endpoint baru tidak berarti identitas sertifikat baru. Jangan hapus direktif hanya karena alamat yang familier menjawab: keterjangkauan dan pihak yang dimaksud adalah dua fakta berbeda, dan alamat hanya membuktikan bahwa sesuatu menjawab. Catat galat persisnya dan detail nama publik dalam laporan yang sudah dibersihkan, karena ketidakcocokan nama dapat ditunjukkan tanpa bahan kunci privat apa pun.

Setelah koreksi yang didukung, sambungkan lagi dengan semua pemeriksaan yang dimaksud aktif dan verifikasi sumber daya yang benar-benar Anda butuhkan. Keberhasilan berarti server yang dimaksud diterima, bukan bahwa suatu sertifikat dipaksa lolos. Panduan resmi OpenVPN 2.6 manual mendokumentasikan tiga jenis itu dan catatan kepercayaannya, dan itulah rujukan yang dikutip ketika antarmuka vendor tidak sependapat dengan profil.