SAN Sertifikat IKEv2: Mengapa Pemeriksaan Identitas Gagal

Sertifikat Anda berantai ke CA tepercaya, tanggalnya benar, tetapi peer tetap menolak menyelesaikan fase 1 dengan kesalahan identitas. Keterjangkauan dan tanda tangan yang valid hanyalah separuh dari yang diperiksa klien IKEv2. Separuh lainnya adalah apakah identitas yang diharapkannya muncul di sertifikat pada bidang yang tepat, dan harapan itu ditetapkan oleh profil, bukan oleh nama berkas sertifikat.

Gejalanya selalu berbentuk sama

Profil koneksi diubah dari nama host menjadi alamat IP, atau diperbarui dari sertifikat yang membawa nama DNS menjadi sertifikat yang hanya membawa alamat, danterowongan berhenti bernegosiasi. Tidak ada yang berubah di jalur jaringan. Klien mencapai peer, menerima sertifikat, dan menolak identitas peer karena pengenal yang diminta untuk diharapkan tidak terwakili dalam bidang yang diterimanya. Pembaruan adalah pemicu biasa, karena sertifikat pengganti sering berasal dari templat yang berbeda dari yang digantikannya.

Kedua sisi lalu mencatat sesuatu yang tidak membantu, itulah sebabnya kegagalan biasanya dilaporkan sebagai masalah sertifikat. Log klien dapat menyebutkan identitas yang diinginkannya, dan nama itu adalah petunjuk yang Anda cari, bukan tanggal kedaluwarsa.

Cocokkan jenis pengenal, bukan hanya nilainya

SAN dNSName dan SAN iPAddress adalah bidang berbeda dengan aturan pencocokan berbeda, jadi sertifikat yang membawa 203.0.113.10 sebagai string DNS tidak memuaskan klien yang mengharapkan identitas IP. Validator modern sebagian besar mengabaikan nama umum, sehingga label ramah di detail sertifikat tidak membuktikan apa pun tentang apa yang akan cocok. Jika nama host diganti dengan alamat saat pemecahan masalah, anggap identitas yang diharapkan ikut berpindah sampai Anda memeriksanya. Bandingkan string di profil dengan string di SAN karakter demi karakter, karena titik di akhir atau spasi nyasar sudah cukup.

Wildcard hanyalah kemudahan DNS dan mengikuti aturan pencocokannya sendiri, yang merupakan alasan lain mengapa profil berbasis IP tidak boleh bergantung padanya.

Temukan di mana setiap klien menyimpan harapan itu

Di strongSwan, nilai yang dibandingkan dengan sertifikat berasal dari pengaturan identitas peer: rightid dalam konfigurasi klasik, atau id dari bagian koneksi jarak jauh di swanctl. Dokumentasinya tentang interoperabilitas Apple IKEv2 berguna di sini karena menjelaskan konvensi identitas yang digunakan klien yang digerakkan profil, dan konvensi itu menjelaskan kelas ketidakcocokan yang tampak acak di jaringan.

Profil konfigurasi Apple membawa bidang pengenal jarak jauh, dan nilai di sana adalah yang diperiksa klien, bukan alamat server di pengaturan koneksi. Klien Windows dan peralatan masing-masing memiliki bidang sendiri dengan nilai bawaan sendiri, dan nilai bawaan itu sering mengikuti alamat yang Anda ketik. Ketika dua bidang tidak setuju, yang benar-benar dibaca klienlah yang menang, dan itu jarang yang Anda sunting.

Perbaiki profil atau sertifikat, dengan sengaja

Periksa sertifikat peer dengan perkakas yang disetujui dan daftarkan entri SAN beserta jenisnya sebelum mengubah apa pun. Pemeriksaan itu tidak memerlukan kunci privat dan tidak perlu mengunggah, dan menyelesaikan pertanyaan dalam hitungan detik. Jika penerapan menghendaki satu identitas DNS, sertifikat harus membawanya sebagai entri dNSName, dan jika penerapan menghendaki alamat, sertifikat memerlukan entri iPAddress untuk alamat yang tepat itu.

Ketika sertifikatnya salah, minta yang sudah diperbaiki dari operator dengan pengenal yang diharapkan secara spesifik. Ketika profilnya salah, perbaiki profil dan biarkan sertifikat. Menonaktifkan validasi identitas membuat kesalahan hilang dan menghapus pemeriksaan bahwa terowongan berbicara dengan peer yang Anda maksud.

Dokumentasikan identitas yang diharapkan per platform klien, karena nilai yang diturunkan satu klien secara otomatis mungkin perlu dinyatakan eksplisit di klien lain.

Berikan empat fakta pada permintaan pembaruan

Tuliskan pengenal yang diharapkan dan jenisnya, entri SAN yang benar-benar dimiliki sertifikat saat ini, klien dan versi yang melakukan pemeriksaan, serta teks kesalahan yang persis. Permintaan pembaruan yang dibangun dari empat baris itu mendapatkan sertifikat yang benar pada percobaan pertama, bukan sertifikat lain dengan nama berkas yang sama-sama familier.