PKCS12, PEM ці DER: што насамрэч патрэбна кліенту VPN
Упакоўка вырашае, ці імпартуе кліент ідэнтычнасць, а не ці ёй можна давяраць. Параўнайце PKCS12, PEM і DER, потым праверце.
У абмеркаваннях сертыфікатаў ходзяць два сцверджанні. Першае — што .p12 гэта моцны варыянт, а .pem — слабы; другое — што тэкставы файл павінен быць бяспечным для адпраўкі, бо яго можна прачытаць. Ні адно не вытрымлівае хвіліны праверкі.
PKCS12, PEM і DER апісваюць, як сертыфікатныя аб’екты пакуюцца і кадуюцца. Яны не вырашаюць, хто суразмоўца, ці давяраць выпушчальніку і ці патрэбны файлу пароль.
Што кліент прымае — пытанне сумяшчальнасці. Што файл змяшчае — пытанне ідэнтычнасці. Раздзяляйце гэта, і большасць памылак імпарту перастане быць загадкай.
Тры кантэйнеры, адна мадэль аб’екта
Пачніце з таго, што ў вас сапраўды ёсць. Сертыфікат — гэта подпісанае сцверджанне пра публічны ключ. Прыватны ключ — асобны матэрыял, які даказвае, што вы кантралюеце гэты ключ. Ланцуг — набор выпушчальнікаў, якія звязваюць ваш сертыфікат з коранем, якому давярае кліент. Усе тры існуюць незалежна ад упакоўкі.
Файл PKCS12, звычайна .p12 або .pfx, — гэта кантэйнер, вызначаны ў RFC 7292, які можа несці прыватны ключ, адзін ці некалькі сертыфікатаў і ланцуг у адным блоку, абароненым паролем, з псеўданімам, што называе ідэнтычнасць. Файл PEM — тэкставая рамка паводле RFC 7468: цела base64 паміж радкамі BEGIN і END, і адзін файл можа ўтрымліваць некалькі блокаў запар. DER — гэта бінарнае кадаванне тых жа структур ASN.1, а цела PEM — літаральна DER, абгорнуты base64.
Апошні сказ варта запомніць. Пераўтварэнне 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 — гэта транспартная азбука. Яна нічога не хавае, і любы можа раскладаць блок 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 — устойлівае рашэнне. Пакідаць старыя шыфры назаўсёды ўключанымі на кліенцкай машыне дзеля аднаго файла — дрэнны абмен.
Пятая — неадназначнасць. Кантэйнер з двума ключамі і двума сертыфікатамі або файл PEM з трыма блокамі CERTIFICATE прымушае кліента выбіраць, і яго выбар часта проста першы элемент. Калі тунель узнімаецца з няправільнай ідэнтычнасцю, гэта звычайна прычына.
Праверце перад пераўтварэннем
Чытайце структуру, не друкуючы сакрэтаў. 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, выміце ключ і ланцуг, а затым выдаліце прамежкавыя файлы праз працэс апрацоўкі ўліковых даных, які ваша каманда ўжо выкарыстоўвае.
Пасля імпарту правярайце ідэнтычнасць, а не дыялог: суб’ект, выпушчальнік, тэрмін дзеяння і імя, якое кліент прадставіць. Прыязная назва ў спісе — гэта этыкетка, а не пацверджаная ідэнтычнасць. Калі тунель потым правальваецца, вы адладжваеце аўтэнтыфікацыю або маршрутызацыю замест упакоўкі, што значна карацейшая размова.