Jika Anda mengganti «sertifikat VPN», Anda mungkin mengubah layanan yang salah. RRAS menyimpan setidaknya tiga kontrol sertifikat, masing-masing milik protokol dan peran koneksi yang berbeda. Menyebutkan protokolnya lebih dulu mengubah tebakan berisiko menjadi satu perubahan pengikatan yang dapat dibalik. Semua yang di bawah bergantung pada satu kalimat itu.

Sebutkan protokol sebelum sertifikat

Pendengar SSTP menyajikan sertifikat TLS kepada klien yang berperilaku seperti HTTPS. Koneksi IKEv2 situs-ke-situs yang masuk mengumumkan identitas server dan memvalidasi sertifikat rekan terhadap akar tepercaya. Definisi situs-ke-situs per antarmuka membawa identitas mesinnya sendiri.

Itu tiga kontrol dengan tiga cakupan. Mencampuradukkannya menghasilkan perubahan yang tampak berhasil pada satu protokol dan tidak berpengaruh pada protokol lainnya, yang lebih buruk daripada kegagalan yang jelas. Catat protokol mana yang gagal, pihak mana yang menyajikan sertifikat, dan pihak mana yang menolaknya sebelum Anda menyentuh apa pun.

SSTP adalah pengikatan HTTPS

Untuk penerapan Remote Access yang didukung, Set-RemoteAccess mengekspos parameter SslCertificate yang digunakan untuk konektivitas SSTP dan untuk peran DirectAccess terkait HTTPS.

Cakupan validasi dan penerapannya mengikuti konfigurasi Remote Access, sehingga satu perubahan pengikatan dapat menjangkau lebih dari satu koneksi atau node. Dalam penerapan dengan penyeimbangan beban, cakupan itu mencakup setiap node yang dicakup konfigurasi. Mengubah satu node dan menguji satu klien membuat sisanya tetap menyajikan sertifikat daun lama, dan inilah jenis perubahan setengah jadi yang bertahan melewati jendela pemeliharaan.

Sebelum pembaruan, verifikasi nama layanan yang diharapkan, rantai, masa berlaku, penggunaan yang dimaksudkan, dan ketersediaan kunci privat. Sertifikat harus cocok dengan nama yang akan diperiksa klien, dan label adaptor bukanlah nama itu.

IKEv2 masuk punya parameternya sendiri

Set-VpnAuthProtocol mengonfigurasi autentikasi IKEv2 situs-ke-situs yang masuk, dan CertificateAdvertised menyediakan sertifikat ketika mode autentikasi terowongan memakainya. Ini bukan perintah umum untuk memilih sertifikat server apa pun di host.

Pisahkan dua objek: sertifikat daun yang disajikan server sebagai identitasnya sendiri, dan akar yang dipakai untuk menerima sertifikat rekan. Memilih penerbit mana yang Anda percayai tidak mengatakan apa pun tentang sertifikat daun mana yang disajikan server.

Identitas satu antarmuka situs-ke-situs diatur melalui Set-VpnS2SInterface. Itu bukan otomatis sertifikat SSTP, bahkan ketika keduanya berada di penyimpanan yang sama pada mesin yang sama.

Periksa kandidat terlebih dahulu

Tampilan terfokus dari penyimpanan mesin lokal menunjukkan metadata publik tanpa mengekspor apa pun yang privat:

Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Thumbprint, Subject, HasPrivateKey, NotAfter

Daftar itu adalah titik awal, bukan uji kelayakan. Periksa entri SAN, penggunaan kunci yang diperluas, rantai, dan akses akun layanan ke kunci privat untuk protokol yang Anda konfigurasi.

Sertifikat yang dipasang untuk identitas klien cloud yang tidak terkait tidak layak hanya karena muncul di penyimpanan yang sama. Visibilitas bukan kelayakan, dan sidik jari pada tangkapan layar tidak membuktikan apa pun tentang apakah akun layanan dapat membaca kunci. Periksa akses itu secara eksplisit, karena izin kunci yang hilang baru gagal saat layanan dimulai ulang dan mencoba memakai sertifikat.

Catat pengikatan saat ini dan pastikan Anda masih dapat menjangkau host dengan cara lain sebelum mengubahnya. Jalur pemulihan adalah bagian dari perubahan, bukan bagian dari insiden yang menyusul.

Pembaruan bukan aktivasi

Menerbitkan ulang sertifikat adalah tindakan berbeda dari memilihnya untuk layanan yang berjalan. Sertifikat daun baru dapat mempertahankan identitas DNS yang dimaksudkan dan tetap membawa sidik jari berbeda, sehingga tidak ada yang menunjuk padanya sampai pengikatan diperbarui. Pembaruan mengubah objek; aktivasi mengubah referensi ke objek itu. Mencampuradukkan keduanya adalah alasan sertifikat yang diperbarui dengan benar dapat tidak terpakai selama berminggu-minggu.

Terapkan perubahan yang didukung pada jendela yang sesuai, termasuk setiap restart yang didokumentasikan, lalu periksa sertifikat dari koneksi baru protokol yang dimaksudkan. Sesi klien yang di-cache mungkin masih menampilkan sertifikat daun lama dan membuat perubahan yang benar tampak rusak.

Hentikan penggunaan sertifikat sebelumnya melalui proses normal hanya setelah pemeriksaan itu lolos. Referensi Set-RemoteAccess mendokumentasikan cakupan parameter SSL, termasuk pengaruhnya dalam penerapan dengan penyeimbangan beban, dan itulah bagian yang layak dibaca sebelum perubahan pengikatan.

Artikel terkait