SSL сертификат для почтового сервера

Как я получал и прикручивал SSL сертификат для защиты трафика почтового сервера

Что требуется:
Шифрование почтовых сообщений на всех протоколах по которым они ходят.

Исходные данные:
Домен - notessysadmin.com
MX сервер (доменное имя на котором крутится почтарь) - mail.notessysadmin.com, он же сайт с вебмордой
Шифруемые протоколы - SMTP, POP, IMAP, HTTP

Получал сертификат у регистратора домена, т.е. на nic.ru. Там есть неплохой мануал, но, почему-то, они думают что сертификаты используются только для WEB, дальше объясню почему.

Заказал самый дешевый сертификат для физического лица на февраль 2013г. - "Thawte SSL123" на три года за 6570р. В общем-то не дорого, по сравнению с другими.
Стоит отметить, что данный сетрификат поддерживает только одно доменное имя, а не один домен. И может:
1. шифровать трафик
2. удостоверять владельца сайта
Если не заниматься электронной коммерцией и не заботиться о безопасности электронной корреспонденции, то по сути, авторизированная подпись и не нужна, но google mail с недавних пор перестал доверять самоподписным сертификатам при импорте почты из других почтовых служб. Поэтому и пришлось прикручивать доверенный сертификат.

Вообще, не лишним будет прочесть это.

Итак, для начала нужен CSR, как написано на nic.ru это:

"CRS(Certificate Signing Request) — запрос на получение сертификата, который представляет собой текстовый файл, содержащий в закодированном виде информацию об администраторе домена и открытый ключ."

Генерируем. Rucenter предлагает сгенерить приватный ключ для апача такой командой:

openssl genrsa -des3 -out private.key 2048

В общем-то команда правильная и, если предполагается шифровать только HTTP, POP и IMAP, то можно делать как написано и дальше не читать. Но Postfix такой ключ не примет и заставить его никак нельзя (но к голубятне и индейцу прикрутить все-же можно). В официальном руководстве Postfix'а написано:

In order to use TLS, the Postfix SMTP server generally needs a certificate and a private key. Both must be in "PEM" format. The private key must not be encrypted, meaning: the key must be accessible without a password.

Т.е. приватный ключ должен быть без пароля. За создание пароля отвечает параметр -des3, поэтому надо сгенерировать без него, переходим в каталог в котором будут храниться пароли и генерим сначала приватный ключ:

mkdir /etc/serts
cd /etc/serts
openssl genrsa -out private.key 2048

который выглядит примерно так:

а затем и CSR ключ, где notessysadmin.com - название именно домена, а не того доменного имени для которого делается сертификат. По ходу надо ответить на несколько вопросов, при чем надо быть внимательным, т.к. исправить уже будет нельзя, только перевыпустить:

# openssl req -new -key private.key -out notessysadmin.com.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:Tomsk State
Locality Name (eg, city) []:Tomsk
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:mail.notessysadmin.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

там где ответил (выделено жирным) - поля обязательные для заполнения, где нет не обязательные. Но все-равно отображение названия компании My Company при просмотре сертификата не будет, т.к. его тип этого не подразумевает, а так же сама процедура не проводит проверку компании на валидность, только владение доменом.
Появился файл запроса notessysadmin.com.csr:

Вводим в поле CSR на сайте, настраиваем нехитрые парамертры и отсылаем запрос.
Через несколько минут приходит письмо с thawte.com о просьбе подтверждения заказа, затем еще одно и, примерно через час, с nic.ru о том что процедура выпуска сертификата успешно завершена со ссылкой на сам сертификат.
Для скачивания предоставлены четыре сертификата: корневой, два промежуточный и сертификат на домен mail.notessysadmin.com, качаем все.

Опять же с никру:

Промежуточный корневой сертификат является связующим звеном в иерархической цепочке сертификатов. С его помощью пользователь сайта, на котором установлен сертификат, может проверить всю цепочку доверия и убедиться в подлинности выпущенного сертификата.

другими словами это сертификат центра сертификации (CA - Certification authority), а вот зачем их два - хз, сначала подумал чтобы показать всю цепочку от созданного сертификата до корня, но опытным путем выяснилось, что апач нормально принимает рутовый сертификат (т.е. при заходе на https://mail.notessysadmin.com не выскакивает окно о предупреждении), а вот отправка и прием из клиента Mozilla Thunderbird рутовый сертификат не принимался, но подошел один из промежуточных.

Переименовываем и копируем ключи из полученных файлов на сервер:

mail_notessysadmin_com_YYYY_MM_DD.crt -> mail.notessysadmin.com.crt root_pem_thawte_ssl123_1.crt -> root.crt intermediate_pem_thawte_ssl123_1.crt -> intermediate1 intermediate_pem_thawte_ssl123_2.crt -> intermediate2

по сути назвать их можно как угодно.

В итоге в /etc/serts получилось шесть файлов:
private.key - созданный ранее приватный ключ
notessysadmin.com.csr - запрос на сертификат, теперь можно удалить
root.crt - корневой сертификат thawte
intermediate1 - первый промежуточный сертификат
intermediate2 - второй промежуточный сертификат
mail.notessysadmin.com.crt - сам сертификат, ради которого все и затевалось

В общем-то все. Настройка демонов на SSL шифрование тема отдельной статьи, приведу только блоки с сертификатами:

#Apache - конфиг файла с доменом:
SSLCertificateKeyFile "/etc/certs/private.key"
SSLCertificateFile "/etc/certs/mail.notessysadmin.com.crt"
SSLCACertificateFile "/etc/certs/root.crt"

#Dovecot - dovecot.conf:
ssl_cert_file = /etc/certs/mail.notessysadmin.com.crt
ssl_key_file = /etc/certs/private.key
ssl_ca_file = /etc/certs/intermediate2.crt

#Postfix - main.cf:
smtpd_tls_key_file = /etc/certs/private.key
smtpd_tls_cert_file = /etc/certs/mail.notessysadmin.com.crt
smtpd_tls_CAfile = /etc/certs/intermediate2.crt

Если все правильно настроено, то сертификаты не будут просить подтверждения исключения безопасности и не добавятся к списку серверов почтового клиента в управлении сертификатами. Все должно работать.

UPD. Можно получить бесплатный сертификат такого же типа, который описан в заметке, только на один год, на startssl.com. Подробное описание как это сделать. Пользуюсь данным сервисом уже года два, рекомендую. Продлить данный сертификат, как и любой другой - нельзя, только перевыпустить.

Комментарии к посту “Получение и установка SSL сертификата для почтового сервера (Postfix, Dovecot и Apache)”

Виталий Парфенов 25.07.2014
In order to use TLS, the Postfix SMTP server generally needs a certificate and a private key. Both must be in «PEM» format. The private key must not be encrypted, meaning: the key must be accessible without a password.
А как же формат .pem? SMTP будет работать и с .key .crt?
Ответить ↓
1. admin 25.07.2014
  Цитата приводилась ради «must be … without a password»
  Да, SMTP будет работать и с .key, и с .crt.
  Ответить ↓
  1. Виталий Парфенов 25.07.2014
    Спасибо!
    Ответить ↓
Татьяна Новицкая 21.04.2015
Спасибо, объяснили блондинке как правильно создать сертификаты))
Ответить ↓

Как я получал и прикручивал SSL сертификат для защиты трафика почтового сервера

Похожие записи

Комментарии к посту “Получение и установка SSL сертификата для почтового сервера (Postfix, Dovecot и Apache)”

Добавить комментарий Отменить ответ