Dua dakwaan berlegar dalam perbincangan sijil. Yang pertama ialah .p12 pilihan yang kukuh dan .pem yang longgar; yang kedua ialah fail teks mesti selamat dihantar kerana anda boleh membacanya. Kedua-duanya tidak bertahan seminit pemeriksaan.

PKCS12, PEM dan DER menerangkan cara objek sijil dibungkus dan dikodkan. Ia tidak menentukan siapa rakan sebaya, sama ada pengeluar dipercayai atau sama ada fail memerlukan kata laluan.

Apa yang klien terima ialah soal keserasian. Apa yang terkandung dalam fail ialah soal identiti. Asingkan kedua-duanya dan kebanyakan ralat import berhenti menjadi misteri.

Tiga bekas, satu model objek

Mulakan dengan apa yang benar-benar anda miliki. Sijil ialah pernyataan bertandatangan tentang kunci awam. Kunci peribadi ialah bahan berasingan yang membuktikan anda mengawal kunci itu. Rantaian ialah set pengeluar yang menghubungkan sijil anda dengan akar yang dipercayai klien. Ketiga-tiganya wujud tanpa mengira pembungkusan.

Fail PKCS12, biasanya .p12 atau .pfx, ialah bekas yang ditakrifkan dalam RFC 7292 yang boleh membawa kunci peribadi, satu atau lebih sijil dan rantaian dalam satu blok dilindungi kata laluan, dengan alias yang menamakan identiti. Fail PEM ialah rangka teks yang ditakrifkan dalam RFC 7468: badan base64 antara baris BEGIN dan END, dan satu fail boleh memegang beberapa blok berturut-turut. DER ialah pengekodan binari struktur ASN.1 yang sama, dan badan PEM secara literal ialah DER yang dibalut base64.

Ayat terakhir itu wajar diingat. Menukar PEM kepada DER menulis semula rangka, bukan kandungan, dan menukar balik mengembalikan bait asal.

ContainerCan holdDoes not decide
PKCS12 (.p12, .pfx)Key, leaf certificate, chain, alias, passwordWhich root the client trusts
PEM (.pem, .crt, .cer)Any number of base64 blocksWhether the private key is present
DER (.der, .cer)One binary structureThe object type, whatever the extension says

Pengekodan bukan penyulitan

base64 ialah abjad pengangkutan. Ia tidak menyembunyikan apa-apa, dan sesiapa boleh menyahkod blok PEM dalam shell. Fail DER adalah binari dan sama awamnya. Tiada satu sifat pun ialah perlindungan, dan tiada satu pun membayangkan kata laluan wujud.

Perlindungan sebenar ada pada bahan kunci. Ikatan PKCS12 boleh menyulitkan kandungannya di bawah kunci terbitan kata laluan. Kunci peribadi PEM boleh disulitkan dengan blok pengepala lama atau disimpan dalam PKCS#8 EncryptedPrivateKeyInfo. Sijil sahaja tidak menyimpan apa-apa rahsia, sebab itu eksport yang hanya menghasilkan sijil membuat klien tidak dapat mengesahkan identiti, apa jua format yang anda balut.

Sambungan ialah petunjuk, bukan kontrak. Fail berakhir dengan .cer dan .crt muncul dalam kedua-dua pengekodan, dan peralatan cukup kerap mengeksport sijil DER dengan nama .pem sehingga meneka daripada akhiran menghabiskan satu petang. Baca bait pertama pula: fail PEM dibuka dengan baris BEGIN, manakala DER bermula dengan 0x30 kerana struktur luar ialah SEQUENCE.

Mengapa import sebenarnya gagal

Mesej ralat klien memampatkan beberapa masalah berbeza menjadi satu ayat tentang sijil tidak sah, jadi asingkan mengikut punca. Yang paling biasa ialah ketidakpadanan pengekodan: klien yang menghurai PEM memulangkan ralat hurai pada fail DER, dan pembetulannya ialah penukaran, bukan sijil baharu. Yang kedua ialah kunci hilang, apabila sijil betul dan identiti tidak dapat dibuktikan. Yang ketiga ialah rantaian, apabila ikatan tanpa sijil perantaraan kelihatan betul dalam dialog import dan gagal semasa jabat tangan.

Parameter penyulitan menyebabkan yang keempat, dan ia kelihatan tepat seperti kata laluan salah. Peralatan lama mengeksport fail PKCS12 dengan RC2-40 dan 3DES, yang ditolak OpenSSL 3 melainkan penyedia legacy dimuatkan. Eksport semula daripada peralatan dengan AES-256-CBC dan PBKDF2 ialah pembetulan tahan lama. Membiarkan sifer lama dihidupkan secara kekal pada mesin klien demi satu fail ialah tawaran buruk.

Yang kelima ialah kekaburan. Bekas yang memegang dua kunci dan dua sijil, atau fail PEM dengan tiga blok CERTIFICATE, memaksa klien memilih, dan pilihannya selalunya hanya item pertama. Apabila terowong naik dengan identiti salah, itu biasanya puncanya.

Periksa sebelum menukar

Baca struktur tanpa mencetak rahsia. openssl pkcs12 -in bundle.p12 -info -noout melaporkan algoritma penyulitan dan alias sambil menekan output kunci dan sijil, dan manual openssl-pkcs12 mendokumenkan bendera. Membuang -noout dan menambah -nodes adalah untuk menghasilkan fail yang anda mahu simpan, bukan untuk pandangan pantas, kerana ia menulis kunci peribadi secara terbuka.

Untuk sijil, openssl x509 -in cert.pem -noout -subject -issuer -dates menjawab apa yang tidak akan dijawab dialog import, dan menambah -ext subjectAltName menunjukkan nama yang benar-benar sah untuk sijil itu. Jika fail ialah DER, tambah -inform DER; satu bendera itu menyelesaikan kebanyakan ralat unable-to-load.

Memadankan kunci dengan sijil adalah mekanikal, dan wajar dilakukan sebelum sebarang import:

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

Digest yang sama bermakna pasangan itu memang berpasangan. Digest yang berbeza bermakna anda mempunyai kunci yang salah, dan tiada penukaran format akan mengubahnya.

Apa yang tidak pernah diubah format

Keputusan kepercayaan berlaku di atas bekas. Klien menelusuri rantaian ke akar dalam storannya, memeriksa tetingkap kesahan, memeriksa penggunaan kunci lanjutan untuk pengesahan klien, dan di sebelah pelayan memeriksa bahawa nama yang didail muncul dalam sijil. Tiada satu langkah itu membaca sambungan fail.

Sebab itulah menamakan semula fail sehingga ralat hilang menjadi cara yang sangat boleh dipercayai untuk membuang masa. Import berjaya, identiti masih salah, dan kegagalan muncul semula semasa jabat tangan apabila mesejnya kurang membantu. Itu juga sebabnya ikatan yang dieksport dua tahun lalu diimport dengan bersih dan tetap ditolak: tarikh luput mengembara di dalam sijil, bukan dalam nama fail.

Urutan yang mengelakkan kerja semula

Tanya dokumentasi klien pengekodan mana yang diterima dan bekas apa yang dijangka untuk identiti klien, kemudian lihat apa yang diberikan kepada anda. Jika klien mahu satu identiti yang boleh diimport dan anda mempunyai fail PEM berasingan, bina ikatan sekali dengan kata laluan yang anda kawal dan simpan sumbernya. Jika ia mahu PEM, ekstrak kunci dan rantaian, kemudian hapuskan fail perantaraan melalui proses pengendalian kelayakan yang pasukan anda sudah gunakan.

Selepas import, sahkan identiti dan bukan dialog: subjek, pengeluar, luput dan nama yang akan dibentangkan klien. Nama mesra dalam senarai ialah label, bukan identiti yang disahkan. Jika terowong kemudian gagal, anda menyahpepijat pengesahan atau penghalaan dan bukan pembungkusan, yang merupakan perbualan jauh lebih pendek.

Artikel berkaitan