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, извлечете ключа и веригата и след това премахнете междинните файлове чрез процеса за работа с удостоверения, който екипът ви вече използва.
След импорта проверявайте идентичността, не диалога: субект, издател, срок и името, което клиентът ще представи. Приятелското име в списък е етикет, не потвърдена идентичност. Ако след това тунелът се провали, отстранявате проблеми с удостоверяването или маршрутизацията вместо с опаковката, което е много по-кратък разговор.