Home » Linux » CentOS » Настройка SSL/TLS сертификатов Let's Encrypt в postfix и dovecot

Настройка SSL/TLS сертификатов Let's Encrypt в postfix и dovecot

Я давно написал и поддерживаю в актуальном состоянии статьи про настройку почтовых серверов. При этом до сих пор не дошли руки описать использование в них бесплатных сертификатов. Так что сегодня я расскажу, как настроить бесплатный SSL/TLS сертификат от Let's Encrypt для использования в postfix и dovecot

Углубленный онлайн-курс по MikroTik

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.

Настройка 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

Получение сертификата Let's Encrypt

Пакеты эти живут в репозитории 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 для автоматического создания учетной записи. Затем выбрать по очереди каждый из доменов для создания бесплатного сертификата.

Запуск cerbot

Если все прошло без ошибок, то вы увидите в директории /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 tls сертификата по smtp

Если у вас все в порядке, значит настройка ssl в postfix закончена. Остался последний штрих.

Обновление сертификатов почтового сервера

В Centos 8 certbot почему-то не добавил себя в планировщики. Ни в cron, ни в systemd timers. Но нам мало обновить сертификаты, нужно еще перезапустить службы, которые его используют. Для этого идем в конфиг letsencrypt для каждого домена и добавляем в самый конец параметр.

post_hook = systemctl reload postfix dovecot httpd

Сделать это нужно в конфигурационных файлах в директории /etc/letsencrypt/renewal/. Там для каждого домена будет свой конфиг. После этого можете прогнать тест обновления, чтобы убедиться в том, что ошибок нет.

# certbot renew --dry-run

Обновление сертификата через certbot

Все в порядке. Можно добавлять задание в /etc/crontab, или в любой другой конфиг, как вы обычно делаете. Я больше люблю все задачи держать в одном системном конфиге crontab.

1 1 * * * root /usr/bin/certbot renew

На этом у меня все по настройке SSL/TLS сертификатов в почтовом сервере postfix + dovecot. Если есть замечания и предложения, жду их в комментариях.

Углубленный онлайн-курс по MikroTik.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

56 комментариев

  1. Михаил Александрович Карташев

    1 1 * * * root /usr/bin/certbot renew

    А оно работает?
    у меня просто не сработало пару раз на Nginx и CentOS
    Оказалось, что вот nginx оно не нашло (
    "Could not find a usable 'nginx' binary. Ensure nginx exists, "
    Поправил конечно. Но вот в таком виде не захотело работать.

  2. Роман М.

    По-моему упустили важный момент для 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 сертификатов она не нужна. А у вас раз прописана, значит надо обновлять хэш от этой настройки.

  3. Александр

    Приветствую. А как привязать сертификат от летэнкрипт к opendkim? При отправке письма прикрепляется подпись opendkim которая не соответствует летэнкрипт и от этого письма будут в спам попадать.
    Думали об этом?

    • Зачем это? В этом нет никакого смысла. Открытую часть вы публикуете в DNS, закрытая часть на почтовом сервере. Тут не нужны никакие подтверждения валидности сертификата через центры сертификации.

  4. Я поигрался с 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. Я их значит тоже ставлю, генерирую сертификат и оно просто начинает работать без каких-либо изменений.

  5. При установке сертификатов от 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

  6. Вячеслав

    Добрый день! Вопрос, обязательно разносить сервер и веб интерфейс на разные доменные имена ? возможно ли сделать сервер mail.site.ru и веб интерфейс по этому же адресу ? тогда, и сертификат понадобится один

    • Да, так можно сделать. Но могут быть неудобства. Например, у вас локальная сеть и всем пользователям настроен доступ по доменному имени в почтовых программах. Когда почтовый сервер и веб сервер размещаются на одном сервере, это не проблема. Но если вы захотите веб сервер с веб интерфейсом сделать на отдельной виртуальной машине, начнутся проблемы, так как доменное имя одно, а сервисы разные на разных серверах. Я лично с этим сталкивался и было неудобно. Так что для более гибких настроек я бы лучше разделял доменные имена почтового сервера и веб интерфейса.

  7. Добрый день. Есть вопрос на который не могу найти ответ, может вы подскажете.
    В планах создать отказоустойчивый сервер почты на двух провайдерах.
    Схема примерно такая - ВМ с БД пользователей и 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, браузеры не ругаются на сертификат, почтовые клиенты тоже.

  8. Добрый день
    Задача поставить 2 почтовых сервера на 1 Ip
    mail.site1.ru
    mail.site2.ru
    с этом случае как правильно сертификаты сделать?
    1. в апач сделал 4 вирт сервера
    2. сертификаты пока не получал
    3. в /etc/postfix/main.cf тоже 2 прописывать

    • Почтовый сервер в общем случае может быть только один. И для него выпускается сертификат. А потом этот сервер может обслуживать любое количество почтовых доменов. Вы не настроите так просто на одном сервере два почтовых сервера с разными доменными именами. Это непростая задача. Я не знаю даже примерно, как её решать. Обычно её и не решают, так как имя почтового сервера никак не привязано к почтовым доменам, которые он обслуживает. Так что нет смысла делать два разных почтовых сервера с разными доменными именами.

  9. Добрый день! Можете подсказать пожалуйста? Правильно ли я понимаю, что если: у меня один домен example.com, один внешний ip, в локальной сети за nat два сервера, один почта mail.example.com другой сайт site.example.com, то нужно на каком-то одном получить все сертификаты через certbot , а потом перетащить нужные сертификаты на второй сервер? Или как-то по другому решать эту проблему (второй внешний ip например)? Просто на site.example.com я уже получил сертификат, и теперь при получении сертификата mail.example.com certbot ругается, что на этом ip уже есть домен.

  10. Александр

    Сломал уже моск, не знаю что делать Может кто подскажет в какую степь копать
    Мой доменный провайдер не поддерживает ДНС проверку, руками вбивать 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 более продвинут и его давно рекомендуют к использованию. Но вот как раз из-за таких ситуаций и не хочется. Может так оказаться, что кто-то не захочет или не сможет работать с новым форматом сертификатов.

  11. Анатолий

    Добрый день. Спасибо за хорошую статью, но неясным для новичка остается небольшой момент.
    Вот не могу понять: сертификат должен быть для почтового домена или для сервера. К примеру - домен @test.net, сервер почтовый - mail.test.net, сертификат должен быть для 1) test.net или
    2) mail.test.net

    Хотелось бы получить небольшое разъяснение.

    • Для почтового сервера. Доменов может быть много разных. Но проверка идёт самого почтового сервера и его имени.

  12. Здравствуйте.

    Могу ли я использовать 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>

        В чем может быть причина?

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

  13. Добрый день
    Подскажите пожалуйста по моей проблеме - сделал сертификаты вместо самоподписанных, теперь в логе 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. Вы перепутали приватный ключ и сертификат. Ключ это ключ, а сертификат - сертификат. Их не надо путать.

  14. Вообще всё сломалось. Not Found The requested URL / was not found on this server. Благо сегодня выходной. Что делать...? Как вернуть хотя бы всё как было...? Почта в тандербёрде не ходит, веб-интерфейс не грузится...

    • В статье вообще нет ничего, что могло бы сломать работу почты. Вы в конфигах postfix и dovecot только путь к сертификатам меняете и все. Вернитесь обратно на те сертификаты, с которыми все нормально работало. А на будущее, тестируйте все изменения сначала на тестовых серверах, а не рабочих.

  15. 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-ый порт в виртуальный хост. Но вроде всё же добавлено.

  16. Альберт

    После добавление 2х вирт хостов у меня не работает postfixadmin ошибка 404 все на месте каталог postfixadmin тоже на месте с веб сервером кроме 2х хостов виртуальныйх ничего не делал.Как починить???

    • А вы до этого как в postfixadmin ходили? По ip адресу?

      • Альберт

        да ip/postfixadmin

        • А по ip вообще открывается страница заглушка? Я вот буквально только что все закончил по этой статье настраивать. Все получилось. Если уже настроили сертификаты, то проще перенести директории с postfixadmin и roundcube в какие-то виртуальные хосты и ходить туда по https. Я так делаю.

  17. И certbot всё время ругается на то что 80 порт занят httpd Приходиться его останавливать потом запускать выпуск сертификатов. Как это можно обойти?

    • Это происходит, когда вы выбираете подтверждение через запуск собственного веб сервера certbot. Но он не может его запустить, потому что у вас apache работает на 80-м порту. Подтверждайте другим способом, через webroot.

  18. Не знаете с чем может быть связана данная ошибка, до последнего времени обновлялись сертификаты без проблем!

    [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. Вам надо разбираться с настройками веб сервера, почему так происходит.

  19. Спасибо.
    Развернул на Proxmox VE связку Debian + postfix + dovecot + Sogo + nginx + apache solr + apache tika + Proxmox Mail Gateway (антиспам + логирование кто-куда-когда). Привязал все это к AD. Бэкапы (инкрементные) ВМ выполняет Proxmox Backup Server (на днях вышел релиз). Периметр сторожит pfsense. В кач-ве NAS - xigmanas и OMV.

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.
Используешь Telegram? Подпишись на канал автора →
This is default text for notification bar