Как сгенерировать CSR на Postfix

Это руководство показывает вам, как сгенерировать CSR (запрос на подпись сертификата) в Postfix с помощью командной строки OpenSSL. Сам Postfix не генерирует ключи или CSR — он использует файлы, созданные OpenSSL, и ссылается на них из /etc/postfix/main.cf. Вы выполняете одну команду, которая создает сразу два файла: приватный ключ, который остается на сервере, и CSR, который вы отправляете в свой Центр сертификации (CA).

CSR кодирует имя хоста, которое ваш MTA предъявляет при STARTTLS, данные вашей организации и открытую часть ключа. Соответствующий приватный ключ никогда не покидает сервер. Если вы его потеряете, выпущенный сертификат станет непригодным для использования, и вам придется начинать все заново.

Предварительные требования

• Root или доступ через sudo к серверу, на котором работает Postfix.
• Установленный OpenSSL. Он входит в базовую систему во всех основных дистрибутивах Linux; проверьте с помощью openssl version.
• Полное доменное имя почтового хоста, которое вы хотите указать в сертификате, например mail.example.com. Оно должно совпадать с MX-записью, к которой подключаются клиенты по STARTTLS, а не с голым доменом верхнего уровня.

Шаг 1: Подготовьте каталог для ключа и CSR

Храните материалы TLS для Postfix в отдельном каталоге внутри /etc/postfix/, чтобы упростить управление правами доступа. Создайте его и ограничьте доступ только для root:

sudo mkdir -p /etc/postfix/ssl
sudo chmod 700 /etc/postfix/ssl
cd /etc/postfix/ssl

Вы сгенерируете ключ и CSR внутри этого каталога, а затем сошлетесь на них из main.cf после того, как CA выпустит сертификат.

Шаг 2: Сгенерируйте приватный ключ и CSR

Выполните приведенную ниже команду. Она создает приватный ключ и CSR за один шаг и включает Subject Alternative Name (SAN), который требуют современные браузеры, почтовые клиенты и CA. SAN должен содержать имя почтового хоста (то, на которое указывает ваша MX-запись), а не голый домен верхнего уровня:

sudo openssl req -new -newkey rsa:2048 -nodes 
-keyout /etc/postfix/ssl/mail.example.com.key 
-out /etc/postfix/ssl/mail.example.com.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=mail.example.com" 
-addext "subjectAltName=DNS:mail.example.com"

Вот что делает каждая часть:

• req -new создает новый запрос на подпись сертификата.
• -newkey rsa:2048 генерирует новый 2048-битный приватный ключ RSA. 2048 бит — это текущий минимум для публичных сертификатов; вы можете использовать rsa:4096 для более крупного ключа.
• -nodes оставляет приватный ключ незашифрованным (без парольной фразы), чтобы Postfix мог загрузить его при запуске без запроса.
• -keyout записывает приватный ключ. Держите этот файл в секрете и никогда не отправляйте его никому, включая CA.
• -out записывает CSR, который вы отправляете в CA.
• -subj заполняет поля субъекта прямо в команде, чтобы она выполнялась без интерактивных запросов. Укажите в CN (Common Name) ваш почтовый хост.
• -addext «subjectAltName=…» добавляет запись SAN. CA выпускают сертификаты на основе списка SAN, поэтому почтовый хост должен присутствовать здесь.

Замените mail.example.com на реальное имя хоста, к которому подключаются клиенты (часто это то же имя, что и в вашей MX-записи), и отредактируйте значения -subj в соответствии с данными вашей организации. Двухбуквенный код страны (C) должен быть в верхнем регистре, например US или GB. Для сертификата с проверкой домена (DV) поля организации не проверяются, но команде все равно нужны корректные значения. Современный OpenSSL по умолчанию подписывает CSR с помощью SHA-256, что требуется всеми публичными CA.

Если вы предпочитаете заполнять поля в интерактивном режиме вместо использования -subj, уберите эту строку, и OpenSSL запросит у вас каждое значение:

sudo openssl req -new -newkey rsa:2048 -nodes 
-keyout /etc/postfix/ssl/mail.example.com.key 
-out /etc/postfix/ssl/mail.example.com.csr 
-addext "subjectAltName=DNS:mail.example.com"

При появлении запроса оставьте поля challenge password и optional company name пустыми, нажав Enter. CA игнорируют эти поля, а challenge password впоследствии вызывает проблемы.

Охват нескольких имен хоста

Если один и тот же экземпляр Postfix отвечает на несколько имен (например, и mail.example.com, и smtp.example.com, или общий сертификат для почты и веб-почты), перечислите все имена хостов в значении SAN через запятую:

-addext "subjectAltName=DNS:mail.example.com,DNS:smtp.example.com,DNS:webmail.example.com"

Common Name должно по-прежнему быть основным именем почтового хоста. Добавление голого apex-домена в SAN полезно только в том случае, если почтовые клиенты когда-либо подключаются к нему напрямую; если ваша MX-запись указывает на поддомен, вам не нужно добавлять apex-домен в сертификат.

Предпочитаете ключ ECDSA?

Ключи ECDSA меньше и быстрее, чем RSA при том же уровне безопасности, и поддерживаются всеми современными почтовыми клиентами и CA. Чтобы вместо этого сгенерировать ключ и CSR P-256 (prime256v1), замените аргумент -newkey:

sudo openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -nodes 
-keyout /etc/postfix/ssl/mail.example.com.key 
-out /etc/postfix/ssl/mail.example.com.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=mail.example.com" 
-addext "subjectAltName=DNS:mail.example.com"

Шаг 3: Защитите приватный ключ

Ограничьте доступ к приватному ключу так, чтобы читать его мог только root. Postfix открывает свои материалы TLS до сброса привилегий, поэтому владение от имени root и режим доступа 600 одновременно корректны и обязательны:

sudo chown root:root /etc/postfix/ssl/mail.example.com.key
sudo chmod 600 /etc/postfix/ssl/mail.example.com.key

Файл CSR не является секретным (он содержит только открытый ключ и данные вашего субъекта), но хранение его в том же защищенном каталоге поддерживает порядок в структуре файлов.

Шаг 4: Проверьте CSR

Прежде чем отправить запрос, убедитесь, что он содержит правильное имя хоста и SAN, а его подпись действительна. Эта команда выводит расшифрованное содержимое и проверяет подпись локально:

openssl req -noout -text -verify -in /etc/postfix/ssl/mail.example.com.csr

Найдите в выводе verify OK, проверьте, что строка Subject показывает ваш почтовый хост как Common Name, и убедитесь, что раздел X509v3 Subject Alternative Name перечисляет все ожидаемые имена хостов. Если SAN отсутствует, пересоздайте CSR с правильным значением -addext: CA не может добавить имена хостов после выпуска сертификата. Вы также можете вставить CSR в наш онлайн Декодер CSR, чтобы проверить эти поля в браузере.

Шаг 5: Отправьте CSR

Откройте файл CSR и скопируйте все его содержимое, включая строки BEGIN и END:

cat /etc/postfix/ssl/mail.example.com.csr

Блок выглядит так. Скопируйте все от первой строки до последней, включая пять дефисов с каждой стороны маркеров BEGIN и END:

-----BEGIN CERTIFICATE REQUEST-----
MIIC...base64-encoded data...AB
-----END CERTIFICATE REQUEST-----

Вставьте этот блок в форму заказа SSL. После того, как CA проверит CSR и выпустит сертификат, следуйте нашей инструкции по установке SSL для Postfix, чтобы развернуть его. Держите файл .key на сервере: он нужен вам вместе с выпущенным сертификатом для обслуживания STARTTLS, и вы никогда не должны отправлять его в CA или кому-либо еще.

Если вы предпочитаете не использовать командную строку, создайте запрос с помощью нашего Генератора CSR и вставьте результат в свой заказ. Генератор возвращает соответствующий приватный ключ, который вы размещаете по тому же пути на сервере.

Куда файлы попадают в Postfix

Для справки, вот как только что сгенерированные вами файлы подключаются к Postfix после того, как CA вернет сертификат и промежуточный сертификат (пакет CA). В Postfix версии 3.4 и новее рекомендуемая форма с одной директивой использует один PEM-файл, содержащий приватный ключ, за которым следует полная цепочка сертификатов:

cat mail.example.com.key mail.example.com.crt intermediate.pem 
> /etc/postfix/ssl/mail.example.com.chain.pem
sudo chmod 600 /etc/postfix/ssl/mail.example.com.chain.pem

Затем в /etc/postfix/main.cf:

smtpd_tls_chain_files = /etc/postfix/ssl/mail.example.com.chain.pem
smtpd_tls_security_level = may

В Postfix старше версии 3.4 используйте устаревшую пару директив, при этом ключ и сертификат с полной цепочкой хранятся в отдельных файлах:

smtpd_tls_cert_file = /etc/postfix/ssl/mail.example.com.fullchain.crt
smtpd_tls_key_file  = /etc/postfix/ssl/mail.example.com.key
smtpd_tls_security_level = may

Полное пошаговое руководство по установке, включая сервис отправки на порту 587 и проверку с помощью OpenSSL, находится в нашем руководстве по установке SSL для Postfix.

Сгенерировать CSR на других почтовых платформах

Используете другой почтовый сервер или шлюз? Смотрите наши другие руководства по CSR:

• Courier IMAP Server
• Kerio Connect
• Qmail
• SurgeMail
• Zimbra
• Все учебные материалы по генерации CSR