Создать PEM сертификаты
PEM — это не отдельный “вид сертификата” вроде DV или OV, а очень распространённый формат файла, в котором хранят сертификаты, приватные ключи, CSR-запросы и полные цепочки сертификатов. На практике это текстовый формат с блоками, начинающимися и заканчивающимися строками вида BEGIN и END, например CERTIFICATE, PRIVATE KEY или CERTIFICATE REQUEST. Именно поэтому PEM настолько популярен в Linux-среде, Apache, NGINX, HAProxy, API-клиентах и автоматизации. Когда администратору нужно включить HTTPS на сайте, сделать CSR для центра сертификации или конвертировать PFX-файл в формат, который понимает веб-сервер, всё очень часто заканчивается именно PEM-файлами.
Это важно и для небольших сайтов, и для серьёзной инфраструктуры. Например, публичный сайт или интернет-магазин с SSL сертификатами требует правильно собранных файла сертификата, промежуточной цепочки и приватного ключа. На хостинге часть этого может быть автоматизирована, но на виртуальном сервере администратор обычно сам управляет файлами, правами доступа и командами OpenSSL. Поэтому понимание PEM — это не абстрактная теория, а практический навык сопровождения сервисов.
Сначала важно разделить четыре основных элемента. Приватный ключ — это секретный файл, который должен оставаться только у вас и не должен публиковаться. CSR, или Certificate Signing Request, — это запрос, который отправляется центру сертификации или используется в автоматизированной выдаче. CRT или CERTIFICATE — это уже выданный сертификат. Chain — это промежуточные сертификаты, помогающие клиентам корректно проверить доверенную цепочку. Все эти элементы могут существовать в PEM-формате, поэтому фраза “создать PEM сертификат” на практике очень часто означает не один файл, а весь рабочий комплект.
Самая логичная и безопасная последовательность выглядит так: сначала создаётся приватный ключ, потом создаётся CSR, затем получается сертификат от центра сертификации, а после этого при необходимости собирается fullchain или выполняется конвертация из другого формата в PEM. Если понимать именно эту последовательность, большая часть работы с сертификатами становится простой и предсказуемой. Ошибки начинаются обычно тогда, когда путают файлы, теряют нужный приватный ключ или забывают, что серверу часто нужен не только leaf-сертификат, но и цепочка.
# 1. Создать приватный ключ openssl genrsa -out private.key 2048 # 2. Создать CSR openssl req -new -key private.key -out request.csr
При создании CSR OpenSSL запрашивает данные о стране, организации и Common Name. Именно данные о домене определяют, для каких имён сертификат будет действителен. Если сервис должен работать для example.com и www.example.com, эту часть не стоит заполнять небрежно. В современных сценариях особенно важны значения Subject Alternative Name, потому что именно они реально используются при проверке имени сертификата.
# Пример CSR с базовыми данными openssl req -new -key private.key -out request.csr -subj "/C=LV/ST=Riga/L=Riga/O=Company/CN=example.com"
Когда центр сертификации выпускает сертификат, вы обычно получаете один или несколько файлов: сам серверный сертификат, промежуточные сертификаты и иногда инструкции по сборке цепочки. В Linux-среде часто создают fullchain-файл, где сначала идёт сертификат сервера, а затем промежуточные сертификаты. Это важно, потому что без полной цепочки некоторые клиенты и сервисы будут считать доверие неполным, даже если в вашем браузере всё выглядит нормально.
# Собрать полный chain-файл cat server.crt intermediate.crt > fullchain.pem
Очень распространённый сценарий — конвертация PFX или P12 в PEM. Это бывает, когда сертификат экспортирован из Windows, IIS или другого инструмента, а затем должен использоваться в NGINX, Apache, HAProxy или Linux-сервисе. PFX может содержать и сам сертификат, и приватный ключ, и иногда цепочку. OpenSSL позволяет извлечь эти части по отдельности, но здесь важно чётко понимать, какой файл за что отвечает, и хранить приватный ключ в безопасном месте.
# Извлечь сертификат из PFX openssl pkcs12 -in certificate.pfx -clcerts -nokeys -out server.crt # Извлечь приватный ключ openssl pkcs12 -in certificate.pfx -nocerts -nodes -out private.key # Извлечь промежуточные сертификаты openssl pkcs12 -in certificate.pfx -cacerts -nokeys -out chain.crt
PEM удобен тем, что это текстовый формат, и его можно открыть обычным редактором. Но это же создаёт и риск: можно случайно повредить переносы строк, скопировать не весь блок или сохранить приватный ключ в неподходящем месте. Особенно аккуратно нужно обращаться именно с приватным ключом. На Linux его обычно размещают вне публичного веб-каталога и задают жёсткие права доступа, чтобы читать его могли только нужный сервис и администратор.
# Безопасные права для приватного ключа chmod 600 private.key chown root:root private.key
После создания или конвертации очень полезно проверить, что сертификат, приватный ключ и CSR действительно соответствуют друг другу. Классическая ошибка — пытаться использовать сертификат с чужим приватным ключом. В такой ситуации Apache или NGINX часто отказываются запускаться и сообщают, что ключ не соответствует сертификату. Самый практичный способ — сравнить modulus или аналогичные значения через OpenSSL до выкладки на боевой сервер.
# Проверка соответствия ключа и сертификата openssl x509 -noout -modulus -in server.crt | openssl md5 openssl rsa -noout -modulus -in private.key | openssl md5 # Проверка CSR и сертификата openssl req -noout -text -in request.csr openssl x509 -noout -text -in server.crt
Отдельно стоит упомянуть self-signed сертификаты. Они полезны для тестовых стендов, лабораторий, внутренних сервисов и разработки, когда публичное доверие не требуется. Но self-signed сертификат — это не замена публичному SSL для сайта клиентов. Если такой сертификат использовать на публичной странице, браузеры будут предупреждать о недоверенном издателе, потому что сертификат не подписан известным центром сертификации.
# Создать self-signed сертификат openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout private.key -out server.crt
Проверка, размещение и типичные ошибки
После подготовки PEM-файлов следующий шаг — корректно разместить их на сервере. Apache, NGINX и другие сервисы используют разный синтаксис конфигурации, но логика одинаковая: нужно указать путь к сертификату и путь к соответствующему приватному ключу, а во многих случаях ещё и к chain или fullchain. В продакшене не стоит перезапускать сервис вслепую. Сначала лучше проверить конфигурацию, а уже потом выполнять reload или restart.
# Проверка конфигурации NGINX nginx -t # Проверка конфигурации Apache apachectl configtest
Самые частые ошибки — неправильный порядок сертификатов в fullchain, путаница между leaf и chain, использование неверного приватного ключа, слишком широкие права на чувствительные файлы и хранение ключей в директориях, доступных лишним процессам или пользователям. Ещё одна очень типичная проблема — забытый срок действия. Сертификат может быть технически правильным сегодня, но если не следить за его продлением, результат для пользователей будет тот же, что и при поломанном SSL: предупреждения и потеря доверия.
Хорошая практика — документировать, откуда получен сертификат, какой приватный ключ к нему относится, где лежит chain, какой сервис использует эти файлы и когда заканчивается срок действия. Это особенно важно в средах с несколькими доменами или несколькими администраторами. Сами PEM-файлы несложны, но путаница очень быстро растёт, если через несколько месяцев никто уже не помнит, какой файл для чего создавался.
Когда этот процесс понятен, создание и сопровождение PEM-сертификатов становится рутинной задачей. Вы знаете, как сделать ключ, как подготовить CSR, как принять выданный сертификат, как собрать fullchain и как проверить соответствие всех частей. Именно такая последовательная логика позволяет не просто один раз “починить SSL”, а безопасно и аккуратно поддерживать HTTPS в долгосрочной перспективе.