Memperbarui Sertifikat VPN Tanpa Mengubah Identitasnya

Pembaruan sertifikat yang mengubah identitas bukanlah pembaruan, melainkan migrasi yang mengenakan tiket pemeliharaan. Klien memverifikasi nama, rantai, dan kadang kunci tertentu, dan ketiganya bisa berubah tanpa tanggal kedaluwarsa berubah. Sebelum meminta penggantian, tulis apa yang sebenarnya diperiksa klien: nama host atau identitas peer, tujuan sertifikat, kebijakan kunci, dan rantai penerbit. Pembaruan bersifat rutin atau terkoordinasi tergantung pada apa yang diubah oleh penggantian itu.

Tiga kondisi menentukan bentuk pembaruan

Ketiga kondisi itu adalah apakah ada yang mem-pin leaf, apakah rantai berubah, dan siapa lagi yang memvalidasi nama. Jawablah dari sisi klien, bukan dari kenyamanan CA, karena klienlah yang gagal pada jam tiga pagi.

Mulailah dengan memeriksa sertifikat yang Anda miliki. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName mencetak subjek, penerbit, jendela validitas, dan nama-nama yang benar-benar valid untuk sertifikat itu. Bidang terakhir itu paling penting dan paling sering diasumsikan: permintaan pembaruan yang menghilangkan SAN yang diandalkan klien menghasilkan sertifikat yang valid secara teknis tetapi salah secara fungsional. Salin daftar SAN dari sertifikat lama ke permintaan, jangan mengetiknya ulang dari ingatan.

Kondisi satu: apakah ada yang mem-pin leaf

Jika klien memercayai CA yang terpelihara dan memvalidasi nama, pembaruan leaf dengan kunci baru tidak terlihat oleh mereka. Jika ada klien yang mem-pin sertifikat leaf, sidik jarinya, atau kunci publiknya, penggantian adalah perubahan terkoordinasi dengan pergantian keras, karena pin lama tidak dapat memvalidasi sertifikat baru.

Cari tahu kasus mana yang Anda hadapi sebelum memesan apa pun. Pin yang tidak didokumentasikan siapa pun tetap pin ketika rusak.

Kondisi dua: bandingkan pin dan rantai

Sidik jari membuat pin dapat diperiksa: openssl x509 -noout -fingerprint -sha256 -in server.crt pada sertifikat lama dan baru, dan openssl x509 -noout -pubkey untuk membandingkan kunci publik. Jika konfigurasi klien, profil seluler, atau penyimpanan kepercayaan perangkat memuat salah satu nilai itu, Anda punya pin. Profil VPN seluler adalah tempat persembunyian yang umum, karena profil disebarkan sekali dan tidak pernah diperiksa lagi.

Jika penggantian berasal dari intermediate yang sama dan klien sudah memilikinya atau dapat mengambilnya, tidak ada yang berubah di sisi kepercayaan. Intermediate baru, penerbit berbeda, atau rantai yang dikirim dalam urutan salah mengubah pembaruan menjadi perubahan kepercayaan, dan kegagalannya tampak seperti penerbit tak dikenal, bukan sertifikat kedaluwarsa.

Periksa rantai yang benar-benar dikirim server dengan openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, dan verifikasi secara lokal dengan openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Melakukannya sebelum perubahan memberi Anda garis dasar untuk dibandingkan sesudahnya.

Kondisi tiga: siapa lagi yang memvalidasi nama

Konsentrator VPN, penyeimbang beban, probe pemantauan, integrasi RADIUS atau SAML, dan profil seluler masing-masing dapat menyimpan salinan nama yang diharapkan atau jangkar kepercayaan. Pembaruan adalah saat salinan-salinan itu menyimpang, karena sertifikat berubah dan salinannya tidak.

Daftarkan setiap konsumen sebelum perubahan dan putuskan, untuk masing-masing, apakah perlu pembaruan. Yang Anda lupakan adalah yang akan menelepon Anda.

Ada juga jebakan waktu. Periksa awal validitas sekaligus kedaluwarsa, karena sertifikat yang disiapkan untuk aktivasi nanti ditolak jika dipasang terlalu dini, dan galatnya tampak seperti masalah jam, bukan masalah penyiapan. openssl x509 -noout -dates pada file baru sebelum Anda menerapkannya adalah pemeriksaan dua detik. Pertahankan juga jalur pemulihan yang didukung dan konfigurasi yang diketahui baik, agar pembaruan yang salah dapat dibalik dengan memulihkan sertifikat dan kunci sebelumnya.

Terapkan, verifikasi dengan autentikasi baru, lalu pensiunkan

Tunnel yang sudah berdiri mencerminkan validasi yang terjadi saat dibangun, jadi bisa tampak sehat sementara setiap koneksi baru gagal. Uji dengan autentikasi baru menggunakan nama layanan sebenarnya yang dipakai klien.

Selesaikan pemeriksaan tingkat aplikasi yang penting bagi pengguna, dan konfirmasikan pengiriman rantai dari sudut pandang klien, bukan dari sudut pandang server. Jangan menekan pemeriksaan nama atau sertifikat agar transisi tetap tenang; itu mengubah masalah kompatibilitas sementara menjadi permanen.

Pensiunkan materi usang hanya setelah penerapan terverifikasi, dan perlakukan kunci yang disusupi sebagai kasus yang sama sekali berbeda: pembaruan saja tidak mencabut apa pun, jadi identitas yang terdampak memerlukan proses pencabutan dan penanganan sesi dari penerapan tersebut. RFC 5280 mendefinisikan aturan sertifikat dan validasi jalur di bawah semua ini. Pisahkan pembaruan leaf rutin dari penggantian CA, agar klien tidak diminta memercayai penerbit baru tanpa alasan.