Memperbaharui Sijil VPN Tanpa Mengubah Identitinya

Pembaharuan sijil yang mengubah identiti bukanlah pembaharuan, ia adalah pemindahan yang memakai tiket penyelenggaraan. Klien mengesahkan nama, rantaian dan kadangkala kunci tertentu, dan ketiga-tiganya boleh berubah tanpa tarikh luput berubah. Sebelum meminta penggantian, tuliskan apa yang sebenarnya diperiksa oleh klien: nama hos atau identiti rakan sebaya, tujuan sijil, dasar kunci dan rantaian pengeluar. Pembaharuan sama ada rutin atau diselaraskan bergantung pada apa yang diubah oleh penggantian itu.

Tiga syarat menentukan bentuk pembaharuan

Tiga syarat itu ialah sama ada sesuatu menyematkan daun, sama ada rantaian berubah, dan siapa lagi yang mengesahkan nama. Jawab dari pihak klien dan bukan dari kemudahan CA, kerana klien itulah yang gagal pada pukul tiga pagi.

Mulakan dengan memeriksa sijil yang anda miliki. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName mencetak subjek, pengeluar, tetingkap kesahihan dan nama-nama yang sebenarnya sah untuk sijil itu. Medan terakhir itulah yang paling penting dan paling kerap diandaikan: permintaan pembaharuan yang meninggalkan SAN yang diharapkan klien menghasilkan sijil yang sah secara teknikal tetapi salah secara fungsi. Salin senarai SAN daripada sijil lama ke dalam permintaan dan bukannya menaipnya semula dari ingatan.

Syarat satu: adakah sesuatu menyematkan daun

Jika klien mempercayai CA yang diselenggara dan mengesahkan nama, pembaharuan daun dengan kunci baharu tidak kelihatan kepada mereka. Jika mana-mana klien menyematkan sijil daun, cap jarinya atau kunci awamnya, penggantian itu ialah perubahan yang diselaraskan dengan peralihan keras, kerana sematan lama tidak dapat mengesahkan sijil baharu.

Ketahui kes mana anda berada sebelum memesan apa-apa. Sematan yang tidak didokumenkan oleh sesiapa tetap sematan apabila ia patah.

Syarat dua: bandingkan sematan dan rantaian

Cap jari menjadikan sematan boleh diperiksa: openssl x509 -noout -fingerprint -sha256 -in server.crt pada sijil lama dan baharu, dan openssl x509 -noout -pubkey untuk membandingkan kunci awam. Jika konfigurasi klien, profil mudah alih atau stor kepercayaan perkakas mengandungi salah satu nilai itu, anda mempunyai sematan. Profil VPN mudah alih ialah tempat persembunyian yang biasa, kerana profil diedarkan sekali dan tidak pernah diperiksa lagi.

Jika penggantian datang daripada perantara yang sama dan klien sudah memilikinya atau boleh mendapatkannya, tiada apa yang berubah di pihak kepercayaan. Perantara baharu, pengeluar berbeza atau rantaian yang dihantar dalam susunan yang salah menjadikan pembaharuan sebagai perubahan kepercayaan, dan kegagalan itu kelihatan seperti pengeluar tidak dikenali dan bukannya sijil yang tamat tempoh.

Periksa rantaian yang benar-benar dihantar oleh pelayan dengan openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, dan sahkan secara setempat dengan openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Melakukannya sebelum perubahan memberi anda garis dasar untuk dibandingkan selepas itu.

Syarat tiga: siapa lagi yang mengesahkan nama

Konsentrator VPN, pengimbang beban, probe pemantauan, integrasi RADIUS atau SAML dan profil mudah alih masing-masing boleh menyimpan salinan sendiri bagi nama yang dijangka atau sauh kepercayaan. Pembaharuan ialah saat salinan-salinan itu mencapah, kerana sijil berubah dan salinannya tidak.

Senaraikan setiap pengguna sebelum perubahan dan putuskan, bagi setiap satu, sama ada ia memerlukan kemas kini. Yang anda lupa itulah yang akan memanggil anda.

Terdapat juga perangkap masa. Periksa permulaan kesahihan serta tarikh luput, kerana sijil yang disediakan untuk pengaktifan kemudian ditolak jika dipasang terlalu awal, dan ralat itu kelihatan seperti masalah jam dan bukannya masalah penyediaan. openssl x509 -noout -dates pada fail baharu sebelum anda menggunakan adalah pemeriksaan dua saat. Kekalkan juga laluan pemulihan yang disokong dan konfigurasi yang diketahui baik, supaya pembaharuan yang salah boleh diterbalikkan dengan memulihkan sijil dan kunci sebelumnya.

Gunakan, sahkan dengan pengesahan baharu, kemudian nyahaktifkan

Terowong yang telah terbina mencerminkan pengesahan yang berlaku semasa ia dibina, jadi ia boleh kelihatan sihat sedangkan setiap sambungan baharu gagal. Uji dengan pengesahan baharu menggunakan nama perkhidmatan sebenar yang digunakan oleh klien.

Lengkapkan pemeriksaan peringkat aplikasi yang penting kepada pengguna, dan sahkan penghantaran rantaian dari sudut pandangan klien dan bukannya pelayan. Jangan tekan pemeriksaan nama atau sijil untuk mengekalkan peralihan itu senyap; itu menjadikan masalah keserasian sementara sebagai kekal.

Nyahaktifkan bahan usang hanya selepas penggunaan disahkan, dan anggap kunci yang terjejas sebagai kes yang sama sekali berbeza: pembaharuan semata-mata tidak membatalkan apa-apa, jadi identiti yang terjejas memerlukan proses pembatalan dan pengendalian sesi penggunaan itu. RFC 5280 mentakrifkan peraturan sijil dan pengesahan laluan yang mendasari semua ini. Asingkan pembaharuan daun rutin daripada penggantian CA, supaya klien tidak diminta mempercayai pengeluar baharu tanpa sebab.