PKCS12, PEM же DER: VPN кардарына чындыгында эмне керек
Таңуулоо кардар инсандыкты импорттой аларын чечет, анын ишенимдүүлүгүн эмес. PKCS12, PEM жана DERди салыштырып, анан текшериңиз.
Сертификаттар тууралуу талкууларда эки ырастоо жүрөт. Биринчиси — .p12 күчтүү вариант, ал эми .pem алсыз; экинчиси — тексттик файлды жөнөтүү коопсуз болушу керек, анткени аны окуй аласыз. Экөө тең бир мүнөттүк текшерүүгө чыдабайт.
PKCS12, PEM жана DER сертификат объектилеринин кантип таңууланып, коддолорун сүрөттөйт. Алар каршы тарап ким экенин, чыгаруучуга ишенүүгө болобу, файлга сырсөз керекпи — аны чечпейт.
Кардар эмнени кабыл алары — шайкештик маселеси. Файлда эмне бар экени — инсандык маселеси. Ушул экөөнү бөлүп кармаңыз, ошондо импорт каталарынын көбү сырдуу болуудан калат.
Үч контейнер, бир объект модели
Чындыгында колуңузда болгон нерседен баштаңыз. Сертификат — ачык ачкыч тууралуу кол коюлган билдирүү. Жеке ачкыч — ошол ачкычты көзөмөлдөй турганыңызды далилдеген өзүнчө материал. Чынжыр — сертификатыңызды кардар ишенген тамырга байланыштырган чыгаруучулардын жыйындысы. Үчөө тең таңуулоого карабастан бар.
PKCS12 файлы, адатта .p12 же .pfx, RFC 7292де аныкталган контейнер жана жеке ачкычты, бир же бир нече сертификатты жана чынжырды сырсөз менен корголгон бир блокто алып жүрө алат, инсандыкты атаган псевдоним менен. PEM файлы RFC 7468де аныкталган тексттик алкак: BEGIN жана END саптарынын ортосунда base64 дене, жана бир файлда бир нече блок катары менен болушу мүмкүн. DER — ошол эле ASN.1 түзүмдөрүнүн экилик коддолушу, ал эми PEM денеси сөзмө-сөз base64кө оролгон DER.
Акыркы сүйлөм эстеп калууга татыктуу. PEMди DERге айландыруу алкакты кайра жазат, мазмунду эмес, ал эми кайтарганда баштапкы байттар келет.
| Container | Can hold | Does not decide |
|---|---|---|
| PKCS12 (.p12, .pfx) | Key, leaf certificate, chain, alias, password | Which root the client trusts |
| PEM (.pem, .crt, .cer) | Any number of base64 blocks | Whether the private key is present |
| DER (.der, .cer) | One binary structure | The object type, whatever the extension says |
Коддоо шифрлөө эмес
base64 — ташуу алфавити. Ал эч нерсени жашырбайт, жана каалаган адам shellде PEM блогун чече алат. DER файлы экилик жана ушундай эле ачык. Эки касиет тең коргоо эмес, жана экөө тең сырсөз бар экенин билдирбейт.
Чыныгы коргоо ачкыч материалында. PKCS12 бумасы мазмунун сырсөздөн алынган ачкыч менен шифрлей алат. PEM жеке ачкычын эски аталыш блогу менен шифрлөөгө же PKCS#8 EncryptedPrivateKeyInfo ичинде сактоого болот. Сертификат жалгыз эч нерсе жашырбайт, ошондуктан сертификат гана берген экспорт кардарды аутентификациялоо мүмкүнчүлүгүнөн ажыратат, аны кандай форматка ороп койсоңуз да.
Кеңейтүү — белги, келишим эмес. .cer жана .crt менен бүткөн файлдар эки коддоодо тең кездешет, жана түзүлүштөр DER сертификаттарын .pem аттары менен жетишерлик тез-тез чыгарат, ошондуктан уланды боюнча божомолдоо жарым күндү корот. Андай учурда алгачкы байттарды окуңуз: PEM файлы BEGIN сабы менен башталат, ал эми DER 0x30 менен башталат, анткени сырткы түзүм SEQUENCE.
Импорт чындыгында эмнеге ийгиликсиз болот
Кардардын ката билдирүүлөрү бир нече түрдүү маселени жараксыз сертификат тууралуу бир сүйлөмгө кысат, ошондуктан себеби боюнча бөлүңүз. Эң көп кездешкени — коддоо шайкешсиздиги: PEM талдаган кардар DER файлында талдоо катасын кайтарат, ал эми чечим жаңы сертификат эмес, айландыруу. Экинчиси — жок ачкыч, мында сертификат тартибинде, бирок инсандыкты далилдөө мүмкүн эмес. Үчүнчүсү — чынжыр, мында ортолук сертификатсыз бума импорт диалогунда туура көрүнөт да, кол алышуу учурунда ийгиликсиз болот.
Шифрлөө параметрлери төртүнчүсүн пайда кылат, жана ал так туура эмес сырсөзгө окшошот. Эски түзүлүштөр PKCS12 файлдарын RC2-40 жана 3DES менен чыгарчу, аларды OpenSSL 3 legacy провайдери жүктөлбөсө четке кагат. Түзүлүштөн AES-256-CBC жана PBKDF2 менен кайра чыгаруу — туруктуу чечим. Бир файл үчүн кардардын машинасында эски шифрлерди дайыма күйүк кармоо — начар бүтүм.
Бешинчиси — эки маанилүүлүк. Эки ачкыч жана эки сертификаты бар контейнер, же үч CERTIFICATE блогу бар PEM файлы кардарды тандоого мажбурлайт, жана анын тандоосу көбүнчө жөн гана биринчи элемент. Туннель туура эмес инсандык менен көтөрүлсө, адатта себеби ошол.
Айландыруудан мурун текшериңиз
Купуяларды басмай түзүмдү окуңуз. openssl pkcs12 -in bundle.p12 -info -noout шифрлөө алгоритмдерин жана псевдонимдерди билдирет жана ачкыч менен сертификаттын чыгышын басат, ал эми openssl-pkcs12 колдонмосу желекчелерди документтештирет. -nooutту алып салуу жана -nodes кошуу — сактоого жаткан файлдарды түзүү үчүн, тез көз чаптыруу үчүн эмес, анткени ал жеке ачкычты ачык жазат.
Сертификат үчүн openssl x509 -in cert.pem -noout -subject -issuer -dates импорт диалогу жооп бербеген нерсеге жооп берет, ал эми -ext subjectAltName кошуу сертификат чындыгында жарактуу аттарды көрсөтөт. Файл DER болсо, -inform DER кошуңуз; ошол бир желекче unable-to-load каталарынын көбүн чечет.
Ачкычты сертификат менен дал келтирүү механикалык иш жана ар кандай импорттон мурун жасоого татыктуу:
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
Бирдей дайджесттер жуптун чогуу экенин билдирет. Ар башка дайджесттер туура эмес ачкычыңыз бар экенин билдирет, жана эч бир формат айландыруу муну өзгөртпөйт.
Формат эч качан өзгөртпөгөн нерсе
Ишеним чечимдери контейнердин үстүндө кабыл алынат. Кардар өз кампасындагы тамырга чейин чынжырды басып өтөт, жарактуулук терезесин текшерет, кардар аутентификациясы үчүн кеңейтилген ачкыч колдонулушун текшерет, ал эми сервер тарапта чакырган аты сертификатта бар-жогун текшерет. Бул кадамдардын эч бири файл кеңейтүүсүн окубайт.
Ошондуктан ката жоголгонго чейин файлдын атын өзгөртүү убакытты короткон мынчалык ишенимдүү жол. Импорт ийгиликтүү болот, инсандык дагы эле туура эмес, жана ийгиликсиздик кол алышуу учурунда кайра пайда болот, мында билдирүү азыраак жардам берет. Ошондуктан эки жыл мурун экспорттолгон бума таза импорттолуп, баары бир четке кагылат: жарактуулук мөөнөтү файлдын атында эмес, сертификаттын ичинде саякаттаган.
Кайра иштөөдөн качкан тартип
Кардардын документтеринен кайсы коддоолорду кабыл аларын жана кардар инсандыгы үчүн кайсы контейнерди күтөрүн сураңыз, анан сизге эмне берилгенин караңыз. Эгер кардар бир импорттолуучу инсандыкты кааласа жана сизде өзүнчө PEM файлдары болсо, буманы өзүңүз көзөмөлдөгөн сырсөз менен бир жолу куруп, булактарды сактаңыз. Эгер PEM керек болсо, ачкыч менен чынжырды алып чыгып, анан ортолук файлдарды командаңыз мурунтан колдонгон эсептик маалыматтарды иштетүү процесси менен жок кылыңыз.
Импорттон кийин диалогду эмес, инсандыкты текшериңиз: субъект, чыгаруучу, мөөнөт жана кардар көрсөтө турган ат. Тизмедеги жагымдуу ат — белги, текшерилген инсандык эмес. Эгер кийин туннель ийгиликсиз болсо, сиз таңуулоонун ордуна аутентификацияны же маршруттоону оңдоп жатасыз, бул алда канча кыска сүйлөшүү.