PKCS12, PEM, atau DER: apa yang sebenarnya dibutuhkan klien VPN

Dua klaim beredar di diskusi sertifikat. Yang pertama, .p12 adalah opsi yang kuat dan .pem yang longgar; yang kedua, file teks harus aman dikirim karena Anda bisa membacanya. Tidak ada yang bertahan satu menit pemeriksaan.

PKCS12, PEM, dan DER menjelaskan bagaimana objek sertifikat dikemas dan dikodekan. Mereka tidak menentukan siapa rekanannya, apakah penerbitnya tepercaya, atau apakah file memerlukan kata sandi.

Apa yang diterima klien adalah soal kompatibilitas. Apa yang ada di dalam file adalah soal identitas. Pisahkan keduanya dan sebagian besar galat impor berhenti menjadi misterius.

Tiga wadah, satu model objek

Mulailah dari apa yang benar-benar Anda miliki. Sertifikat adalah pernyataan bertanda tangan tentang kunci publik. Kunci privat adalah materi terpisah yang membuktikan Anda mengendalikan kunci itu. Rantai adalah himpunan penerbit yang menautkan sertifikat Anda ke akar yang dipercaya klien. Ketiganya ada terlepas dari pengemasan.

Berkas PKCS12, biasanya .p12 atau .pfx, adalah wadah yang didefinisikan dalam RFC 7292 yang dapat membawa kunci privat, satu atau beberapa sertifikat, dan rantai dalam satu gumpalan yang dilindungi kata sandi, dengan alias yang menamai identitas. Berkas PEM adalah pembingkaian teks yang didefinisikan dalam RFC 7468: badan base64 di antara baris BEGIN dan END, dan satu berkas dapat memuat beberapa blok berurutan. DER adalah pengodean biner struktur ASN.1 yang sama, dan badan PEM secara harfiah adalah DER yang dibungkus base64.

Kalimat terakhir itu layak diingat. Mengubah PEM menjadi DER menulis ulang pembingkaiannya, bukan isinya, dan mengubahnya kembali mengembalikan bita aslinya.

Pengodean bukan enkripsi

base64 adalah abjad transportasi. Ia tidak menyembunyikan apa pun, dan siapa pun dapat mendekode blok PEM di shell. Berkas DER bersifat biner dan sama publiknya. Tidak satu pun sifat itu merupakan perlindungan, dan tidak satu pun menyiratkan adanya kata sandi.

Perlindungan sebenarnya ada pada materi kunci. Bundel PKCS12 dapat mengenkripsi isinya di bawah kunci yang diturunkan dari kata sandi. Kunci privat PEM dapat dienkripsi dengan blok tajuk lama atau disimpan di PKCS#8 EncryptedPrivateKeyInfo. Sertifikat saja tidak menyimpan apa pun yang rahasia, karena itu ekspor yang hanya menghasilkan sertifikat membuat klien tidak dapat mengautentikasi, apa pun format yang Anda bungkus.

Ekstensi adalah petunjuk, bukan kontrak. Berkas berakhiran .cer dan .crt muncul di kedua pengodean, dan peralatan cukup sering mengekspor sertifikat DER dengan nama .pem sehingga menebak dari akhiran menghabiskan satu sore. Baca bita pertama saja: berkas PEM dibuka dengan baris BEGIN, sedangkan DER dimulai dengan 0x30 karena struktur luarnya adalah SEQUENCE.

Mengapa impor sebenarnya gagal

Pesan galat klien memadatkan beberapa masalah berbeda ke dalam satu kalimat tentang sertifikat tidak valid, jadi pisahkan berdasarkan penyebab. Yang paling umum adalah ketidakcocokan pengodean: klien yang mengurai PEM mengembalikan galat penguraian pada berkas DER, dan perbaikannya adalah konversi, bukan sertifikat baru. Yang kedua adalah kunci yang hilang, ketika sertifikatnya baik dan identitas tidak dapat dibuktikan. Yang ketiga adalah rantai, ketika bundel tanpa sertifikat perantaranya terlihat benar di dialog impor dan gagal saat jabat tangan.

Parameter enkripsi menyebabkan yang keempat, dan tampaknya persis seperti kata sandi yang salah. Peralatan lama mengekspor berkas PKCS12 dengan RC2-40 dan 3DES, yang ditolak OpenSSL 3 kecuali penyedia legacy dimuat. Mengekspor ulang dari peralatan dengan AES-256-CBC dan PBKDF2 adalah perbaikan yang tahan lama. Membiarkan sandi lama aktif permanen di mesin klien demi satu berkas adalah pertukaran yang buruk.

Yang kelima adalah ketaksaan. Wadah berisi dua kunci dan dua sertifikat, atau berkas PEM dengan tiga blok CERTIFICATE, memaksa klien memilih, dan pilihannya sering kali hanya item pertama. Ketika terowongan naik dengan identitas yang salah, biasanya itulah penyebabnya.

Periksa sebelum mengonversi

Baca strukturnya tanpa mencetak rahasia. openssl pkcs12 -in bundle.p12 -info -noout melaporkan algoritme enkripsi dan alias sambil menekan keluaran kunci dan sertifikat, dan manual openssl-pkcs12 mendokumentasikan flag-nya. Membuang -noout dan menambahkan -nodes adalah untuk menghasilkan berkas yang hendak Anda simpan, bukan untuk melihat sekilas, karena perintah itu menulis kunci privat secara terbuka.

Untuk sertifikat, openssl x509 -in cert.pem -noout -subject -issuer -dates menjawab apa yang tidak akan dijawab dialog impor, dan menambahkan -ext subjectAltName memperlihatkan nama-nama yang benar-benar valid untuk sertifikat itu. Jika berkasnya DER, tambahkan -inform DER; satu flag itu menyelesaikan sebagian besar galat unable-to-load.

Mencocokkan kunci dengan sertifikat bersifat mekanis, dan layak dilakukan sebelum impor apa pun:

openssl x509 -in cert.pem -noout -pubkey | openssl sha256
openssl pkey -in key.pem -pubout | openssl sha256

Intisari yang identik berarti pasangan itu memang berpasangan. Intisari yang berbeda berarti kunci Anda salah, dan tidak ada konversi format yang mengubahnya.

Apa yang tidak pernah diubah format

Keputusan kepercayaan terjadi di atas wadah. Klien menelusuri rantai ke akar di penyimpanannya, memeriksa jendela validitas, memeriksa penggunaan kunci yang diperluas untuk autentikasi klien, dan di sisi server memeriksa bahwa nama yang dipanggilnya muncul di sertifikat. Tidak satu pun langkah itu membaca ekstensi berkas.

Itulah sebabnya mengganti nama berkas sampai galat hilang menjadi cara yang sangat andal untuk membuang waktu. Impor berhasil, identitasnya tetap salah, dan kegagalan muncul lagi saat jabat tangan ketika pesannya kurang membantu. Itu juga sebabnya bundel yang diekspor dua tahun lalu terimpor dengan bersih dan tetap ditolak: tanggal kedaluwarsa berkelana di dalam sertifikat, bukan di nama berkas.

Urutan yang menghindari pengerjaan ulang

Tanyakan kepada dokumentasi klien pengodean mana yang diterima dan wadah apa yang diharapkan untuk identitas klien, lalu lihat apa yang diberikan kepada Anda. Jika klien menginginkan satu identitas yang dapat diimpor dan Anda memiliki berkas PEM terpisah, bangun bundelnya sekali dengan kata sandi yang Anda kendalikan dan simpan sumbernya. Jika ia menginginkan PEM, ekstrak kunci dan rantainya, lalu hapus berkas perantaranya melalui proses penanganan kredensial yang sudah dipakai tim Anda.

Setelah impor, verifikasi identitasnya, bukan dialognya: subjek, penerbit, kedaluwarsa, dan nama yang akan ditampilkan klien. Nama ramah dalam daftar adalah label, bukan identitas terverifikasi. Jika terowongan kemudian gagal, Anda men-debug autentikasi atau perutean alih-alih pengemasan, yang merupakan percakapan jauh lebih singkat.