Код ошибки 15 lets encrypt

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

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

Введение

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

Тем не менее, последнее время наблюдается тенденция по выдавливанию самоподписанных сертификатов из обращения. Некоторый софт напрочь отказывается им доверять, не оставляя возможность пользователям это исправить. Вместо того, чтобы бороться с софтом, я предлагаю вам настроить всем известные сертификаты от let’s encrypt. К тому же сделать это относительно просто.

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

Итак, я считаю, что вы настроили почтовый сервер по предложенной выше ссылке. Значит, у вас установлен веб сервер Apache, а так же все в порядке с dns записями. Сертификатов мы получим сразу два. Для доменных имен:

Для настройки получения сертификатов let’s encrypt и настройки apache, нам нужно будет установить несколько пакетов. Напоминаю, что речь идет про Centos 8. В других системах настройка будет аналогичной, только имена пакетов могут отличаться.

Пакеты эти живут в репозитории epel, так что если он еще не подключен, подключите.

Дальше нам нужно добавить 2 виртуальных домена в настройки apache. Для этого создаем 2 конфига в директории /etc/httpd/conf. d/.

1. mail. site. ru. conf

2. webmail. site. ru. conf

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

Если увидите ошибку:

Просто удалите конфиг /etc/httpd/conf. d/ssl. conf. Он нам не нужен.

Если нет ошибок, то можно запускать certbot и получать сертификаты. Делается это очень просто.

При первом запуске вам нужно будет указать email для автоматического создания учетной записи. Затем выбрать по очереди каждый из доменов для создания бесплатного сертификата.

Если все прошло без ошибок, то вы увидите в директории /etc/letsencrypt/live две папки с сертификатами для каждого из доменов.

Так же certbot автоматически добавит в конфигурации виртуальных хостов apache несколько дополнительных параметров.

В этот виртуальный хост установите веб почту, если вам она нужна.

Let’s Encrypt в Postfix

Теперь настроим postfix на работу с бесплатным сертификатом от let’s encrypt. Для этого достаточно в конфигурационный файл /etc/postfix/main. cf добавить несколько параметров:

После этого надо перечитать конфигурацию postfix.

Dovecot и сертификаты Let’s Encrypt

Дальше проделаем то же самое, только для Dovecot. Настроим его на работу с сертификатом let’s encrypt. Для этого добавляем в его конфиг /etc/dovecot/dovecot. conf параметры.

И так же перечитываем конфигурацию.

Теперь можно проверить корректность настройки.

Проверка сертификата ssl/tls в почтовом сервере

Способов проверить сертификат в почтовом сервере множество. Например, у меня есть статья, где я настраиваю мониторинг сертификатов с помощью Zabbix. Там же есть примеры и для почтового сервера. Вот так с помощью openssl в консоли сервера можно посмотреть текущие сертификаты.

Это самый простой и быстрый способ. Можете проверить прямо из консоли почтового сервера. Так же можно воспользоваться каким-то готовым сервисом, например https://ssl-tools. net/mailservers.

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

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

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

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

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

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

Онлайн курс по Kubernetes

Онлайн-курс по Kubernetes – для разработчиков, администраторов, технических лидеров, которые хотят изучить современную платформу для микросервисов Kubernetes. Самый полный русскоязычный курс по очень востребованным и хорошо оплачиваемым навыкам. Курс не для новичков – нужно пройти вступительный тест.

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

Автор Zerox

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

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

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

Спасибо за пояснение! Я так и сделал)

Могу ли я использовать SSL сертификат своего веб сайта на почтовом сервере, то есть на postfix и dovecot?

Можете без проблем. Конвертить не обязательно.

Так трудно сказать, в чем проблема. Нужно подробно логи смотреть. Вы пишите про настройки dovecot, но говорите, что не приходят входящие письма. За прием почты отвечает postfix, а не 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>

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

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

Спасибо, я действительно перепутал строки

Вообще всё сломалось. 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 и roundcube в какие-то виртуальные хосты и ходить туда по https. Я так делаю.

по ip заглушка работает, решил перевести postfixadmin на порт 8080

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

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

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

IMPORTANT NOTES:
— The following errors were reported by the server:

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:

Проблема Lets Encrypt

Несколько недель назад, 6 ноября 2020 стало известно что SSL-сертификаты, выданные Let’s Encrypt перестанут работать для пользователей Android 7.1 (Nougat) и более ранних версий (Marshmallow, Lollipop, KitKat, JellyBean и IceCream Sandwich). Это значит что часть аудитории сайта будут видеть такое окно при входе:

Давайте разберемся как оценить масштаб проблемы для своего сайта и какие пути её решения есть.

В чем суть проблемы

При создании центра сертификации Let’s Encrypt было принято решение запросить у другого центра сертификации (IdenTrust) перекрестную подпись. Это было нужно чтобы сертификаты сразу начинали пользоваться доверием со стороны большинства операционных систем и браузеров, иначе получение доверия с их стороны заняло бы годы.

Благодаря использованию корневого сертификата «DST Root X3» от IdenTrust сертификаты компании сразу получили поддержку у Windows, Firefox, macOS, Android, iOS и множества дистрибутивов Linux. Параллельно с этим Let’s Encrypt решили зарегистрировать свой сертификат «ISRG Root X1» чтобы основные платформы начали ему доверять.

Срок действия сертификата «DST Root X3» истекает 1 сентября 2021 года, но Let’s Encrypt решили отказаться от дальнейшего использования перекрестной подписи в пользу своего корневого сертификата.

У нового корневого сертификата есть проблемы совместимости. Программное обеспечение, которое не обновлялось с 2016 года (когда новый сертификат получил широкую поддержку) по-прежнему не доверяет «ISRG Root X1». Например, сюда входят устройства на базе Android до 7.1.1.

Как проверить сертификат

Проверить сертификат можно с помощью онлайн-сервиса https://www. sslshopper. com/ssl-checker. html. Для этого указываем в поле ввода на странице адрес вашего сайта:

Если в результате у одной из зеленых галочек видим строку «The certificate was issued by Let’s Encrypt.», то вам не повезло. Ваш сайт использует сертификат Let’s Encrypt.

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

Если в открывшемся окне в поле «Кем выдан» указано «Let’s Encrypt Authority X3», то проблема коснется и вашего сайта.

Оценка масштаба проблемы

Проблемы в большей степени возникнут с пользователями которые будут переходить по небрендовым поисковым запросам (и контекстной рекламе). То есть с той аудиторией, которая не искала именно ваш сайт.

Не стоит ориентироваться на какие-то общие показатели доли устройств Android 7.1 (и более ранних версий), гораздо правильнее вычислить эту долю для текущей аудитории вашего сайта.

Оценка в Яндекс. Метрике

Для расчёта через Метрику заходим в её отчёт «Источники, сводка» (1), выбираем период в несколько месяцев (2) и добавляем фильтрацию по визиту (3). В фильтрации переход в раздел «Технологии» (4), а затем в подраздел «Операционные системы» (5). Раскрываем список версий операционной системы Google Android (6), выбираем все те что вышли ранее 7.1 (включительно), нажимаем применить (7).

Теперь нажимаем «Сравнить сегменты» и выбираем пункт «С сегментом, заданным вручную». Смотрим какие данные получились у источника «Переходы из поисковых систем». В моём примере вышло 2 218 и 19 554.

Делим первое на второе и получаем 11,34%. Примерно столько процентов аудитории сайта можно потерять, если продолжить использовать сертификат Let’s Encrypt.

Оценка в Google Analytics

Создаем сегмент (4), в источниках трафика (5) выбираем фильтрацию по сеансам (6) и для вводим «organic» в поле «Канал» (7), при типе соответствия «содержит».

Называем сегмент «Поисковый трафик». Теперь нам нужно создать сегмент поискового трафика пользователей старых версий Android, для этого создаем второй сегмент повторяя все предыдущие шаги, назовем второй сегмент «Поисковый трафик не доверяющий Let’s Encrypt».

Следующим этапом переходим в настройки сегмента «Условия» (1) и добавляем два фильтра по сеансам:

Сохраняем сегмент. Применяем для представления сегмент с поисковым трафиком (1) и сегмент с поисковым трафиком не доверяющим Let’s Encrypt (2). В таблице с данными берем общее количество сеансов для каждого сегмента (3) и делим меньшее число на большее. В моём случае получилось 47,75%.

Что мы получили

Теперь мы поняли какая доля устройств может получить предупреждение при входе на сайт. Если ваш трафик в основном брендовый, то вряд ли что-то сильно изменится. Но, если вы занимаетесь SEO и значимая часть трафика идёт по небрендовым запросам, задумайтесь готовы ли вы потерять этих пользователей или нужно решать проблему.

Как решить проблему

Итак, вы решили что не готовы терять эту часть пользователей и портить свои результаты в SEO. Теперь вам нужно сменить свой SSL-сертификат на новый. Можно попробовать поискать бесплатные SSL-сертификаты (обращайте внимание на срок действия сертификата и количество его бесплатных продлений), либо взять платный (но без лишнего геморроя). Популярные центры сертификации с платными SSL-сертификатами: Comodo, Thawte и RapidSSL. Не забывайте что сертификаты чаще всего даются на год, а значит слишком рано покупать их невыгодно (но стоит поставить себе до сентября 2021 событие в календаре, увидев которое вы смените свой сертификат).

Кстати, у меня все свои сайты работают на Let’s Encrypt. И менять я сертификаты не собираюсь. Дело в том, что по отдельности каждый сайт не приносит большого дохода, а значит покупка для каждого из них своего SSL сделает их менее прибыльными.

А вы используете Let’s Encrypt? Если да, то планируете менять сертификат?