Инструменты разработчика · Кодер и декодер Base64
PEM объяснил: почему сертификаты и ключи имеют формат Base64 между BEGIN и END
· Фон
base64 кодирование
Файл PEM представляет собой двоичный файл DER, завернутый в Base64, с помеченными линиями защиты. В этом посте объясняется происхождение формата, правила его строк и то, что вы можете и не можете узнать, расшифровав его.
Сертификат, который «выглядит как текст», но его не удается проанализировать — опечатка в заголовке, случайный возврат каретки и формат под ним.
Файл PEM представляет собой двоичный файл в кодировке Base64, завернутый в текстовые метки. Название происходит от Privacy-Enhanced Mail (RFC 1421, 1992), которая использовала этот формат для зашифрованных сообщений. Сегодня этот формат сохранился в сертификатах TLS, ключах SSH и ключах GPG. Структура проста: за ней следует строка с надписью -----BEGIN CERTIFICATE----- (или BEGIN PRIVATE KEY, BEGIN PUBLIC KEY и т. д.). строками текста в формате Base64 длиной 64, за которыми следует -----END CERTIFICATE-----.
Тело base64 декодируется в двоичный формат, называемый DER (отличительные правила кодирования), который является способом сериализации структурированных данных (в частности, структур ASN.1). Декодирование base64 дает вам двоичный код; чтение двоичного файла требует понимания ASN.1, что сложно. Броня PEM существует, потому что двоичные файлы сложно отправлять по электронной почте и редактировать. Файл сертификата в чисто двоичной форме может быть поврежден при передаче через старые почтовые системы, USENET или веб-формы.
Текстовая броня, видимая в блоке PEM — метки вокруг тела Base64.
Закодировав двоичный файл в кодировке Base64 и обернув его текстовыми метками, весь сертификат становится 7-битным ASCII текстом, который выдерживает любую транспортировку. Текстовый редактор может открыть его; почтовая система не повредит его. Строки -----BEGIN и -----END представляют собой метки для людей и автоматизированных инструментов; они четко обозначают, какие данные находятся внутри. Сертификат помечен как CERTIFICATE; закрытый ключ помечен как PRIVATE KEY.
Этикетка не проверяется криптографическим программным обеспечением; это всего лишь подсказка для людей и инструментов. Ограничение на длину строки 64 в PEM происходит от RFC 1421 и того же рассуждения MIME, что и для электронной почты base64: старые почтовые системы имели ограничения на длину строки, а символы 64 помещались на терминале 1980-х годов. PEM оборачивает вывод base64 в символы 64 с окончанием строки (CR LF в Windows, LF в Unix).
От размеченного текста до декодированных байтов — этот репозиторий не сохраняет историю формата.
При декодировании сертификата PEM синтаксический анализатор должен удалить строки брони (-----BEGIN..., -----END...) и разрывы строк, а затем декодировать остаток в формате Base64. Случайный возврат каретки или несоответствующая метка могут нарушить синтаксический анализ. Перенос строк не является частью стандарта base64 (RFC 4648 base64 разворачивается); это специфично для PEM. Внутри base64 находится двоичный файл в кодировке DER. DER — это ASN.1 (абстрактная синтаксическая нотация), сложная спецификация для представления структур данных.
Сертификат — это структурированная запись, содержащая имя субъекта, открытый ключ, подпись и метаданные. ASN.1 не описывает байты напрямую; он описывает, как должна быть закодирована структура.
Анатомия блока как входные данные для этого инструмента — удалите метки и передайте только тело Base64.
Кодирование начинается с троек значения длины тега. Например, SEQUENCE в ASN.1 кодируется как тег 0x30, за которым следует длина содержимого, а затем само содержимое. Сертификат всегда начинается с байтов 0x30 0x82 (последовательность, длина закодирована в двух байтах), которая отображается как MII в base64.
Проверка сертификата без его анализа: первые три символа тела сертификата PEM почти всегда — это MII (это 0x30 0x82 в base64, начало SEQUENCE). Если блок PEM не декодируется в 0x30, значит, base64 поврежден или метка неверна. Инструмент кодирования и декодера Base64 может декодировать тело и отображать шестнадцатеричный код: вставьте строки base64 (без брони -----BEGIN и END), удалите разрывы строк и декодируйте.
Что выдает декодирование: двоичные байты, а не разобранные поля сертификата
Если выходные данные являются двоичными, начиная с 30 82, скорее всего, это действительная структура сертификата. Если это тарабарщина или текст, значит, декодирование не удалось или код base64 неправильный. Распространенные ошибки PEM: несоответствие метки (например, тело сертификата с меткой PRIVATE KEY), проблема с окончанием строки Windows (некоторые парсеры застревают на CRLF), опечатка в строке брони (лишние пробелы или символы) или отсутствующие разрывы строк.
Инструменты ожидают -----BEGIN CERTIFICATE----- а не -----BEGIN CERT----- или BEGIN CERTIFICATE. Копирование PEM из веб-браузера или PDF может привести к появлению кавычек Unicode или смарт-кавычек вместо кавычек ASCII, что приведет к нарушению метки. Вставка закрытого ключа в поле сертификата является распространенной ошибкой; синтаксический анализатор отклонит его, поскольку метка не соответствует. PEM поддерживает несколько блоков в одном файле.
Рабочий пример: декодирование короткого тела и проверка байтов без подтверждения подписи сертификата.
Файл ключей SSH может содержать как закрытый ключ (с меткой PRIVATE KEY), так и открытый ключ (с меткой PUBLIC KEY) или несколько блоков сертификатов. Парсер читает файл сверху, ища строки, начинающиеся с -----BEGIN. Когда он его находит, он читает до тех пор, пока -----END с соответствующей меткой, извлекает и декодирует в base64 тело и обрабатывает его. Затем он продолжает поиск следующего блока.
Случайно объединенная цепочка сертификатов (несколько блоков PEM для сертификата и его промежуточных элементов) в одном файле действительна, если все метки верны. Формат PEM был стандартизирован для почты с улучшенной конфиденциальностью (RFC 1421) в начале 1990-х годов.
Что здесь не распространяется — анализ структур ASN.1, шифрование закрытым ключом и пакеты PKCS#12.
RFC 7468 (2015) модернизировал определение, уточнив правила длины строки, формат линии брони и крайние случаи. Сейчас большинство инструментов и стандартов ссылаются на RFC 7468. Существуют и другие форматы преобразования двоичного текста в текст (например, DER в шестнадцатеричный для некоторых протоколов), но PEM с метками base64 и ASCII является фактическим стандартом для криптографии, а TLS, поскольку он удобен для чтения, является простым текстом и его легко копировать или отправлять.
Создание блока PEM: возьмите двоичный файл DER (например, сертификат из криптографической библиотеки), закодируйте его в base64, оберните результат в символы 64 разрывами строк и окружите его -----BEGIN CERTIFICATE----- и -----END CERTIFICATE----- строк. Анализ блока PEM: найдите строки -----BEGIN и -----END, извлеките тело base64 (удалив броню и разрывы строк), выполните base64-декодирование, чтобы получить двоичный файл, затем проанализируйте DER и ASN.1 двоичный файл.
Вывод: PEM — это Base64 с метками — как кодировщик и декодер Base64 дают вам локальное место, где можно попробовать тело блока Base64, полностью в браузере.
Большинство инструментов автоматизируют это; вы редко создаете PEM вручную. Но понимание структуры полезно при отладке ошибки синтаксического анализа или при проверке сертификата вручную. Сертификат PEM выглядит как текст, но его содержимое представляет собой двоичные данные. Чтение меток начала и конца не дает вам информации о том, что содержит сертификат; вы должны декодировать base64 и проанализировать ASN.1, чтобы увидеть имя субъекта, открытый ключ, эмитента и срок действия.
Инструмент кодирования и декодера Base64 может декодировать тело, чтобы вы могли проверить первые несколько байтов. Для полного анализа вам понадобится парсер ASN.1 (в большинстве языков программирования для этого есть библиотеки). Основная идея заключается в том, что PEM — это формат контейнера: он содержит любые данные, закодированные в DER, а не только сертификаты. Метка сообщает вам предполагаемое использование, но синтаксический анализатор должен правильно обрабатывать тип данных.