Когда речь заходит о TLS, чаще всего спорят не про криптографию, а про «в каком формате прислали сертификат» и «почему сервер ругается на private key mismatch». PEM, DER и PKCS#12 (PFX) — это разные способы упаковать одни и те же сущности: сертификат, цепочку и приватный ключ. Ниже — практическая шпаргалка, которая помогает быстро понять, что у вас в руках, и привести файлы к нужному виду через OpenSSL.
Что вообще лежит внутри TLS-набора
Для корректной установки TLS на веб‑сервер обычно нужны три вещи:
Сертификат сервера (leaf certificate) — выдан на домен/список доменов.
Приватный ключ — секретный, хранится у вас; по нему сервер доказывает владение сертификатом.
Цепочка (intermediate certificates, bundle/chain) — чтобы клиент мог построить доверие до корневого CA.
Иногда CA присылает ещё и root-сертификат. На веб‑сервере он обычно не нужен: клиенты и так держат корни в trust store.
Запомните правило: «формат» (PEM/DER/PFX) — это упаковка. «Сертификат/ключ/цепочка» — это содержимое.
PEM: текстовый контейнер, который вы видите каждый день
PEM — это Base64 + заголовки/футеры вида -----BEGIN CERTIFICATE-----. На практике это самый частый формат для Linux‑окружений, панелей и веб‑серверов.
PEM удобен тем, что его легко открыть в редакторе и понять тип блока (сертификат/ключ), а также тем, что в одном файле можно хранить несколько сущностей подряд (например, leaf + intermediates).
Как понять, что файл — PEM
Откройте файл и посмотрите на первые строки. Типичные блоки:
сертификат:
BEGIN CERTIFICATE;приватный ключ:
BEGIN PRIVATE KEYилиBEGIN RSA PRIVATE KEYилиBEGIN EC PRIVATE KEY;цепочка: несколько блоков
BEGIN CERTIFICATEподряд.
Проверка сертификата PEM через OpenSSL
openssl x509 -in cert.pem -noout -text
openssl x509 -in cert.pem -noout -subject -issuer -dates -serial
Проверка приватного ключа PEM
Убедитесь, что ключ читается и соответствует ожидаемому типу:
openssl pkey -in privkey.pem -noout -text
Если ключ зашифрован, OpenSSL запросит passphrase. Для продакшена заранее продумайте, как сервис будет стартовать без ручного ввода пароля (systemd, секреты, агент) — иначе получите внезапный даунтайм после перезагрузки.
DER: бинарный формат «как есть», без заголовков
DER — это бинарное ASN.1‑представление. Его часто встречают в Windows‑мире, в устройствах, в некоторых API. Расширения .cer/.crt не гарантируют DER: это может быть и PEM.
Как понять, что файл — DER
DER нельзя «прочитать глазами» — это бинарный файл. Быстрая проверка: попробуйте распарсить как DER‑сертификат.
openssl x509 -inform der -in cert.der -noout -text
Если это действительно DER, команда отработает. Если нет — увидите ошибки ASN.1/decoder.
PKCS#12 (PFX): контейнер «сертификат + ключ + цепочка» под паролем
PKCS#12 — контейнер, чаще всего с расширением .p12 или .pfx. Он может включать приватный ключ, leaf‑сертификат, intermediates (цепочку) и служебные поля вроде friendlyName для удобства импорта.
Типичный сценарий: нужно перенести «всё в одном файле» в IIS, балансировщик, K8s-секреты, Java‑окружение или отдать коллеге. Контейнер обычно защищают паролем.
Посмотреть содержимое PFX
openssl pkcs12 -in bundle.pfx -info -noout
openssl pkcs12 -in bundle.pfx -nodes -nokeys
Вторая команда покажет сертификаты без извлечения ключей (удобно для проверки, что внутри есть intermediates).
OpenSSL: конвертация между PEM, DER и PFX
Ниже — самые частые операции конвертации и «приведения в порядок», когда один софт ожидает PEM, другой — DER, а третий — PKCS#12.
DER → PEM (сертификат)
openssl x509 -inform der -in cert.der -out cert.pem
PEM → DER (сертификат)
openssl x509 -in cert.pem -outform der -out cert.der
Собрать PFX (PKCS#12) из PEM: ключ + сертификат + цепочка
Обычно у вас отдельно leaf (cert.pem) и отдельно цепочка intermediates (chain.pem). Итоговый PFX будет создан с паролем.
openssl pkcs12 -export -out bundle.pfx -inkey privkey.pem -in cert.pem -certfile chain.pem
Извлечь сертификаты (leaf + chain) из PFX в PEM
openssl pkcs12 -in bundle.pfx -out certs.pem -nokeys
Если внутри и leaf, и intermediates — они окажутся в одном PEM подряд. Многие веб‑серверы принимают такой «бандл», но иногда удобнее разделить на файлы.
Извлечь приватный ключ из PFX
Без шифрования (осторожно: файл станет крайне чувствительным, выставляйте права):
openssl pkcs12 -in bundle.pfx -out privkey.pem -nodes -nocerts
С сохранением шифрования ключа (будет запрошен новый пароль):
openssl pkcs12 -in bundle.pfx -out privkey.pem -nocerts
Привести ключ к PKCS#8 (часто самый «совместимый» PEM)
Иногда софт ожидает ключ именно в PKCS#8 (обычно это BEGIN PRIVATE KEY). Преобразование:
openssl pkcs8 -topk8 -in privkey.pem -out privkey-pkcs8.pem
Чтобы не оставлять ключ в открытом виде, добавьте шифрование:
openssl pkcs8 -topk8 -in privkey.pem -out privkey-pkcs8.pem -v2 aes-256-cbc
Private key mismatch: как быстро проверить соответствие ключа и сертификата
Ошибка private key mismatch означает простое: вы пытаетесь использовать сертификат с чужим приватным ключом. Часто это случается после перевыпуска, когда CSR делали с новым ключом, а на сервере остался старый.
Способ №1: сравнить modulus (только для RSA)
openssl x509 -in cert.pem -noout -modulus | openssl md5
openssl rsa -in privkey.pem -noout -modulus | openssl md5
Если хэши совпали — пара верная. Если нет — mismatch.
Способ №2: сравнить public key (подходит для RSA и EC)
Универсальный вариант — сравнить публичный ключ, извлечённый из сертификата и из приватного ключа.
openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform der | openssl sha256
openssl pkey -in privkey.pem -pubout | openssl pkey -pubin -outform der | openssl sha256
Совпало — это одна пара.
Типовые причины mismatch
взяли «не тот» ключ из бэкапа/репозитория/папки с несколькими выпусками;
сертификат перевыпустили с новым CSR, а на сервер положили старый ключ;
в PFX несколько записей, импортировали «не тот alias»;
ключ обрезан/повреждён при копировании (часто при переносе через буфер обмена).
Расширения файлов: почему .crt/.cer/.key не гарантируют формат
Расширение — это подсказка, но не истина. Встречается:
.pem— чаще PEM (сертификаты/ключи/цепочки);.crt,.cer— может быть PEM или DER;.key— обычно PEM приватный ключ (в том числе зашифрованный);.p12,.pfx— PKCS#12.
Надёжный путь — не угадывать, а проверять командами OpenSSL (как в секциях выше).
Цепочка сертификатов: как понять, что вы отдаёте клиентам
Даже если ключ и сертификат совпали, сайт может «ломаться» у части клиентов из‑за неправильной цепочки. Типичная ситуация: установлен только leaf, а intermediate забыли.
Проверить цепочку в локальных файлах
Если у вас есть leaf и intermediates:
openssl verify -CAfile chain.pem cert.pem
Это быстрая диагностика: если chain.pem действительно содержит нужные intermediates, проверка пройдёт.
Проверить, что в chain.pem правильные сертификаты
У каждого промежуточного есть Subject и Issuer. Быстро посмотреть:
openssl x509 -in cert.pem -noout -issuer -subject
openssl x509 -in chain.pem -noout -issuer -subject
Если в chain.pem несколько сертификатов, команда выше покажет только первый. Для просмотра всех сертификатов в цепочке:
openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout
Если нужно сверить результат «как видит клиент», пригодится отдельная диагностика рукопожатия и цепочки: проверка TLS через openssl s_client и базовая диагностика.
Java keystore: импорт PKCS#12 и работа с alias
В Java‑мире всплывают keystore, alias и форматы JKS/PKCS12. Современная Java обычно умеет PKCS#12 напрямую, но некоторые приложения всё ещё требуют JKS.
Импорт PFX/PKCS#12 в JKS (если нужно)
keytool -importkeystore -srckeystore bundle.pfx -srcstoretype PKCS12 -destkeystore keystore.jks -deststoretype JKS
Посмотреть содержимое keystore и alias
keytool -list -v -keystore keystore.jks
keytool -list -v -storetype PKCS12 -keystore bundle.pfx
Если сертификат «не подхватывается», часто причина именно в alias: приложение смотрит один alias, а импортировали вы другой (или лежит несколько записей, и выбрана не та).
Частые грабли при конвертации и установке
1) Перепутали leaf и chain
Некоторые панели/веб‑серверы ждут «сертификат» и «цепочку» в разные поля. Другие — наоборот, хотят fullchain одним файлом. В любом случае клиент должен получить leaf + intermediates.
2) Случайно отдали приватный ключ
Не размещайте приватный ключ в публичной части сайта и не отправляйте его в тикеты/чаты без необходимости. Если ключ утёк — безопасный путь обычно один: перевыпуск с новым ключом и отзыв старого (по возможностям CA).
3) Зашифрованный ключ там, где сервис не умеет пароль
Некоторые демоны не умеют стартовать с запросом пароля (важно для автозапуска). Тогда вам нужен подход с агентом/секретами или ключ без пароля, но с максимально строгими правами доступа на файл и на пользователя сервиса.
4) «OpenSSL читает, а сервер нет»
Причины часто бытовые: DOS‑переносы строк, лишние пробелы, «склеенные» секции, ключ в неожиданном формате. Универсальный шаг: привести ключ к PKCS#8, и убедиться, что файл содержит ровно один ключевой блок.
Мини-чеклист: что сделать, когда «не работает TLS»
Определите формат файла (PEM/DER/PFX) командами OpenSSL, а не по расширению.
Проверьте соответствие сертификата и ключа (pubkey hash или modulus для RSA).
Проверьте, что цепочка intermediates корректная и не перепутана с leaf.
Если это Java/keystore — проверьте alias и тип хранилища (PKCS12/JKS).
После изменений сделайте корректный reload/restart сервиса и перепроверьте рукопожатие.
Итоги
PEM удобен для администрирования и веб‑серверов, DER встречается как «бинарный сертификат», а PKCS#12 (PFX) — практичный вариант, когда нужно переносить сертификат вместе с ключом и цепочкой (и защитить контейнер паролем). Если держать правило «сначала проверяю содержимое, потом конвертирую», то большинство проблем с форматами и ошибками вида mismatch исчезают.
Если вы планируете обслуживать несколько проектов и доменов, удобно держать единый порядок хранения ключей/сертов и регулярно проверять сроки. А инфраструктуру под сайты и сервисы можно развернуть как на виртуальном хостинге, так и на VDS — в зависимости от требований к доступу и автоматизации.
