Sertifikat gateway VPN Anda masih berlaku, rantainya tervalidasi, dan klien IKEv2 tetap menolak login dengan pesan tentang interval validitas sertifikat. Naluri pertama adalah menerbitkan ulang sertifikat gateway atau mengganti metode EAP, dan keduanya biasanya salah. Upaya login membawa dua identitas server yang terpisah: sertifikat gateway yang dipakai IKE, dan sertifikat yang disajikan oleh apa pun yang mengakhiri PEAP. Salah satunya baik, dan yang lain adalah alasan klien berhenti.

Dua identitas, satu upaya login

Sertifikat di profil VPN termasuk pertukaran IKE: ini membuktikan bahwa gateway adalah rekan yang disebut profil, di bawah kebijakan IKE yang dikonfigurasi. Sertifikat yang gagal di sini milik percakapan lain, sesi TLS yang dibuka PEAP dengan apa pun yang mengautentikasi pengguna, yang sering kali server RADIUS seperti NPS dan bukan gateway itu sendiri. Pemeriksaan ketiga, kredensial pengguna, terjadi di dalam sesi itu. Kata sandi yang valid tidak dapat memperbaiki sertifikat server yang kedaluwarsa, dan sertifikat gateway yang valid tidak dapat menjamin endpoint PEAP.

Pelapisan ini menjelaskan mengapa kesalahan sertifikat muncul di tempat yang satu-satunya sertifikat terkonfigurasi adalah milik gateway. Ini juga menjelaskan mengapa menerbitkan ulang sertifikat itu tidak mengubah apa pun.

Baca baris log terhadap tahapannya

Temukan pesan yang menyebutkan alasan dan tanggalnya. Keluhan tentang interval validitas di samping kesalahan subjek berarti server menolak sertifikat yang diberikan kepadanya, bukan bahwa pengguna menolak login. Lalu temukan tahapannya: log charon strongSwan menampilkan IKE_SA .* established sebelum pertukaran EAP dimulai, jadi kesalahan sertifikat setelah baris itu milik identitas EAP, sedangkan kesalahan sebelumnya menunjuk ke gateway. Teks tahap di panel koneksi klien Windows mengatakan hal yang sama.

Periksa jam klien sebelum menyentuh sertifikat apa pun. Perangkat yang meleset beberapa jam menghasilkan kesalahan validitas yang sama dengan sertifikat yang benar-benar kedaluwarsa. Menyetel ulang jam adalah perbaikan lima detik, dan mengganti sertifikat yang tidak pernah menjadi masalah adalah gangguan layanan.

Cari tahu endpoint mana yang mengakhiri PEAP

Dalam desain gateway plus RADIUS, gateway meneruskan EAP dan tidak mengakhirinya. Plugin eap-radius strongSwan menyerahkan pertukaran ke server RADIUS, yang memiliki sesi TLS PEAP dan sertifikatnya. Korelasikan satu upaya yang gagal di kedua log dan pastikan proses mana yang benar-benar memilih sertifikat untuk sesi itu.

Untuk NPS sertifikat harus berada di penyimpanan komputer lokal, membawa tujuan autentikasi server, cocok dengan nama yang diharapkan klien, dan dapat dibaca oleh akun layanan. Persyaratan sertifikat Microsoft untuk NPS mencantumkan syarat-syarat itu. Server EAP lain punya aturan pemilihan sendiri, jadi jangan menyalin kekhususan NPS ke penerapan FreeRADIUS atau sebaliknya. Aturan yang bertahan pada kedua pengaturan adalah endpoint yang mengakhiri PEAP memiliki sertifikat yang akan Anda ubah.

Ganti sertifikat di tempat EAP berakhir

Perbarui atau ganti sertifikat pada endpoint yang mengakhiri PEAP, melalui proses yang didukung, dengan mempertahankan tujuan autentikasi server dan nama yang diharapkan. Pasang rantai lengkap di tempat layanan mencarinya dan beri layanan akses ke kunci privat. Mulai ulang atau ikat ulang layanan, karena banyak layanan menyimpan sertifikat lama di memori dan terus menyajikannya. File yang disalin ke mesin tidak membuktikan apa pun tentang sertifikat yang sebenarnya disajikan layanan.

Pastikan perubahan dengan mengorelasikan upaya berikutnya dengan log milik layanan, atau dengan memeriksa sertifikat yang disajikan sesi. Jika log itu masih menampilkan sidik jari lama, mulai ulang tidak berhasil.

Jangan berasumsi bahwa file terbaru di sebuah direktori adalah yang sedang dipakai. Salinan dengan nama yang benar dan izin yang salah tidak mengubah apa pun. Nilai perubahan dari identitas yang disajikan, bukan dari stempel waktu file.

Apa yang tidak boleh dilakukan

Jangan menonaktifkan validasi PEAP atau memaksakan metode dalam yang lebih lemah untuk melewati kesalahan. Itu mengubah kebijakan dan menghapus sifat autentikasi server yang justru menangkap sertifikat kedaluwarsa. Anda akan menukar pemeriksaan yang berfungsi dengan koneksi yang berfungsi, dan sertifikat kedaluwarsa berikutnya akan datang tanpa apa pun yang mengumumkannya.

Jangan menganggap koneksi berhasil dari sistem operasi lain sebagai bukti bahwa sertifikat dapat diterima. Klien itu mungkin memakai metode EAP lain, penyimpanan kepercayaan lain, atau tidak ada validasi server sama sekali, sehingga keberhasilannya tidak mengatakan apa pun tentang pemeriksaan yang gagal di sini. Pertahankan satu uji negatif yang disengaja, seperti sertifikat dengan nama salah atau rantai yang tidak tepercaya, yang gagal sesuai harapan. Jika uji itu sekarang lolos, Anda menghapus pemeriksaan, bukan memperbaiki sertifikat. Catat identitas mana yang gagal, agar orang berikutnya tidak memulai lagi dari sertifikat gateway.

Artikel terkait