Я давно написал и поддерживаю в актуальном состоянии статьи про настройку почтовых серверов. При этом до сих пор не дошли руки описать использование в них бесплатных сертификатов. Так что сегодня я расскажу, как настроить бесплатный SSL/TLS сертификат от Let's Encrypt для использования в postfix и dovecot
Введение
Речь пойдет про типовой почтовый сервер, настроенный самостоятельно на базе популярных бесплатных компонентов - Настройка postfix + dovecot + mysql база + postfixadmin + roundcube + dkim на CentOS 8. В качестве бэкенда для web сервера там используется apache, так что получать сертификаты будем с его помощью.
В ситуации с непубличным почтовым сервером нет принципиальной необходимости использовать подтвержденный сертификат. Вы запросто можете выпустить свой самоподписаный и использовать его. Пользователям достаточно будет подтвердить, что они доверяют этому сертификату и проблем не будет.
Тем не менее, последнее время наблюдается тенденция по выдавливанию самоподписанных сертификатов из обращения. Некоторый софт напрочь отказывается им доверять, не оставляя возможность пользователям это исправить. Вместо того, чтобы бороться с софтом, я предлагаю вам настроить всем известные сертификаты от let's encrypt. К тому же сделать это относительно просто.
Получаем сертификат от Let's Encrypt
Итак, я считаю, что вы настроили почтовый сервер по предложенной выше ссылке. Значит, у вас установлен веб сервер Apache, а так же все в порядке с dns записями. Сертификатов мы получим сразу два. Для доменных имен:
- mail.site.ru - имя почтового сервера, этот сертификат будут использовать postfix и apache
- webmail.site.ru - домен для web интерфейса почты, будет использовать веб сервер
Для настройки получения сертификатов let's encrypt и настройки apache, нам нужно будет установить несколько пакетов. Напоминаю, что речь идет про Centos 8. В других системах настройка будет аналогичной, только имена пакетов могут отличаться.
# dnf install certbot python3-certbot-apache mod_ssl
Пакеты эти живут в репозитории epel, так что если он еще не подключен, подключите.
# dnf install epel-release
Дальше нам нужно добавить 2 виртуальных домена в настройки apache. Для этого создаем 2 конфига в директории /etc/httpd/conf.d/.
1. mail.site.ru.conf
<VirtualHost *:443> ServerName mail.site.ru DocumentRoot /var/www/mail.site.ru/ <Directory /var/www/mail.site.ru/> Options -Indexes +FollowSymLinks AllowOverride All </Directory> ErrorLog /var/log/httpd/mail.site.ru-error.log CustomLog /var/log/httpd/mail.site.ru-access.log combined </VirtualHost> <VirtualHost *:80> ServerName mail.site.ru DocumentRoot /var/www/mail.site.ru/ <Directory /var/www/mail.site.ru/> Options -Indexes +FollowSymLinks AllowOverride All </Directory> ErrorLog /var/log/httpd/mail.site.ru-error.log CustomLog /var/log/httpd/mail.site.ru-access.log combined </VirtualHost>
2. webmail.site.ru.conf
<VirtualHost *:443> ServerName webmail.site.ru DocumentRoot /var/www/webmail.site.ru/ <Directory /var/www/webmail.site.ru/> Options -Indexes +FollowSymLinks AllowOverride All </Directory> ErrorLog /var/log/httpd/webmail.site.ru-error.log CustomLog /var/log/httpd/webmail.site.ru-access.log combined </VirtualHost> <VirtualHost *:80> ServerName webmail.site.ru DocumentRoot /var/www/webmail.site.ru/ <Directory /var/www/webmail.site.ru/> Options -Indexes +FollowSymLinks AllowOverride All </Directory> ErrorLog /var/log/httpd/webmail.site.ru-error.log CustomLog /var/log/httpd/webmail.site.ru-access.log combined </VirtualHost>
По сути конфиги идентичные, только названия доменов разные. Теперь можно проверить конфигурацию apache и перезапустить его.
# apachectl -t # apachectl reload
Если увидите ошибку:
AH00526: Syntax error on line 85 of /etc/httpd/conf.d/ssl.conf: SSLCertificateFile: file '/etc/pki/tls/certs/localhost.crt' does not exist or is empty
Просто удалите конфиг /etc/httpd/conf.d/ssl.conf. Он нам не нужен.
Если нет ошибок, то можно запускать certbot и получать сертификаты. Делается это очень просто.
# certbot --apache
При первом запуске вам нужно будет указать email для автоматического создания учетной записи. Затем выбрать по очереди каждый из доменов для создания бесплатного сертификата.
Если все прошло без ошибок, то вы увидите в директории /etc/letsencrypt/live две папки с сертификатами для каждого из доменов.
Так же certbot автоматически добавит в конфигурации виртуальных хостов apache несколько дополнительных параметров.
<VirtualHost *:443> ServerName webmail.site.ru DocumentRoot /var/www/webmail.site.ru/ <Directory /var/www/webmail.site.ru/> Options -Indexes +FollowSymLinks AllowOverride All </Directory> ErrorLog /var/log/httpd/webmail.site.ru-error.log CustomLog /var/log/httpd/webmail.site.ru-access.log combined SSLCertificateFile /etc/letsencrypt/live/mail.site.ru/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/mail.site.ru/privkey.pem Include /etc/letsencrypt/options-ssl-apache.conf </VirtualHost> <VirtualHost *:80> ServerName webmail.site.ru DocumentRoot /var/www/webmail.site.ru/ <Directory /var/www/webmail.site.ru/> Options -Indexes +FollowSymLinks AllowOverride All </Directory> ErrorLog /var/log/httpd/webmail.site.ru-error.log CustomLog /var/log/httpd/webmail.site.ru-access.log combined RewriteEngine on RewriteCond %{SERVER_NAME} =mail.site.ru RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent] </VirtualHost>
В этот виртуальный хост установите веб почту, если вам она нужна.
Let's Encrypt в Postfix
Теперь настроим postfix на работу с бесплатным сертификатом от let's encrypt. Для этого достаточно в конфигурационный файл /etc/postfix/main.cf добавить несколько параметров:
smtpd_tls_key_file = /etc/letsencrypt/live/mail.site.ru/privkey.pem smtpd_tls_cert_file = /etc/letsencrypt/live/mail.site.ru/fullchain.pem
Этого достаточно при условии, что вы настраивали postfix по моей статье. Если нет - сходите, сверьтесь. Там есть еще некоторые параметры, касающиеся tls.
После этого надо перечитать конфигурацию postfix.
# systemctl reload postfix
Dovecot и сертификаты Let's Encrypt
Дальше проделаем то же самое, только для Dovecot. Настроим его на работу с сертификатом let's encrypt. Для этого добавляем в его конфиг /etc/dovecot/dovecot.conf параметры.
ssl_cert = </etc/letsencrypt/live/mail.site.ru/fullchain.pem ssl_key = </etc/letsencrypt/live/mail.site.ru/privkey.pem
И так же перечитываем конфигурацию.
# systemctl reload dovecot
Теперь можно проверить корректность настройки.
Проверка сертификата ssl/tls в почтовом сервере
Способов проверить сертификат в почтовом сервере множество. Например, у меня есть статья, где я настраиваю мониторинг сертификатов с помощью Zabbix. Там же есть примеры и для почтового сервера. Вот так с помощью openssl в консоли сервера можно посмотреть текущие сертификаты.
# openssl s_client -starttls smtp -connect mail.site.ru:25 | openssl x509 -noout -dates 2>/dev/null | grep notAfter | cut -d'=' -f2
Это самый простой и быстрый способ. Можете проверить прямо из консоли почтового сервера. Так же можно воспользоваться каким-то готовым сервисом, например https://ssl-tools.net/mailservers.
Если у вас все в порядке, значит настройка ssl в postfix закончена. Остался последний штрих.
Обновление сертификатов почтового сервера
В Centos 8 certbot почему-то не добавил себя в планировщики. Ни в cron, ни в systemd timers. Но нам мало обновить сертификаты, нужно еще перезапустить службы, которые его используют. Для этого идем в конфиг letsencrypt для каждого домена и добавляем в самый конец параметр.
post_hook = systemctl reload postfix dovecot httpd
Сделать это нужно в конфигурационных файлах в директории /etc/letsencrypt/renewal/. Там для каждого домена будет свой конфиг. После этого можете прогнать тест обновления, чтобы убедиться в том, что ошибок нет.
# certbot renew --dry-run
Все в порядке. Можно добавлять задание в /etc/crontab, или в любой другой конфиг, как вы обычно делаете. Я больше люблю все задачи держать в одном системном конфиге crontab.
1 1 * * * root /usr/bin/certbot renew
На этом у меня все по настройке SSL/TLS сертификатов в почтовом сервере postfix + dovecot. Если есть замечания и предложения, жду их в комментариях.
Добрый день! Можете подсказать пожалуйста? Правильно ли я понимаю, что если: у меня один домен example.com, один внешний ip, в локальной сети за nat два сервера, один почта mail.example.com другой сайт site.example.com, то нужно на каком-то одном получить все сертификаты через certbot , а потом перетащить нужные сертификаты на второй сервер? Или как-то по другому решать эту проблему (второй внешний ip например)? Просто на site.example.com я уже получил сертификат, и теперь при получении сертификата mail.example.com certbot ругается, что на этом ip уже есть домен.
Сломал уже моск, не знаю что делать Может кто подскажет в какую степь копать
Мой доменный провайдер не поддерживает ДНС проверку, руками вбивать txt записи не самый приятный вариант
Поднял nginx proxi manager. И вещь хорошая, и сам продлевает летскрипты, но для моего почтовика сертификаты которые он генерирует не подходят - НПМ делает сертификат из 4 PEM файлов с коротким приваткеем, а communigate pro понимает только RSA приват кей. Вилд сертификат как у вас получается в нужном формате, но из за невозможности автоматом прописать ТХТ запись продлевать такой сертификат будет крайне не удобно (4 домена)
Пытался искать по теме конвертации обычного кея в RSA, но ничего путнего не нашёл.
Сертификаты обычно без проблем конвертятся в разные форматы. Ищите информацию на эту тему. Я еще ни разу не сталкивался с тем, что нельзя было получить нужный формат.
Может кто то как и я упрётся в подобное. Нжинкс прокси менеджер по умолчанию генерирует ключи в key-type = ecdsa. Типа это модно, молодёжно и в таком духе. На 968 вкладке браузера случайно наткнулся на эту инфу и стал копать вглубь. Нужно в файле /etc/letssrypt.ini в докере заменить строчку на key-type = rsa и вот этот ключик прекрасно конвертится (openssl rsa -inform pem -in /root/letsencrypt/live/npm-11/privkey.pem -outform pem -out privkey-rsa.pem) и имеет нужную длину.
Спасибо за информацию. Формат ecdsa более продвинут и его давно рекомендуют к использованию. Но вот как раз из-за таких ситуаций и не хочется. Может так оказаться, что кто-то не захочет или не сможет работать с новым форматом сертификатов.
Добрый день. Спасибо за хорошую статью, но неясным для новичка остается небольшой момент.
Вот не могу понять: сертификат должен быть для почтового домена или для сервера. К примеру - домен @test.net, сервер почтовый - mail.test.net, сертификат должен быть для 1) test.net или
2) mail.test.net
Хотелось бы получить небольшое разъяснение.
Для почтового сервера. Доменов может быть много разных. Но проверка идёт самого почтового сервера и его имени.
Спасибо за пояснение! Я так и сделал)
Здравствуйте.
Могу ли я использовать SSL сертификат своего веб сайта на почтовом сервере, то есть на postfix и dovecot?
Там 2 файла .crt и .key. Мне обязательно их конвертировать на .pem?
Можете без проблем. Конвертить не обязательно.
Спасибо.
Для начала, я прописал эти сертификаты в dovecot (.crt, .key).
При перезагрузке dovecot - все ок, никаких ошибок нет.
Но при подключении через клиента, входящие письма не принимаются.
Выдается ошибка - TLS принудительно закрыл соединение.
Также, при перезагрузке dovecot, он не спросил у меня пароль от ключа (.key).
В чем может быть проблема? Я не прописал ca-bundle файл - это может быть причиной?
Так трудно сказать, в чем проблема. Нужно подробно логи смотреть. Вы пишите про настройки dovecot, но говорите, что не приходят входящие письма. За прием почты отвечает postfix, а не dovecot.
Спасибо.
Прием почты - я имел ввиду когда клиент забирает письма с сервера через IMAP.
Естественно, IMAP настраивается в конфигурациях dovecot.
Хорошо, я поделюсь логами.
Здравствуйте! Пока не смог разобраться.
Прописал сертификат и ключ в настройках Dovecot.
В логах выдает такую ошибку:
imap-login: Error: Failed to initialize SSL server context: Couldn't parse private SSL key: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt, error:0906A065:PEM routines:PEM>
В чем может быть причина?
Я не знаю, не сталкивался с таким. Возможно проблема с зашифрованным приватным ключом. Я всегда использую ключи без паролей.
Добрый день
Подскажите пожалуйста по моей проблеме - сделал сертификаты вместо самоподписанных, теперь в логе dovecot получаю
Feb 04 02:29:34 imap-login: Error: Failed to initialize SSL server context: Can't load SSL certificate: The file contains a private key (you've mixed ssl_cert and ssl_key settings): user=, rip=217.69.142.136, lip=192.168.0.177, session=
Почтовые клиенты не подключаются по imap. Что я не так сделал?
В тексте ошибки все написано. У вас в файле сертификата содержится private key. Вы перепутали приватный ключ и сертификат. Ключ это ключ, а сертификат - сертификат. Их не надо путать.
Спасибо, я действительно перепутал строки
Вообще всё сломалось. Not Found The requested URL / was not found on this server. Благо сегодня выходной. Что делать...? Как вернуть хотя бы всё как было...? Почта в тандербёрде не ходит, веб-интерфейс не грузится...
В статье вообще нет ничего, что могло бы сломать работу почты. Вы в конфигах postfix и dovecot только путь к сертификатам меняете и все. Вернитесь обратно на те сертификаты, с которыми все нормально работало. А на будущее, тестируйте все изменения сначала на тестовых серверах, а не рабочих.
Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80.
Добавить 80-ый порт в виртуальный хост. Но вроде всё же добавлено.
После добавление 2х вирт хостов у меня не работает postfixadmin ошибка 404 все на месте каталог postfixadmin тоже на месте с веб сервером кроме 2х хостов виртуальныйх ничего не делал.Как починить???
А вы до этого как в postfixadmin ходили? По ip адресу?
да ip/postfixadmin
А по ip вообще открывается страница заглушка? Я вот буквально только что все закончил по этой статье настраивать. Все получилось. Если уже настроили сертификаты, то проще перенести директории с postfixadmin и roundcube в какие-то виртуальные хосты и ходить туда по https. Я так делаю.
по ip заглушка работает, решил перевести postfixadmin на порт 8080
И certbot всё время ругается на то что 80 порт занят httpd Приходиться его останавливать потом запускать выпуск сертификатов. Как это можно обойти?
Это происходит, когда вы выбираете подтверждение через запуск собственного веб сервера certbot. Но он не может его запустить, потому что у вас apache работает на 80-м порту. Подтверждайте другим способом, через webroot.
Не знаете с чем может быть связана данная ошибка, до последнего времени обновлялись сертификаты без проблем!
[root@srv conf.d]# certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/srv.zflan.pp.ua.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator standalone, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for srv.geolan.pp.ua
http-01 challenge for srv.zflan.pp.ua
Waiting for verification...
Challenge failed for domain srv.geolan.pp.ua
Challenge failed for domain srv.zflan.pp.ua
http-01 challenge for srv.geolan.pp.ua
http-01 challenge for srv.zflan.pp.ua
Cleaning up challenges
Attempting to renew cert (srv.zflan.pp.ua) from /etc/letsencrypt/renewal/srv.zflan.pp.ua.conf produced an unexpected error: Some challenges have failed.. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/srv.zflan.pp.ua/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/srv.zflan.pp.ua/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: srv.geolan.pp.ua
Type: unauthorized
Detail: Invalid response from
http://srv.geolan.pp.ua/.well-known/acme-challenge/lBCCYdjJqT9wAiO9-EweeSpzI5aU0iBQLBZLnvvgB9g
[45.10.34.32]: "\n\n404 Not
Found\n\nNot Found\n<p"
Domain: srv.zflan.pp.ua
Type: unauthorized
Detail: Invalid response from
http://srv.zflan.pp.ua/.well-known/acme-challenge/kBRpo6OdqY80sGlmG-nmUlRvgAQ1NxpJiwpldbPkmUo
[45.10.34.32]: "\n\n404 Not
Found\n\nNot Found\n<p"
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
- The following errors were reported by the server:
Вот ваша ошибка:
Invalid response from
http://srv.geolan.pp.ua/.well-known/acme-challenge/lBCCYdjJqT9wAiO9-EweeSpzI5aU0iBQLBZLnvvgB9g
404 Not Found
Certbot создает директорию /.well-known/acme-challenge/l в webroot, который вы указали при первом выпуске сертификата. И потом извне обращается к этой директории и файлам в ней для подтверждения того, что вы действительно владелец веб сервера. Но вместо своих файлов получает ошибку 404 Not Found. Вам надо разбираться с настройками веб сервера, почему так происходит.
Спасибо.
Развернул на Proxmox VE связку Debian + postfix + dovecot + Sogo + nginx + apache solr + apache tika + Proxmox Mail Gateway (антиспам + логирование кто-куда-когда). Привязал все это к AD. Бэкапы (инкрементные) ВМ выполняет Proxmox Backup Server (на днях вышел релиз). Периметр сторожит pfsense. В кач-ве NAS - xigmanas и OMV.
А есть на примете хорошее руководство по теме apache solr + apache tika для почты?