PKCS12, PEM və ya DER: VPN müştərisinə əslində nə lazımdır

Sertifikat müzakirələrində iki iddia dolaşır. Birincisi, .p12 güclü variantdır, .pem isə zəif; ikincisi, mətn faylı oxuna bildiyi üçün göndərilməsi təhlükəsiz olmalıdır. Heç biri bir dəqiqəlik yoxlamaya tab gətirmir.

PKCS12, PEM və DER sertifikat obyektlərinin necə qablaşdırıldığını və kodlaşdırıldığını təsvir edir. Onlar qarşı tərəfin kim olduğunu, buraxanın etibarlı olub-olmadığını və ya faylın parol tələb edib-etmədiyini müəyyən etmir.

Müştərinin nə qəbul etməsi uyğunluq məsələsidir. Faylın nə ehtiva etməsi kimlik məsələsidir. Bunları ayırsanız, idxal xətalarının çoxu sirrini itirir.

Üç konteyner, bir obyekt modeli

Əslində nəyiniz olduğu ilə başlayın. Sertifikat açıq açar haqqında imzalanmış bəyanatdır. Şəxsi açar həmin açarı idarə etdiyinizi sübut edən ayrı materialdır. Zəncir sertifikatınızı müştərinin etibar etdiyi kökə bağlayan buraxanlar toplusudur. Hər üçü qablaşdırmadan asılı olmayaraq mövcuddur.

PKCS12 faylı, adətən .p12 və ya .pfx, RFC 7292-də müəyyən edilmiş konteynerdir və şəxsi açarı, bir və ya bir neçə sertifikatı və zənciri bir parolla qorunan blokda daşıya bilər; kimliyi adlandıran alias da var. PEM faylı RFC 7468-də müəyyən edilmiş mətn çərçivəsidir: BEGIN və END sətirləri arasında base64 gövdəsi və bir fayl ardıcıl olaraq bir neçə blok saxlaya bilər. DER eyni ASN.1 strukturlarının binar kodlaşdırmasıdır, PEM gövdəsi isə sözün əsl mənasında base64 ilə bükülmüş DER-dir.

Son cümlə saxlanmağa dəyər. PEM-i DER-ə çevirmək çərçivəni yenidən yazır, məzmunu yox, və geri çevirmə orijinal baytları qaytarır.

Kodlaşdırma şifrələmə deyil

Base64 nəql əlifbasıdır. Heç nəyi gizlətmir və hər kəs PEM blokunu shell-də aça bilər. DER faylı binardır və eyni dərəcədə açıqdır. Heç biri mühafizə deyil və heç biri parolun olduğunu bildirmir.

Əsl mühafizə açar materialındadır. PKCS12 paketi məzmununu paroldan törəmə açarla şifrələyə bilər. PEM şəxsi açarı köhnə başlıq bloku ilə şifrələnə və ya PKCS#8 EncryptedPrivateKeyInfo içində saxlanıla bilər. Sertifikat təkbaşına heç bir sirr saxlamır, buna görə yalnız sertifikat çıxaran ixrac müştərini autentifikasiya edə bilməz, onu hansı formata büksəniz də.

Uzantı işarədir, müqavilə deyil. .cer və .crt ilə bitən fayllar hər iki kodlaşdırmada görünür və cihazlar DER sertifikatlarını o qədər tez-tez .pem adı ilə ixrac edir ki, şəkilçidən təxmin etmək bir günortanı itirir. Əvəzində ilk baytlara baxın: PEM faylı BEGIN sətri ilə açılır, DER isə 0x30 ilə başlayır, çünki xarici struktur SEQUENCE-dir.

İdxal əslində niyə uğursuz olur

Müştəri xəta mesajları bir neçə fərqli problemi etibarsız sertifikat haqqında bir cümleyə sıxır, ona görə onları səbəbə görə ayırın. Ən geniş yayılanı kodlaşdırma uyğunsuzluğudur: PEM-i parslayan müştəri DER faylında parse xətası qaytarır və düzəliş yeni sertifikat deyil, çevirmədir. İkincisi çatışmayan açardır; sertifikat qaydasındadır, kimliyi sübut etmək mümkün deyil. Üçüncüsü zəncirdir; aralıq sertifikatı olmayan paket idxal pəncərəsində düzgün görünür və əl sıxma zamanı uğursuz olur.

Şifrələmə parametrləri dördüncüsünü yaradır və o, tam səhv parol kimi görünür. Köhnə cihazlar PKCS12 fayllarını RC2-40 və 3DES ilə ixrac edirdi; OpenSSL 3 bunları legacy provayder yüklənmədən rədd edir. Cihazdan AES-256-CBC və PBKDF2 ilə yenidən ixrac davamlı həlldir. Bir fayl üçün köhnə şifrləri müştəri maşınında daim açıq saxlamaq pis mübadilədir.

Beşincisi qeyri-müəyyənlikdir. İki açar və iki sertifikat saxlayan konteyner və ya üç CERTIFICATE bloku olan PEM faylı müştərini seçim etməyə məcbur edir və onun seçimi çox vaxt sadəcə birinci elementdir. Tunel səhv kimliklə qalxanda səbəb adətən budur.

Çevirməzdən əvvəl yoxlayın

Strukturu sirləri çap etmədən oxuyun. openssl pkcs12 -in bundle.p12 -info -noout şifrələmə alqoritmlərini və aliasları bildirir, açar və sertifikat çıxışını isə susdurur, və openssl-pkcs12 təlimatı bayraqları sənədləşdirir. -noout-u atmaq və -nodes əlavə etmək saxlayacağınız faylları yaratmaq üçündür, qısa baxış üçün deyil, çünki şəxsi açarı açıq şəkildə yazır.

Sertifikat üçün openssl x509 -in cert.pem -noout -subject -issuer -dates idxal pəncərəsinin cavab vermədiyini cavablandırır, -ext subjectAltName əlavə etmək isə sertifikatın həqiqətən etibarlı olduğu adları göstərir. Fayl DER-dirsə, -inform DER əlavə edin; bu tək bayraq yüklənə bilməyən xətaların çoxunu həll edir.

Açarı sertifikata uyğunlaşdırmaq mexaniki işdir və hər hansı idxaldan əvvəl etməyə dəyər:

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

Eyni dayjestlər cütün bir-birinə aid olduğunu bildirir. Fərqli dayjestlər səhv açara sahib olduğunuzu bildirir və heç bir format çevirməsi bunu dəyişməz.

Formatın heç vaxt dəyişmədiyi şeylər

Etibar qərarları konteynerin üstündə verilir. Müştəri zənciri öz anbarındakı kökə qədər gedir, etibarlılıq pəncərəsini yoxlayır, müştəri autentifikasiyası üçün genişləndirilmiş açar istifadəsini yoxlayır və server tərəfində zəng etdiyi adın sertifikatda göründüyünü yoxlayır. Bu addımların heç biri fayl uzantısını oxumur.

Buna görə faylı xəta yox olana qədər adlandırmaq vaxt itirməyin belə etibarlı yoludur. İdxal uğurlu olur, kimlik yenə səhvdir və uğursuzluq əl sıxma zamanı daha az faydalı mesajla qayıdır. Buna görə də iki il əvvəl ixrac edilmiş paket təmiz idxal olunur və yenə də rədd edilir: bitmə tarixi fayl adında deyil, sertifikatın içində səyahət edib.

Təkrar işdən qaçan bir sıra

Müştərinin sənədlərindən hansı kodlaşdırmaları qəbul etdiyini və müştəri kimliyi üçün hansı konteyner gözlədiyini soruşun, sonra sizə verilənə baxın. Müştəri tək idxal edilə bilən kimlik istəyirsə və sizdə ayrı PEM faylları varsa, paketi bir dəfə özünüz nəzarət etdiyiniz parolla qurun və mənbələri saxlayın. PEM istəyirsə, açarı və zənciri çıxarın, sonra aralıq faylları komandanızın artıq istifadə etdiyi etimadnamə idarəetmə prosesi ilə silin.

İdxaldan sonra dialoqu deyil, kimliyi yoxlayın: subyekt, buraxan, bitmə tarixi və müştərinin təqdim edəcəyi ad. Siyahıdakı dost ad etiketdir, təsdiqlənmiş kimlik deyil. Tunel bundan sonra uğursuz olursa, qablaşdırma yerinə autentifikasiya və ya marşrutlaşdırmanı ayıqlayırsınız, bu isə daha qısa söhbətdir.