PKCS12, PEM или DER: шта је VPN клијенту заиста потребно

У расправама о сертификатима круже две тврдње. Прва је да је .p12 јака опција, а .pem лабава; друга да текстуална датотека мора бити безбедна за слање јер можете да је прочитате. Ниједна не издржава минут провере.

PKCS12, PEM и DER описују како се сертификатни објекти пакую и кодирају. Не одлучују ко је друга страна, да ли је издавалац поуздан или да ли је датотеци потребна лозинка.

Шта клијент прихвата је питање компатибилности. Шта датотека садржи је питање идентитета. Раздвојите то двоје и већина грешака при увозу престаје да буде мистерија.

Три контејнера, један модел објекта

Почните од онога што заиста имате. Сертификат је потписана изјава о јавном кључу. Приватни кључ је одвојен материјал који доказује да контролишете тај кључ. Ланац је скуп издавалаца који повезују ваш сертификат са кореном ком клијент верује. Сва три постоје независно од паковања.

Датотека PKCS12, обично .p12 или .pfx, контејнер је дефинисан у RFC 7292 који може да носи приватни кључ, један или више сертификата и ланац у једном блоку заштићеном лозинком, са псеудонимом који именује идентитет. Датотека PEM је текстуални оквир дефинисан у RFC 7468: base64 тело између редова BEGIN и END, и једна датотека може да садржи неколико блокова заредом. DER је бинарно кодирање истих ASN.1 структура, а тело PEM је буквално DER умотан у base64.

Последња реченица вреди памћења. Претварање PEM у DER преписује оквир, не садржај, а обрнуто претварање враћа изворне бајтове.

Кодирање није шифровање

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 sha256
openssl pkey -in key.pem -pubout | openssl sha256

Идентични диџести значе да пар припада заједно. Различити диџести значе да имате погрешан кључ и никакво претварање формата то не мења.

Шта формат никада не мења

Одлуке о поверењу доносе се изнад контејнера. Клијент пролази ланац до корена у свом складишту, проверава прозор важности, проверава проширену употребу кључа за аутентификацију клијента и на страни сервера проверава да ли се име које је позвао налази у сертификату. Ниједан од тих корака не чита екстензију датотеке.

Зато је преименовање датотеке док грешка не нестане тако поуздан начин да губите време. Увоз успева, идентитет је и даље погрешан, а квар се враћа током руковања где је порука мање корисна. Зато се и пакет извезен пре две године увози чисто и ипак бива одбијен: датум истека је путовао унутар сертификата, не у имену датотеке.

Редослед који избегава преправке

Питајте документацију клијента која кодирања прихвата и какав контејнер очекује за идентитет клијента, па погледајте шта сте добили. Ако клијент жели један увезни идентитет, а имате одвојене PEM датотеке, саставите пакет једном са лозинком коју контролишете и сачувајте изворе. Ако жели PEM, извуците кључ и ланац, а затим уклоните међудатотеке поступком руковања акредитивима који ваш тим већ користи.

После увоза проверите идентитет, не дијалог: субјекат, издаваоца, истек и име које ће клијент представити. Пријатно име на листи је ознака, не проверени идентитет. Ако тунел затим падне, отклањате грешке у аутентификацији или рутирању уместо у паковању, што је много краћи разговор.