Permintaan kunci OpenVPN setelah OpenSSL 3: periksa penyedianya

Tidak ada yang menyentuh profilnya, tetapi klien yang sama sekarang meminta frasa sandi untuk kunci privat setiap kali mulai. Ketika perubahan itu muncul dalam beberapa hari setelah peningkatan distribusi, peningkatan itulah penyebab yang paling mungkin: OpenSSL 3 menata ulang dukungan algoritmenya, dan kunci yang dulu dibaca lancar oleh pustaka lama bisa menjadi tidak terbaca tanpa satu byte pun berubah. Lakukan pemeriksaan secara berurutan, karena dua di antaranya tampak identik bila hanya melihat permintaannya.

Pertanyaan pertama adalah apakah kuncinya terenkripsi, dan yang kedua adalah apakah build ini dapat mendekripsinya. Perubahan konfigurasi baru masuk akal setelah kedua jawaban diketahui.

Periksa apakah kuncinya terenkripsi

Baca baris pertama berkas lalu biarkan pustaka mengurainya, karena nama berkas tidak membuktikan apa pun. Blok PEM berlabel ENCRYPTED PRIVATE KEY adalah PKCS#8 terenkripsi, dan blok RSA PRIVATE KEY yang lebih lama yang membawa Proc-Type: 4,ENCRYPTED adalah bentuk tradisional, dan keduanya mengharapkan frasa sandi. Blok PRIVATE KEY yang tidak terenkripsi seharusnya tidak meminta sama sekali. Jalankan penguraian sebagai akun yang memiliki berkas itu, karena masalah izin menghasilkan galat yang berbeda dan jauh kurang menarik.

Jika kuncinya benar-benar tidak terenkripsi dan klien tetap meminta, berhentilah melihat kriptografi dan periksa apakah profil menyebut berkas askpass yang masih dapat dibaca layanan.

Periksa apakah build ini dapat mendekripsinya

OpenSSL 3 memisahkan dukungan algoritmenya ke dalam penyedia, dan sekumpulan sandi lama kini berada di penyedia legacy, bukan di penyedia bawaan. Kunci yang dienkripsi dengan salah satu sandi itu tetap sah, tetapi pustaka yang dimuat tanpa penyedia legacy tidak dapat mendekodenya. Pada sebagian klien hal itu tampak sebagai permintaan yang berulang, pada klien lain sebagai kegagalan keras tepat setelah frasa sandi.

Uraikan kunci yang sama dua kali dengan biner yang sama: pertama hanya dengan penyedia bawaan, lalu dengan legacy dan bawaan sama-sama diminta pada baris perintah. Jika percobaan kedua berhasil di tempat percobaan pertama gagal, diagnosis berpijak pada bukti, bukan pada waktu peningkatan. Jika keduanya gagal dengan cara yang sama, frasa sandinya salah atau berkasnya rusak, dan tidak ada pengaturan penyedia yang memperbaiki keduanya.

Periksa perbaikan paling sempit yang tersedia

Utamakan perubahan yang dibatasi pada klien daripada yang berlaku seluruh sistem. Sebagian build 2.6 menerima opsi profil yang memuat kedua penyedia untuk proses daemon itu, jadi pastikan direktifnya dalam manual untuk versi Anda yang tepat sebelum bergantung padanya; menyunting openssl.cnf sistem justru memengaruhi setiap program OpenSSL di host. Pengaturan yang lebih sempit juga jauh lebih mudah dibatalkan setelah kuncinya dikodekan ulang.

Jangan hapus frasa sandi agar permintaannya hilang. Itu mengubah kredensial yang terlindungi menjadi berkas teks biasa dan diam-diam mengubah risiko setiap cadangan, salinan, dan bundel dukungan tempat ia muncul. Pembedaan yang penting adalah antara kunci yang memerlukan frasa sandinya dan kunci yang tidak dapat didekode pustaka ini.

Periksa konteks layanan, lalu enkode ulang

Setelah kunci dapat dibuka, enkripsi ulang dengan algoritme terkini agar ketergantungannya hilang. Tulis berkas baru dengan sandi modern, verifikasi bahwa ia terurai, perbarui profil, dan simpan salinan lama hanya sampai koneksi berhasil. Jangan pernah meletakkan frasa sandi pada baris perintah, tempat setiap pengguna lokal dapat membacanya dari daftar proses. Hapus berkas lama hanya setelah yang baru tersambung dari akun layanan, bukan hanya dari shell Anda.

Lalu periksa unit yang benar-benar menjalankan klien. Kunci yang terbaca di shell Anda bisa jadi tidak terbaca bagi layanan yang berjalan di bawah akun lain atau dengan pengaturan direktori rumah yang diperketat.

Catat pengaturan penyedia di samping profil dan simpan uji dua perintah bersamanya. Ketika peningkatan berikutnya menghapus penyedia legacy, jalankan lagi uji itu untuk melihat apakah kuncinya masih memerlukannya atau profilnya dapat dilepas dari akal-akalan ini.

Permintaan adalah gejala dengan setidaknya tiga penyebab, dan hanya satu di antaranya frasa sandi yang hilang.