Apa yang Terjadi Saat Anda Mengganti Otoritas Sertifikat VPN

Mengganti otoritas sertifikat VPN bukan tukar berkas. Begitu CA baru menandatangani sertifikat pertamanya, setiap validator yang masih hanya memercayai yang lama harus mengambil keputusan, dan host yang tidak pernah menerima jangkar baru terus menolak peer yang sah. Saya telah melihatnya gagal di kedua arah: gateway mempelajari CA baru sedangkan klien tidak, sehingga koneksi baru gagal, sementara tunnel yang sudah hidup tetap hidup dan membuat gangguan tampak seperti masalah routing. Berikut yang berubah, sesuai urutan munculnya kegagalan.

Satu penggantian, dua perubahan terpisah

Otoritas sertifikat adalah sebuah nama, kunci publik, dan kunci privat yang menandatangani. Validator tidak pernah memercayai «CA» secara abstrak. Mereka memercayai satu sertifikat tertentu yang sudah ada di penyimpanan kepercayaan, dan menerima penerbit hanya jika rantai tanda tangan mencapai salinan tersimpan itu. Karena itu mengganti CA mengubah dua hal yang gagal secara terpisah: jangkar mana yang diterima dan identitas peer mana yang diterbitkan di bawahnya.

Sebagian besar penerapan VPN memvalidasi di kedua arah. Klien mengautentikasi sertifikat gateway, dan gateway mengautentikasi sertifikat klien. Rotasi yang hanya menyegarkan bundel klien membuat server menolak setiap klien yang masih menyajikan identitas dari CA lama, dan sebaliknya sama lazimnya. Inventarisasi dulu titik penegakannya: penyimpanan kepercayaan klien, berkas ca gateway, proksi yang mengakhiri TLS di depannya, dan pemeriksaan yang menguji endpoint dari luar.

Apa yang diperiksa validator, berurutan

Validasi jalur naik dari sertifikat peer melalui perantara mana pun sampai mencapai jangkar tepercaya. Pada setiap langkah ia memverifikasi tanda tangan, memeriksa bahwa setiap sertifikat berada di dalam jendela masa berlakunya, dan memastikan batasan dasar serta penggunaan kunci mengizinkan penerbit menandatangani. Baru setelah itu aplikasi melihat sertifikat daun: nama alternatif subjek harus mencakup nama yang dipanggil, dan penggunaan kunci yang diperluas harus mengizinkan autentikasi server atau klien.

Untuk mengulang penelusuran itu secara offline, arahkan -CAfile ke bundel persis yang akan Anda terapkan, bukan ke penyimpanan sistem. Kalau tidak, Anda menguji host, bukan perubahannya:

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 bekerja terhadap pendengar TLS biasa seperti halaman admin HTTPS gateway; kanal kontrol OpenVPN mendahului TLS, jadi s_client tidak dapat memeriksa jabat tangan tunnel.

Aturan pembentukan jalur di balik kesalahan itu ada di RFC 5280 bagian 6. Aturan itu menjelaskan kegagalan yang jika tidak tampak sewenang-wenang: perantara kedaluwarsa yang tidak diingat siapa pun, sertifikat yang penggunaan kuncinya melarang penandatanganan, atau batasan nama yang mengecualikan host yang Anda uji.

Mengapa tunnel lama tetap bekerja

TLS dan OpenVPN keduanya menjaga sesi yang sudah terbentuk tetap hidup setelah jabat tangan selesai. Tidak ada yang memvalidasi ulang sertifikat peer per paket, jadi klien yang terhubung sebelum perubahan terus melewatkan lalu lintas sampai ia bernegosiasi ulang, tersambung ulang, atau tunnel jatuh. Celah itulah sebabnya penggantian CA bisa tampak baik selama satu jam lalu gagal pada saat terburuk: laptop bangun dari tidur, pemetaan NAT kedaluwarsa, gateway memulai ulang.

Pelanjutan sesi lebih meregangkan ilusi itu. Tiket sesi TLS memungkinkan klien kembali tanpa mengirim ulang sertifikat, dan pelanjutan melewati validasi jalur karena jabat tangan pertama sudah melakukannya. Jadi uji yang jujur adalah jabat tangan penuh di proses baru. Mulai ulang klien alih-alih menyambungkan ulang tunnel, dan pada profil uji pertimbangkan menonaktifkan tiket agar jalur pelanjutan tidak dapat menyembunyikan rantai yang rusak.

Jaga lapisan kunci statis terpisah dari ini. tls-auth menambahkan HMAC ke kanal kontrol, tls-crypt mengenkripsi dan mengautentikasinya, dan keduanya tidak membawa materi sertifikat, jadi merotasi salah satunya adalah perubahan terpisah dengan mode kegagalannya sendiri. Penerapan yang mencampur keduanya berakhir dengan klien yang kunci statisnya baik, sertifikatnya usang, dan pesan galatnya tidak menyebut keduanya.

Jebakan penggunaan ulang nama subjek

Menggoda untuk menggunakan ulang nama terbedakan pendahulunya agar tidak ada yang perlu berubah di hilir. Itu menjaga baris penerbit tetap stabil di antarmuka dan menghancurkan satu-satunya sinyal yang Anda butuhkan. Dua sertifikat dengan subjek identik dan kunci berbeda tidak dapat dibedakan berdasarkan nama, jadi bundel yang memuat kedua jangkar memberi validator dua kandidat dan tanpa aturan untuk memilih.

Pembentukan jalur lalu dapat memilih yang salah, melaporkan «tidak dapat memperoleh sertifikat penerbit lokal» padahal jangkar yang benar ada, atau berhasil pada satu host dan gagal pada host lain dengan bundel yang sama, karena urutan kandidatnya berbeda. Jika nama harus digunakan ulang, simpan kedua jangkar dalam berkas terpisah selama transisi dan muat secara eksplisit, lalu gabungkan hanya setelah setiap peer menyajikan penerbit baru. Jika tidak, beri pengganti nama umum yang berbeda — akhiran generasi atau tanggal cukup — agar log dan teks galat menyebut otoritas mana yang menerbitkan peer yang gagal.

Rotasi yang tidak menjatuhkan jaringan

Untuk penggantian terencana, terima kedua jangkar selama jendela terbatas alih-alih beralih dalam satu langkah. Terbitkan CA baru dan perantaranya, letakkan jangkar baru di bundel setiap validator di samping yang lama, dan baru setelah itu mulai menerbitkan sertifikat peer darinya. Peer dengan identitas lama memvalidasi terhadap jangkar lama; yang baru bekerja terhadap jangkar baru.

Dilakukan dalam urutan itu, setiap langkah dapat dibalik. Kegagalan yang Anda hindari adalah peralihan serentak, ketika klien yang melewatkan pembaruan bundel bertemu gateway yang sudah memensiunkan jangkar lama, jabat tangan mati, dan tidak ada log yang menyebut sisi mana yang usang.

Pensiunkan ke arah sebaliknya. Terbitkan ulang setiap identitas yang harus bertahan, pastikan masing-masing menyajikan rantai baru, lalu hapus jangkar lama dari bundel. Cabut kunci privat CA lama dari layanan, karena penerbit yang masih bisa menandatangani berarti rotasi belum selesai. Simpan sertifikat dan catatan penerbitan untuk audit. Penerbit yang hilang dipulihkan ke kepercayaan yang sama; paparan menuntut identitas baru dan tanpa kembali ke jangkar lama.

Verifikasi hasilnya, bukan daftar berkasnya

Berkas kepercayaan di direktori yang diharapkan tidak membuktikan banyak. Aplikasi mungkin membaca jalur lain, format lain, atau salinan di dalam paket yang diganti oleh peningkatan versi. Periksa perilaku di kedua ujung, bukan keberadaan berkas.

Pastikan koneksi baru dengan identitas baru berhasil, lalu pastikan identitas yang diterbitkan CA pensiun ditolak. Uji kedua itulah yang dilewatkan orang, dan satu-satunya yang menunjukkan otoritas lama tidak lagi memberi akses. Bila penerapan bergantung pada CRL atau OCSP, periksa bahwa titik distribusi di sertifikat baru dapat diselesaikan dan peer yang bertanya dapat menjangkau penjawabnya.

Akhiri dengan klien yang belum pernah terhubung: hapus keadaan profilnya, sambungkan, dan baca rantai yang dinegosiasikan. Peer yang melanjutkan sesi tersimpan akan dengan gembira melaporkan bahwa migrasi berhasil padahal ia tidak memvalidasi apa pun.