P12 lama gagal di OpenSSL 3: kata sandi salah atau cipher lama?
Bedakan frasa sandi yang salah ketik dari bundel RC2 lama yang menolak dibuka OpenSSL 3, lalu segel ulang berkasnya tanpa melepas perlindungan kunci.
Dialog impor mengambil kata sandi Anda, berputar sesaat, lalu menyatakan tidak dapat membaca bundel itu. Tidak ada yang memberi tahu Anda apakah Anda salah mengetik frasa sandi atau berkas itu disegel dengan cipher yang tidak lagi disertakan klien. Keduanya kegagalan berbeda dengan perbaikan berbeda, dan pilihan yang salah berujung pada penurunan versi klien yang hanya menunda keputusan. Mengamati tahap tempat klien berhenti memisahkan keduanya dalam sekitar satu menit.
Apa yang terjadi antara dialog dan daftar sertifikat
Berkas .p12 adalah wadah, bukan sertifikat. Di dalamnya ada satu atau beberapa kantong sertifikat dan kantong kunci privat yang dienkripsi dengan kunci turunan dari kata sandi Anda, ditambah pemeriksaan integritas bernama MAC atas seluruh berkas. Membukanya berarti memverifikasi MAC itu, mendekripsi kantong kunci, dan mencocokkan sertifikat dengan kunci yang keluar darinya.
Masalah kata sandi muncul pada tahap MAC. Masalah cipher muncul kemudian, ketika kantong kunci harus dibuka dan build yang membukanya tidak memiliki implementasi algoritme yang disebut dalam berkas.
Kasus kedua umum pada sistem saat ini karena OpenSSL 3 memindahkan sekelompok algoritme lama ke penyedia legacy opsional. Bundel yang diekspor OpenSSL 1.x biasanya menyegel sertifikat dengan RC2 40-bit dan kunci privat dengan Triple DES tiga kunci. Build OpenSSL 3 bawaan masih memverifikasi MAC dengan kata sandi Anda yang benar lalu gagal pada kantong, jadi kata sandinya tidak pernah salah dan mengetik ulang tidak mengubah apa pun.
Baca wadahnya tanpa menuliskan kunci
Minta build OpenSSL di mesin Anda sendiri mengurai berkas itu dan membaca titik tempat ia menyerah. Pemeriksaan tanpa berkas keluaran membiarkan kunci tetap terenkripsi di disk, dan itulah satu-satunya alasan langkah ini aman di host bersama.
openssl pkcs12 -in vpn-identity.p12 -info -nooutPada bundel legacy dengan kata sandi yang benar, ini mencetak atribut kantong lalu berhenti dengan digital envelope routines::unsupported. Dengan kata sandi salah Anda mendapat Mac verify error: invalid password? sebelum kantong mana pun dibaca. Kedua pesan menunjuk ke arah berlawanan, dan itulah tepatnya informasi yang ditahan klien.
Jika kegagalannya adalah yang algoritme tidak didukung, jalankan perintah yang sama lagi dengan -legacy ditambahkan dan tidak ada yang lain diubah. Flag itu memuat penyedia legacy hanya untuk proses itu. Ia tidak membuat klien VPN mengurai bundel lama, tidak menyentuh kebijakan kripto seluruh sistem, dan merupakan pengukuran, bukan perbaikan, karena berkas tetap harus diganti.
Kesalahan mana berarti tahap mana
Tabel singkat memisahkan ketiga hasil, dan kata-katanya lebih penting daripada tempat dialog muncul.
| Text you see | Stage | What it tells you |
|---|---|---|
Mac verify error: invalid password? | Integrity check | Passphrase or cached credential, not the cipher |
digital envelope routines::unsupported | Bag decrypt | Algorithm missing from the default provider |
not enough data / header too long | Container format | Wrong encoding, edited file, or truncated download |
Teks seperti not enough data atau header too long tidak termasuk salah satu dari dua kelompok pertama. Itu masalah format: berkas DER yang diganti namanya menjadi .pem, salinan yang dirusak editor yang menulis ulang akhir baris, atau unduhan tidak lengkap. Bandingkan checksum dengan yang dikirim penerbit sebelum Anda mulai melihat cipher.
Perlakukan Mac verify error hanya sebagai bukti tentang kata sandi. Artinya MAC yang dihitung dari yang Anda ketik tidak cocok dengan nilai tersimpan, yang terjadi karena salah ketik, kata sandi yang di-cache dari impor sebelumnya, atau berkas yang diekspor ulang dengan frasa sandi berbeda. Ia tidak mengatakan apa pun tentang apakah algoritme di dalamnya sudah lama.
Bangun bundel yang benar-benar bisa dibuka klien
Setelah parser legacy memastikan berkasnya sehat, perbaikan permanennya adalah penggantian yang algoritmenya didukung klien tujuan: AES-256-CBC untuk kantong kunci dan sertifikat, PBKDF2 dengan SHA-256 untuk derivasi, dan SHA-256 untuk MAC. Administrator PKI Anda dapat mengekspornya dari materi kunci yang sama, dan sertifikat di dalamnya tetap sertifikat yang sudah dipercaya server Anda.
Bila Anda harus mengonversi secara lokal, minta alat pkcs12 menyegel ulang kantongnya alih-alih membuangnya lebih dulu. Jauhkan kedua frasa sandi dari riwayat shell dengan membacanya dari berkas.
openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
-keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
-passin file:old.pass -passout file:new.passKonversi yang berhasil tidak mengatakan apa pun tentang masa berlaku, penggunaan kunci, kecocokan kunci privat, atau apakah server memercayai rantai penerbit. Pengemasan ulang adalah perubahan transportasi, bukan pembaruan, dan masing-masing hal itu tetap memerlukan pemeriksaannya sendiri.
Lewati resep apa pun yang menulis kunci perantara tanpa perlindungan atau kata sandi keluaran kosong hanya karena klien kemudian menerima berkasnya. Bundel yang terbaca dengan perlindungan terlepas adalah hasil yang lebih buruk daripada kegagalan impor yang Anda mulai.
Pastikan klien mengimpor berkas yang Anda bangun
Penguraian bersih di terminal membuktikan wadahnya valid. Itu tidak membuktikan klien memilihnya, karena profil sisa bisa terus menunjuk ke berkas lama, dan sebagian klien menyimpan identitas yang diimpor dengan nama yang tidak Anda pilih.
Cetak identitas yang akan Anda impor dan bandingkan dengan yang ditampilkan klien di tampilan sertifikatnya.
openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
| openssl x509 -noout -subject -dates -fingerprint -sha256Hapus dulu entri profil yang usang, lalu impor. Jika klien mencatat subjek atau sidik jari yang dimuatnya, cocokkan dengan baris di atas; jika hanya menampilkan nama ramah, periksa tanggal kedaluwarsanya, karena lebih sulit dikacaukan dengan sertifikat lain dari penerbit yang sama.
Referensi PKCS12 mencantumkan opsi penyedia, frasa sandi, dan keluaran yang dipakai di sini. Intinya adalah menjaga penyedia legacy di luar lingkungan klien: ukur dengannya, kirim tanpanya, dan biarkan kunci privat terlindungi di disk.