Server Admin Авторский блог системного администратора
Я давно написал и поддерживаю в актуальном состоянии статьи про настройку почтовых серверов. При этом до сих пор не дошли руки описать использование в них бесплатных сертификатов. Так что сегодня я расскажу, как настроить бесплатный SSL/TLS сертификат от Let's Encrypt для использования в postfix и dovecot
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Реклама ИП Скоромнов Д.А. ИНН 331403723315
Введение
Речь пойдет про типовой почтовый сервер, настроенный самостоятельно на базе популярных бесплатных компонентов - Настройка 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. Если есть замечания и предложения, жду их в комментариях.
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Реклама ИП Скоромнов Д.А. ИНН 331403723315
Добрый день.
Я настроил почтовый сервер по Вашей статье. Настройка postfix + dovecot + postfixadmin + roundcube + dkim на Debian. Установил certbot для nginx
python3-certbot-nginx.
При запуске он находит домен: webmail.mydomain.ru
Извините за глупый вопрос. Это ошибка ? Я правильно понимаю, что сертификат должен быть на имя почтового сервера . Т.е. по Вашей статье
mail.rocky-linux.ru. И Certbot должен был найти именно его (mail.mydomain.ru)?
Сертификат для почтового сервера должен быть свой, для веб интерфейса свой, если у них разные доменные имена. Это имя может быть и одинаковым, но я не рекомендую так делать.
Здравствуйте. Столкнулся с любопытной проблемой, при выполнении команды certbot renew появляется ошибка:
Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: sub.mydomain.ru
Type: unauthorized
Detail: тут.ip.адрес: Invalid response from http://sub.mydomain.ru/.well-know/acme-challenge/somekey: 404
Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.
Failed to renew certificate sub.mydomain.ru with error: Some challenges have failed.
У меня есть предположения, что это проблема с DNS или firewall на стороне шлюза. Как Вы считаете, с чем может быть связана проблема?
А что тут любопытного? Проблема описана прямым текстом:
Invalid response from http://sub.mydomain.ru/.well-know/acme-challenge/somekey: 404
404 ошибка при попытке проверить указанный выше урл. В чём тут причина можно только гадать. Скорее всего ошибка в настройке веб сервера, на котором происходит проверка. Указанный урл http://sub.mydomain.ru/.well-know/acme-challenge/ должен работать и давать ответ 200, а не 404.
1 1 * * * root /usr/bin/certbot renew
А оно работает?
у меня просто не сработало пару раз на Nginx и CentOS
Оказалось, что вот nginx оно не нашло (
"Could not find a usable 'nginx' binary. Ensure nginx exists, "
Поправил конечно. Но вот в таком виде не захотело работать.
По-моему упустили важный момент для postfix. Нужно перечитать хеш для БД postfix-а, иначе он не увидит новые сертификаты. У меня без этого не работает.
Для postfix в случае обновления сертификатов (уже получены новые) недостаточно выполнить:
systemctl reload postfix
нужно обязательно:
postmap -F hash:/etc/postfix/vmail_ssl.map && systemctl reload postfix
нужно переписать сертификаты в базе самого postfix с перечитыванием хеша. Иначе так и будут старые сертификаты использоваться postfix-ом.
Для dovecot достаточно:
systemctl reload dovecot
Если в postfix напрямую прописаны сертификаты в конфиге, то никакие хэши обновлять не надо. А сервисы да, нужно перезапустить, или как минимум перечитать конфиг. Это вообще универсальное правило для всех популярных служб. После обновления сертификатов нужно перечитать конфигурацию, потому что по сути она поменялась.
"Если в postfix напрямую прописаны сертификаты в конфиге, то никакие хэши обновлять не надо. "
Вроде бы так это и должно работать. Но не работает.
Файлы сертификатов есть.
В конфиге прописано НАПРЯМУЮ (это же напрямую или нет?):
============
smtpd_tls_chain_files = /www/server/panel/plugin/mail_sys/cert/site.su/privkey.pem,/www/server/panel/plugin/mail_sys/cert/site.su/fullchain.pem
tls_server_sni_maps = hash:/etc/postfix/vmail_ssl.map
============
в файле vmail_ssl.map тоже прописаны те же самые сертификаты
Вроде бы достаточно?
Но не работает только если перечитать или перезапустить. postfix в моем случае продолжает работать со старыми сертификатами, хоть и файлов этих старых сертификатов уже нет. Если файлов сертификатов не существует, то логично, что postfix их берет из своей БД?
systemctl reload postfix
или
systemctl restart postfix
тоже не работает.
А совместно с
postmap -F hash:/etc/postfix/vmail_ssl.map
все работает.
Для меня это загадка, если вы пишите, что достаточно напрямую прописать сертификаты в конфиге.
Не могу понять, что я упускаю в таком случае?
У меня в статье нету этой настройки:
tls_server_sni_maps = hash:/etc/postfix/vmail_ssl.map
Я не знаю, зачем она нужна. В общем случае для работы TLS сертификатов она не нужна. А у вас раз прописана, значит надо обновлять хэш от этой настройки.
Приветствую. А как привязать сертификат от летэнкрипт к opendkim? При отправке письма прикрепляется подпись opendkim которая не соответствует летэнкрипт и от этого письма будут в спам попадать.
Думали об этом?
Зачем это? В этом нет никакого смысла. Открытую часть вы публикуете в DNS, закрытая часть на почтовом сервере. Тут не нужны никакие подтверждения валидности сертификата через центры сертификации.
Я поигрался с tls_policy_maps, но я так и не понял применяются ли они вообще. Но потом я еще поковырялся в логах и заметил, что когда удаленный сервер работает с моим самоподписанным сертификатом, то подключение происходит с использованием TLSv1.2 и шифром ECDHE-RSA-AES256-SHA384.
Я проверил сам себя напечатав openssl s_client -starttls smtp -cipher ECDHE-RSA-AES256-SHA384 -connect mail.myserver.ru:25 и увидел сертификат и используемый протокол TLSv1.3. Потом указал использовать TLSv1.2 и тоже увидел сертификат, но когда я прописал в конфиг постфикса сертификат от LE, то мне сказали вот так:
[root@mail ~]# openssl s_client -starttls smtp -cipher ECDHE-RSA-AES256-SHA384 -connect mail.myserver.ru:25 -tls1_2
CONNECTED(00000003)
140494004447040:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1544:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 260 bytes and written 188 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1689235154
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
В общем решил. Проблема оказалась в том, что виноват установленный certbot от LE по их инструкции. Почему и как это уже не знаю - не понимаю как оно там работает
Не пронял, при чём тут certbot? Это просто обвязка на python, которая помогает получить сертификат. Как он может влиять на работу приложений?
Извините, я от радости не очень полно описал что помогло решить проблему.
Так вот, как я выяснил тот проблемный сервер работает под MS Exchange 2013 (назову его "сервер 1") и прекрасно работает с использованием шифра ECDHE-RSA-AES256-SHA384 при помощи TLSv1.2. А параллельно с ним есть еще один MS почтарь посвежее (а его назову "сервер 2"), который тоже работает с TLSv1.2, но с похожим шифром ECDHE-RSA-AES256-GCM-SHA384, видимо посвежее, не шарю. Проблема заключалась в том, что как только я меняю в конфиге постфикса самоподписанные сертификаты на LE'шные, то "сервер 1" не может договориться с моим сервером и соединиться, а "сервер 2" при этом никаких проблем не испытывает.
Решил попробовать подрубить сертификаты LE и указать шифр, с которым работает "сервер 1" + параметр -tls1_2, но как оказалось оно не видит сертификат, а самоподписанный - видит.
Долго пытался понять что и почему, но так и не понял, пока не заметил разницу в установке certbot между инструкцией от разработчика и этой статьей. Здесь Вы ставите дополнительно эти пакеты: python3-certbot-apache и mod_ssl. Я их значит тоже ставлю, генерирую сертификат и оно просто начинает работать без каких-либо изменений.
При установке сертификатов от Let's Encrypt столкнулся с тем, что с определенного сервера перестала приходить почта. Это не какой-то крупный почтовый сервис, а лишь внутренняя почта одной компании. И вот не могу понять в чем конкретно заключается проблема - в отсутствии поддержки SSLv3 со стороны отправителя (если такое возможно) или же свежие сертификаты 'LE' не работают с SSLv2 (я не силен в TLS, возможно бред написал).
При смене самоподписанных сертификатов (настройка mail сервера сделана по Вашей статье) на нормальные для postfix и dovecot с того же гугла или там яндекса все отлично приходит, а вот касаемо ранее упомянутого сервера в логе постфикса наблюдалась такая картина:
...
postfix/smtpd[2079827]: connect from mail.xxxxx.ru[xx.xx.xx.xx]
postfix/smtpd[2079827]: SSL_accept error from mail.xxxxx.ru[xx.xx.xx.xx]: -1
postfix/smtpd[2079827]: warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:ssl/statem/statem_srvr.c:2285:
postfix/smtpd[2079827]: lost connection after STARTTLS from mail.xxxxx.ru[xx.xx.xx.xx]
postfix/smtpd[2079827]: disconnect from mail.xxxxx.ru[xx.xx.xx.xx] ehlo=1 starttls=0/1 commands=1/2
...
Что оно все таки хочет? От меня какие-то правильные настройки TLS или от сервера отправителя поддержку SSLv3?
Забыл добавить, что при использовании самоподписанных сертов я исправно получаю почту с этого сервера, а подключение происходит с использованием TLS 1.2
Судя по всему, там какая-то старая система и у неё нет свежих шифров, которые используются в современных сертификатах от LE.
Вот ошибка: no shared cipher
А эти сертификаты от LE могут работать со старыми шифрами или это никак не настроить и нужно чтобы отправитель у себя обновил систему?
Вам будет проще настроить исключение для этого клиента, чтобы общаться с ним без шифрования. Я описываю, как это сделать, в своей статья по настройке postfix:
https://serveradmin.ru/nastrojka-postfix-dovecot-postfixadmin-roundcube-dkim-na-debian/#Nastrojka_postfix
Ищите по фразе tls_policy_maps.
Добрый день! Вопрос, обязательно разносить сервер и веб интерфейс на разные доменные имена ? возможно ли сделать сервер mail.site.ru и веб интерфейс по этому же адресу ? тогда, и сертификат понадобится один
Да, так можно сделать. Но могут быть неудобства. Например, у вас локальная сеть и всем пользователям настроен доступ по доменному имени в почтовых программах. Когда почтовый сервер и веб сервер размещаются на одном сервере, это не проблема. Но если вы захотите веб сервер с веб интерфейсом сделать на отдельной виртуальной машине, начнутся проблемы, так как доменное имя одно, а сервисы разные на разных серверах. Я лично с этим сталкивался и было неудобно. Так что для более гибких настроек я бы лучше разделял доменные имена почтового сервера и веб интерфейса.
Спасибо за ответ
Добрый день. Есть вопрос на который не могу найти ответ, может вы подскажете.
В планах создать отказоустойчивый сервер почты на двух провайдерах.
Схема примерно такая - ВМ с БД пользователей и maildir (по NFS подключается к почтовым серверам) (только локальная сеть)
ВМ с первым провайдером и hostname mx1.domain
ВМ с вторым провайдером и hostname mx2.domain
Сертификаты выданы на каждое A имя и прописаны в postfix/dovecot
Поднят apache и получен на имя mail.domian на каждом хосте
Возможно ли прописать два CNAME с mail на mx1 и mx2, чтоб прописать в почтовых клиентах и как настроить сертификаты правильно?
те как работает тот же сервер imap у яндекса, где есть общее имя, а дальше резолвится в поддомены.
Так по идее нельзя сделать. Вам нужен какой-то прокси сервер, например на базе haproxy, который будет раскидывать подключения по разным почтовым серверам. У этого haproxy будет своё доменное имя, которое пропишите клиентам. А у серверов будут свои доменные имена. Мне кажется, архитектурно правильно сделать именно так. А уж сам haproxy можно повесить через плавающий ip типа keepalived и организовать его высокую доступность таким образом.
Спасибо за ответ, понял Вас, посмотрю в эту сторону.
Пока проводил эксперименты, выпустил через let's encrypt сертификат с параметром --expand mail.domian, браузеры не ругаются на сертификат, почтовые клиенты тоже.
Добрый день
Задача поставить 2 почтовых сервера на 1 Ip
mail.site1.ru
mail.site2.ru
с этом случае как правильно сертификаты сделать?
1. в апач сделал 4 вирт сервера
2. сертификаты пока не получал
3. в /etc/postfix/main.cf тоже 2 прописывать
Почтовый сервер в общем случае может быть только один. И для него выпускается сертификат. А потом этот сервер может обслуживать любое количество почтовых доменов. Вы не настроите так просто на одном сервере два почтовых сервера с разными доменными именами. Это непростая задача. Я не знаю даже примерно, как её решать. Обычно её и не решают, так как имя почтового сервера никак не привязано к почтовым доменам, которые он обслуживает. Так что нет смысла делать два разных почтовых сервера с разными доменными именами.
Добрый день! Можете подсказать пожалуйста? Правильно ли я понимаю, что если: у меня один домен 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 для почты?