Apa yang Berlaku Apabila Anda Menggantikan Pihak Berkuasa Sijil VPN

Menggantikan pihak berkuasa sijil VPN bukanlah pertukaran fail. Pada saat CA baharu menandatangani sijil pertamanya, setiap pengesah yang masih mempercayai yang lama sahaja perlu membuat keputusan, dan hos yang tidak pernah menerima sauh baharu terus menolak rakan yang sah. Saya pernah melihatnya gagal dalam kedua-dua arah: gateway mempelajari CA baharu dan klien tidak, jadi sambungan baharu gagal, manakala terowong yang sudah naik kekal naik dan membuat gangguan kelihatan seperti masalah penghalaan. Berikut ialah apa yang berubah, mengikut urutan kegagalan muncul.

Satu penggantian, dua perubahan berasingan

Pihak berkuasa sijil ialah nama, kunci awam dan kunci peribadi yang menandatangani. Pengesah tidak pernah mempercayai «CA» secara abstrak. Mereka mempercayai satu sijil tertentu yang sudah berada dalam stor kepercayaan, dan menerima pengeluar hanya jika rantaian tandatangan sampai ke salinan tersimpan itu. Oleh itu penggantian CA mengubah dua perkara yang gagal secara berasingan: sauh mana yang diterima dan identiti rakan mana yang dikeluarkan di bawahnya.

Kebanyakan penggunaan VPN mengesahkan dalam kedua-dua arah. Klien mengesahkan sijil gateway, dan gateway mengesahkan sijil klien. Rotasi yang hanya menyegarkan bundel klien membiarkan pelayan menolak setiap klien yang masih mengemukakan identiti daripada CA lama, dan sebaliknya juga sama biasa. Senaraikan dahulu titik penguatkuasaan: stor kepercayaan klien, fail ca gateway, mana-mana proksi yang menamatkan TLS di hadapannya, dan pemeriksaan yang menguji titik akhir dari luar.

Apa yang diperiksa pengesah, mengikut urutan

Pengesahan laluan memanjat daripada sijil rakan melalui mana-mana perantara sehingga mencapai sauh yang dipercayai. Pada setiap langkah ia mengesahkan tandatangan, memeriksa bahawa setiap sijil berada dalam tetingkap kesahihannya, dan mengesahkan bahawa kekangan asas dan penggunaan kunci membenarkan pengeluar menandatangani. Hanya selepas itu aplikasi melihat sijil daun: nama alternatif subjek mesti meliputi nama yang didail, dan penggunaan kunci lanjutan mesti membenarkan pengesahan pelayan atau klien.

Untuk mengulang perjalanan itu di luar talian, halakan -CAfile ke bundel tepat yang akan anda gunakan, bukan ke stor sistem. Jika tidak, anda menguji hos, bukan perubahan itu:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Perintah itu hanya berfungsi terhadap pendengar TLS biasa seperti halaman pentadbir HTTPS gateway; saluran kawalan OpenVPN mendahului TLS, jadi s_client tidak dapat memeriksa jabat tangan terowong.

Peraturan pembinaan laluan di sebalik ralat itu ada dalam RFC 5280 bahagian 6. Ia menerangkan kegagalan yang jika tidak kelihatan sewenang-wenangnya: perantara tamat tempoh yang tiada siapa ingat, sijil yang penggunaan kuncinya melarang tandatangan, atau kekangan nama yang mengecualikan hos yang anda uji.

Mengapa terowong lama terus berfungsi

TLS dan OpenVPN kedua-duanya mengekalkan sesi yang telah dibentuk selepas jabat tangan selesai. Tiada apa yang mengesahkan semula sijil rakan bagi setiap paket, jadi klien yang bersambung sebelum perubahan terus melepaskan trafik sehingga ia berunding semula, menyambung semula atau terowong jatuh. Jurang inilah sebabnya penggantian CA boleh kelihatan baik selama sejam dan kemudian gagal pada saat terburuk: komputer riba bangun daripada tidur, pemetaan NAT tamat tempoh, gateway dimulakan semula.

Penyambungan semula sesi meregangkan ilusi itu lebih jauh. Tiket sesi TLS membolehkan klien kembali tanpa menghantar semula sijil, dan penyambungan semula melangkau pengesahan laluan kerana jabat tangan pertama sudah melakukannya. Jadi ujian yang jujur ialah jabat tangan penuh dalam proses baharu. Mulakan semula klien dan bukan sambung semula terowong, dan pada profil ujian pertimbangkan untuk melumpuhkan tiket supaya laluan penyambungan semula tidak dapat menyembunyikan rantaian yang rosak.

Kekalkan lapisan kunci statik berasingan daripada ini. tls-auth menambah HMAC pada saluran kawalan, tls-crypt menyulitkan dan mengesahkannya, dan kedua-duanya tidak membawa bahan sijil, jadi merotasi mana-mana satu ialah perubahan berasingan dengan mod kegagalannya sendiri. Penggunaan yang mencampurkan kedua-duanya berakhir dengan klien yang kunci statiknya elok, sijilnya usang dan mesej ralatnya tidak menyebut kedua-duanya.

Perangkap penggunaan semula nama subjek

Menggoda untuk menggunakan semula nama keistimewaan pendahulu supaya tiada apa di hilir perlu berubah. Itu mengekalkan baris pengeluar stabil dalam antara muka dan memusnahkan satu-satunya isyarat yang anda perlukan. Dua sijil dengan subjek sama dan kunci berbeza tidak dapat dibezakan melalui nama, jadi bundel yang memegang kedua-dua sauh memberikan pengesah dua calon dan tiada peraturan untuk memilih.

Pembinaan laluan kemudian boleh memilih yang salah, melaporkan «tidak dapat memperoleh sijil pengeluar tempatan» sedangkan sauh yang betul hadir, atau berjaya pada satu hos dan gagal pada hos lain dengan bundel yang sama, kerana susunan calon berbeza. Jika nama mesti digunakan semula, simpan kedua-dua sauh dalam fail berasingan sepanjang peralihan dan muatkannya secara eksplisit, dan gabungkan hanya apabila setiap rakan mengemukakan pengeluar baharu. Jika tidak, berikan pengganti nama umum yang tersendiri — akhiran generasi atau tarikh sudah memadai — supaya log dan teks ralat menyatakan di bawah pihak berkuasa mana rakan yang gagal dikeluarkan.

Rotasi yang tidak menjatuhkan rangkaian

Untuk penggantian terancang, terima kedua-dua sauh untuk tempoh terhad dan bukannya bertukar dalam satu langkah. Keluarkan CA baharu dan perantaranya, letakkan sauh baharu dalam bundel setiap pengesah di sebelah yang lama, dan hanya selepas itu mula mengeluarkan sijil rakan daripadanya. Rakan dengan identiti lama disahkan terhadap sauh lama; yang baharu berfungsi terhadap sauh baharu.

Dilakukan dalam urutan itu, setiap langkah boleh dibalikkan. Kegagalan yang anda elakkan ialah pertukaran serentak, apabila klien yang terlepas kemas kini bundel bertemu gateway yang sudah bersara sauh lama, jabat tangan mati, dan tiada log menyatakan pihak mana yang usang.

Bersara ke arah bertentangan. Keluarkan semula setiap identiti yang mesti bertahan, sahkan setiap satu mengemukakan rantaian baharu, kemudian buang sauh lama daripada bundel. Tarik kunci peribadi CA lama daripada perkhidmatan, kerana pengeluar yang masih boleh menandatangani bermakna rotasi belum selesai. Simpan sijil dan rekod pengeluaran untuk audit. Pengeluar yang hilang dipulihkan kepada kepercayaan yang sama; pendedahan memerlukan identiti baharu dan tiada kembali kepada sauh lama.

Sahkan hasilnya, bukan senarai fail

Fail kepercayaan dalam direktori jangkaan membuktikan sedikit sahaja. Aplikasi mungkin membaca laluan lain, format lain, atau salinan di dalam pakej yang digantikan oleh peningkatan. Periksa tingkah laku di kedua-dua hujung, bukan kewujudan fail.

Sahkan sambungan baharu dengan identiti baharu berjaya, kemudian sahkan identiti yang dikeluarkan oleh CA yang bersara ditolak. Ujian kedua itulah yang orang langkau, dan satu-satunya yang menunjukkan pihak berkuasa lama tidak lagi memberi akses. Di mana penggunaan bergantung pada CRL atau OCSP, periksa bahawa titik pengedaran dalam sijil baharu dapat diselesaikan dan rakan yang bertanya dapat mencapai responden.

Akhiri dengan klien yang tidak pernah bersambung: padam keadaan profilnya, sambungkan dan baca rantaian yang dirundingkan. Rakan yang menyambung semula sesi cache akan dengan gembira melaporkan bahawa migrasi berjaya sedangkan ia tidak mengesahkan apa-apa.