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, извлечете го клучот и синџирот, а потоа отстранете ги меѓудатотеките преку процесот за ракување со акредитиви што вашиот тим веќе го користи.
По увозот проверете го идентитетот, не дијалогот: субјект, издавач, важност и името што клиентот ќе го претстави. Пријателското име во список е етикета, не проверен идентитет. Ако тунелот потоа пропадне, дебагирате автентикација или рутирање наместо пакување, што е многу пократок разговор.