Установка и настройка почтового сервер с postfixadmin

Конфигурация Postfix для ретрансляции писем

Скрыть рекламу в статье

Разделы на этой странице:

Конфигурация Postfix для ретрансляции писем

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

Настройка Postfix для работы в режиме ретранслятора

По умолчанию Postfix передает письма, которые удовлетворяют следующим критериям.

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

• Отправитель принадлежит домену, указанному в переменной . По умолчанию значение данной переменной равно значению переменной .

• Отправитель пытается передать письмо на компьютер, принадлежащий одному из доменов, указанных в переменной , или их поддоменов.

Конфигурация по умолчанию указывает на то, что Postfix должен обрабатывать почту из того домена, которому принадлежит сам сервер, и от компьютеров, непосредственно связанных с сервером, посредством сетевых интерфейсов. В большинстве случаев такая конфигурация вполне приемлема, но иногда приходится изменять ее. Чтобы сделать это, вам надо изменить значение или (либо модифицировать обе переменные). Предположим, например, что Postfix должен обслуживать рабочую станцию . Для этого вам надо переопределить значения переменных следующим образом:

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

Данные опции сообщают о том, что письма должны приниматься из сетей 192.168.99.0/24, 172.24.0.0/16 и (127.0.0.0/8), а также с компьютеров, принадлежащих доменам и .

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

Настройка Postfix для передачи почты через ретранслятор

В простейшем случае, чтобы сконфигурировать Postfix для передачи почты посредством другого сервера, достаточно установить значение опции . Эта опция, находящаяся в файле , указывает на компьютер, выполняющий функции ретранслятора. Если в конфигурационном файле сервера имен, управляющего доменом, присутствует запись , указывающая на сервер-ретранслятор, то в качестве значения опции можно задать имя этого домена. Например, если в роли ретранслятора выступает сервер, расположенный на компьютере , в файл необходимо включить следующую запись:

Если ваш сервер находится в том же домене, что и сервер-ретранслятор, и если на ретранслятор, указывает запись , то вместо имени вы можете использовать переменную . Такой подход предпочтительнее тем, что переносе почтового сервера, обслуживающего домен, на другой компьютер перенастраивать Postfix не приходится.

В обычных условиях при передаче почты Postfix обращается к серверу DNS. Если же сервер имен в вашей сети отсутствует (например, если преобразование имен осуществляется с помощью файлов ), вам необходимо включить в конфигурационный файл следующую запись:

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

Оглавление книги

SPF-запись

Это TXT-запись в DNS зоне домена, в которой указываются адреса серверов, с которых происходит отпарвка почты у данного домена. Когда почтовый сервер приемника получает письмо с адресом отправителя , он идет в DNS и проверяет SPF запись у домена mydomain.ru. Пример такой записи:

В данном примере:

• — версия SPF; всегда spf1
• — разрешить прием писем с адреса указанного в A записи mydomain.ru
• — разрешить прием писем с адреса указанного в MX записи mydomain.ru
• — разрешить прием писем из сети 11.22.33.0/24 и разрешить прием писем с адреса 2.2.2.2
• — то же самое что ip4, но для IPv6
• — отбросить письмо, пришедшее не от указанных выше адресов. Можно вместо -all указать ~all, что значит — письмо не отбрасывать, но проверить остальными способами.

Все поля кроме версии опциональные, не обязательно указывать все. Здесь есть более подробное описание синтаксиса SPF-записи: http://www.openspf.org/SPF_Record_Syntax

Установка системы и начальная конфигурация

В гостевой ОС вполне можно отказаться от раздела подкачки, особенно если назначить ВМ достаточное количество оперативки, а datastore гипервизора находится на SSD. Я взял Debian 10, процесс установки полностью стандартный за исключением разметки диска. Имя сервера задаем mail, домен example.com. Система ставится в минимальной конфигурации. В разметке дисков я сделал первый раздел под /boot и второй раздел с шифрованием:

После установки системы я делаю несколько базовых вещей. Удаляю созданного при установке пользователя командой .

Задаю статический адрес, если это не было сделано во время установки. Для этого правим файл

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

Для применения изменений выполняем команду (не забываем здесь заменить название сетевого интерфейса на свое):

Чтобы не углубляться в настройку домашних роутеров, VPN туннель мы будем делать сразу с почтового сервера до VPS и завернем туда весь трафик. Поэтому имеет смысл поменять DNS сервера на публичные. Для этого правим файл , конечный вид которого примет вид:

IPv6 я тоже отключаю, для этого в конец файла добавляю строку:

Чтобы параметр применился выполняем команду:

Проверить, отключился ли IPv6 довольно легко. Для этого нужно просмотреть вывод нижеследующей команды на наличие ipv6 адресов:

Устанавливаем ssh и wget:

Включаю логин по паролю для root по SSH, для этого в файле добавляем строку . Применяем изменения:

Коннектимся к серверу по ssh и едем дальше.

Защита postfix с помощью fail2ban

Изначально fail2ban идет с комплектом готовых настроек и фильтров для защиты большинства популярных сервисов. К ним относится и postfix. Но когда я посмотрел в готовый набор с regexp для postfix, я слегка растерялся Он просто огромен. И самое главное, что в таком виде он не заработал на моем лог файле.

Мне стало лень ковыряться в этих правилах. Для защиты postfix от перебора паролей почтовых ящиков, достаточно банить ip адреса из следующих строк лога.

Jun 17 03:14:07 mail postfix/smtpd: warning: unknown: SASL LOGIN authentication failed: UGFzc3dvcmQ6

Для этого достаточно относительно простого regexp.

^%(__prefix_line)swarning: +\: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: *={0,2})?\s*$

Его придумал не я. Честно подсмотрел на просторах интернета. Примеров масса и у нас, и в англоязычном гугле. Далее создаем конфигурационный файл с фильтром из этого regexp — /etc/fail2ban/filter.d/postfix-sasl.conf.

before = common.conf

_daemon = postfix/smtpd
failregex = ^%(__prefix_line)swarning: +\: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: *={0,2})?\s*$
ignoreregex =

Можно сразу же проверить работу этого фильтра с помощью fail2ban-regex. Эта утилита никого не банит, а просто выводит информацию о работе фильтра.

# fail2ban-regex /var/log/maillog /etc/fail2ban/filter.d/postfix-sasl.conf

Команда успешно отработала и вывела результат.

24327 раз данный фильтр распознал строки, попадающие под работу фильтра. Изначально я напрягся, когда прикинул, что именно такое количество ip адресов поедет в бан с помощью iptables. Это еще не критично большое количество, но все равно достаточно много. По одному добавлять такое количество адресов не стоит. Нужно использовать списки, например, .

На деле зря испугался. Никаких проблем не будет и дальше я покажу почему. Правило обработки лога мы проверили и убедились, что оно работает. Дальше добавляем в jail.conf новую секцию.

enabled	= true
filter	= postfix-sasl
port	= smtp,465,submission,imap,imaps,pop3,pop3s
action	= iptables
logpath	= /var/log/maillog
bantime	= 60m
maxretry = 3
findtime = 60m

Пояснять тут особо нечего и так все понятно. Настройка блокировки будет проверять лог файл и записи в нем за последние 60 минут. Если будут 3 совпадения с regexp из фильтра postfix-sasl, ip адрес будет забанен на 60 минут. Таким образом, список забаненных ip адресов будет не очень большой, так как большая часть адресов будет повторяться.

Запускаем fail2ban и добавляем в автозагрузку.

# systemctl enable --now fail2ban

Проверяем лог файл /var/log/fail2ban.

Смотрим правила iptables.

# iptables -L -v -n

У вас должна появиться отдельная цепочка правил f2b-Postfix-sals с заблокированными ip адресами, которые добавил fail2ban. С защитой postfix с помощью fail2ban все. Переходим к Dovecot.

Описание параметров и дополнительные настройки

— интернет домен для почтовой службы

— по умолчанию = полное доменное имя машины = FQDN. Или берётся не-FQDN доменное имя и прибавляется «.$mydomain».Узнать текущий FQDN машины можно командой Но если команды: и изначально выводят правильные и нужные нам значения – то указывать не обязательно.

— параметр myorigin указывает имя домена, которое используется в почте, отправляемой с этой машины (userLinux@$myorigin). По умолчанию, используется имя локальной машины — $myhostname

— для каких доменов почта будет доставляться локально вместо пересылки на другой хост

— т.к. нет потребности подключаться из вне, то запускаем postfix только на localhost

— сети, которым разрешено выполнять пересылку через данный сервер

Генерирование сертификатов, завершение настройки

Генерируем SSL сертификат командой. Не забываем заменить example.com на свой домен:

Генерируем DKIM. В команде ниже вместе example.com ‒ ваш домен, а вместо 20210121 можно взять текущую дату (ггггммдд):

Результатом выполнения команды будет такой текст:

В файл нужно добавить дату, чтобы получилось примерно так:

Идем в редактор DNS зоны у регистратора, добавляем запись «TXT» с именем и значением Дата в имени у вас будет своя, параметры перечисляются без двойных кавычек. Примерно так:

Тут есть нюанс. По умолчанию длина ТХТ записи может быть до 255 символов, а т.к. мы сгенерировали 2048 битный DKIM ключ, то его длина выходит за это ограничение и если вы внимательно посмотрите на результат генерации ключа, параметр разбит на два, каждый из которых в своих двойных кавычках. Если регистратор поддерживает ТХТ записи большей длины, то две части можно просто схлопнуть, убрав кавычки. У GoDaddy, например, максимальная длина TXT записи 1024 символа. А если регистратор не поддерживает больше 255 символов, то ключ записывается в две ТХТ записи. Или можно сгенерировать более короткий ключ на 1024 бита.

Последнее что нужно сделать ‒ поправить файл . Необходимо раскомментировать строку:

И 4 вложенных параметра, начинающихся на «-o». Двойной пробел перед ними нужно сохранить. Последний параметр, возможно нужно будет просто дописать. На всякий случай в архиве со скриптом приложен готовый к употреблению файл master.cf. Должно получиться так:

Перезагружаем сервер.

Теперь заведем первый почтовый ящик. Для этого нужно воспользоваться скриптом mailuser-addnew.sh. Нужно будет ввести короткое имя (слово до @example.com), доменное имя (сам example.com) и пароль два раза. После этого можно попробовать настроить любой почтовый клиент используя созданную учетную запись.

В качестве примера пусть будет [email protected]. Для настройки почтового клиента набор параметров будет таким: почтовый адрес [email protected], имя пользователя для IMAP и для SMTP так же [email protected], сервер входящей почты IMAP mail.example.com, исходящей почты тоже mail.example.com, способ подключения везде STARTTLS.

Для проверки корректности настройки DKIM и SPF, можно воспользоваться ресурсом https://dkimvalidator.com, отправив туда тестовое письмо и посмотрев отчет. Все проверки должны быть в статусе pass (пройдено).

Установите бесплатный SSL-сертификат Let’s Encrypt

Мы собираемся использовать сертификат SSL для доступа к нашей установке Postfix Admin и включить шифрование Dovecot и Postfix SSL / TLS.

У нас есть руководство по установке SSL-сертификата Let’s Encrypt . Наиболее важным моментом здесь является создание сертификата SSL для вашего имени хоста сервера (FQDN) в нашем случае .

После того, как вы сгенерировали сертификат SSL, следуя приведенному выше учебнику, отредактируйте свой блок сервера Nginx следующим образом:

/etc/nginx/sites-enabled/mail.baks.dev.conf

Перезагрузите службу Nginx, чтобы изменения вступили в силу:

На этом этапе вы сможете войти в систему установки Postfix Admin по адресу , используя пользователя superadmin, созданного ранее в этом руководстве.

Выбор сервера отправки в зависимости от адреса получателя

Итак, в sender_bcc_map всю локальную почту я оставляю локально, просто указывая адрес отправителя (каждый сайт шлет почту от своего ящика) и локального пользователя, к которому она будет складываться. Если у вас много сайтов, то для каждого сайта будет свой локальный пользователь. Чаще всего это так, потому что разные сайты лучше всего запускать под разными пользователями, от которых работает веб сервер. Файл с записями для sender_bcc_map выглядит так:

[email protected] user1
[email protected] user2

Если у вас использует разные ящики для отправки, то можете настроить правило для всего домена сразу:

*@site1.ru user1
*@site2.ru user2

Дальше вам нужно выяснить, как выглядит полностью адрес домена для локальной доставки почты. Это имя задается в параметре mydomain в конфиге postfix main.cf. Допустим, там указано имя сервера — websrv.site.ru. Это не принципиально, в нашем случае там можно написать все, что угодно, но лучше использовать полное доменное имя (fqdn) самого веб сервера, которое указано в DNS записи типа А.

Теперь создаем файл transport_map, в котором пишем следующее:

websrv.site.ru local

Мы явно указываем, что всю почту для домена websrv.site.ru отправлять локально. Не забываем построить индексированный файл:

# postmap /etc/postfix/transport_map

Отправляемся в конфиг main.cf и добавляем туда параметр:

transport_maps = hash:/etc/postfix/transport_map

Перезапускаем postfix и проверяем работу. При отправке почтового сообщения от имени пользователя [email protected] там должно быть примерно следующее:

websrv postfix/smtpd: CC8F0602E205: client=localhost
websrv postfix/cleanup: CC8F0602E205: message-id=<[email protected]>
websrv postfix/qmgr: CC8F0602E205: from=<[email protected]>, size=874, nrcpt=2 (queue active)
websrv postfix/smtpd: disconnect from localhost ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
websrv postfix/local: CC8F0602E205: to=<[email protected]>, relay=local, delay=0.07, delays=0.06/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to mailbox)
websrv postfix/smtp: CC8F0602E205: to=<[email protected]>, relay=smtp.yandex.ru:465, delay=0.93, delays=0.06/0.01/0.23/0.63, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued on myt6-9bdf92ffd111.qloud-c.yandex.net as 1608951012-xOUj8gBhbE-oCJSqvIX)
websrv postfix/qmgr: CC8F0602E205: removed

[email protected]	адрес, с которого сайт ведет отправку почты
[email protected]	итоговый локальный адрес, куда идет пересылка почты
[email protected]	внешний почтовый адрес, куда идет отправление через внешний smtp
smtp.yandex.ru	адрес внешнего smtp сервера

Получили в итоге то, что хотели. Внешняя почта отправляется через внешний smtp адрес, указанный в relayhost, а копии сообщений падают в локальный ящик, который находится в файле /var/mail/user1. Конкретно мне это нужно было для отладки, чтобы понять, что именно отправляет сайт.

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

sender_bcc_maps:

*@site1.ru [email protected] 
*@site2.ru [email protected]

transport_map:

backupmail.ru relay::25

В данном случае backupmail.ru это отдельный почтовый домен и почтовый сервер для него для сбора всей вашей почты. Это не обязательно может быть собственноручно настроенный почтовый сервер. Можете использовать ящик в какой-то готовой службе почты. Но имейте ввиду, если это будет какой-то бесплатный сервис, то он вас быстро заблокирует, если будете слать слишком много почты на этот ящик.

Полезные команды Postfix

До того, как мы начнём, давайте взглянем на некоторые команды, связанные с Postfix.

1. postfix reload или service postfix restart?

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

• postfix reload: Эта команда проверит конфигурационные файлы и, соответственно, обновит Postfix. Поскольку данная команда не приводит к отключению Postfix, она крайне рекомендована в условиях реальной работы.
• service postfix restart: Эта команда, для начала, остановит Postfix, а затем запустит его снова. Эта команда запустит свежий экземпляр Postfix.

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

2. postconf

postconf — это очень полезная команда Postfix. Далее несколько примеров использования postconf.

Для показа значений всех параметров Postfix:

# postconf

Чтобы увидеть значения специфичных параметров, можно использовать grep для фильтра вывода:

# postconf | grep myorigin
append_at_myorigin = yes
myorigin = example.tst

postconf может быть использована для установке значений конкретных параметров Postfix во время выполнения.

# postconf -e 'myorigin = example.tst'

Обратите внимание, что любые параметры Postfix, изменённые командой postconf, сохраняться до перезагрузки. То же самое может быть достигнуто модификацией конфигурационного файла /etc/postfix/main.cf.

По домену через другой SMTP

Открываем на редактирование конфигурационный файл postfix:

vi /etc/postfix/main.cf

Редактируем или дописываем:

transport_maps = hash:/etc/postfix/transport_map

Теперь нужно открыть на редактирование файл транспорта:

vi /etc/postfix/transport_map

И добавить:

dmosk.ru   smtp::25
[email protected]   smtp::25

* где dmosk.ru — домен, для отправки на который используется другой сервер пересылки, а 10.10.10.10 — IP-адрес другого сервера SMTP. [email protected] и mail.mailsystem.ru — конкретный адрес электронной почты и сервер для его пересылки.

После создаем карту:

postmap /etc/postfix/transport_map

И перезапускаем postfix:

systemctl restart postfix

Настройка почтового сервера

Чтобы не заниматься курением конфигов, а результат был предсказуем ‒ я сделал скрипт, который автоматизирует 90% всего процесса из вышеупомянутого гайда с некоторыми отличиями:

• Я не хочу ставить на почтовый сервер ресурсоемкий Nextcloud, вместо него я буду использовать Rainloop

• Подрежем еще несколько мета-тегов: X-Mailer, X-Originating-IP, X-PHP-Originating-Script, Mime-Version. При этом в оригинальном гайде фильтрация конфигурируется в master.cf, а у меня в main.cf

Скрипт устанавливает необходимые пакеты, конфигурирует apache, БД, конфигурирует почтовые службы и на выходе получается практически готовый к употреблению почтовый сервер. При этом я пока не стал включать в скрипт генерирование SSL и DKIM, сделаем это руками чуть ниже.

Скрипт пока не тестировался на корректность работы при многократном запуске. Если почтовый сервер у вас развернут как виртуальная машина, то перед выполнением лучше сделать снапшот ВМ.

Скачиваем и распаковываем скрипт:

Всего в каталоге 3 файла:

• — основной скрипт конфигурирования сервера

• — скрипт создания почтового юзера

• — скрипт смены пароля для существующего почтового юзера

Запускаем . Скрипт попросит ввести следующие данные: имя хоста почтового сервера (в этом гайде это просто mail), имя домена, который был ранее зарегистрирован (например, example.com), IP адрес почтового сервера в локальной сети. Имя хоста + домен как раз образуют полное имя mail.example.com. По завершению работы скрипта почтовые сервисы остаются в выключенном состоянии, т.к. перед запуском надо сгенерировать SSL сертификаты и DKIM. Так же по завершению будет отображен админский пароль от БД. Этот пароль нужно вставить в скрипты и вместо слова PASSWORD, см в файлах вторую строку:

Настройки DNS

Для работы вашей почтовой системы необходимо настроить следующие записи DNS:

Запись, указывающая полное доменное имя (имя хоста) вашей системы на IPv4-адрес вашего почтового сервера.

Полное доменное имя состоит из двух частей: имени хоста и имени домена.

Запись MX, чтобы указать, какой почтовый сервер отвечает за прием сообщений электронной почты от имени домена получателя. В нашем случае мы хотим, чтобы все электронные письма, отправленные на @linuxize.com электронной почты @linuxize.com принимались почтовым сервером mail.linuxize.com .

Запись SPF, которая используется для проверки того, какие почтовые серверы одобрены для отправки электронной почты от имени данного домена. В приведенном ниже примере мы утверждаем почтовые серверы домена (mx), и если проверка SPF не удалась, результатом будет мягкий сбой (~ все):

Конечно, вам необходимо заменить доменное имя и IP-адрес на ваше реальное доменное имя и IP-адрес вашего почтового сервера.

Обратный DNS (PTR)

Обратный DNS (PTR) — это IP-адрес для сопоставления доменного имени, полная противоположность DNS, который сопоставляет доменные имена с IP-адресами.

Большинство почтовых серверов будут выполнять обратный поиск DNS на IP-адресе, который пытается подключиться к ним, и могут не принимать электронные письма с сервера, если запись PTR не установлена.

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

Вы можете использовать команду dig, чтобы узнать обратный DNS для заданного IP-адреса.

Включение Plaintext аутентификации в Dovecot

По причинам безопасности, сервер Dovecot IMAP/POP, по умолчанию, не позволяет аутентификацию простым текстом — plaintext (например, использовать незашифрованные пароли). И это правильно и очень хорошо! Но по некоторым причинам, иногда необходимо задействовать аутентификацию plaintext в Dovecot, для этого используется следующая настройка.

# vim /etc/dovecot/conf.d/10-auth.conf

disable_plaintext_auth = no

# service dovecot restart

Это только некоторые вещи, которые делают администраторы почтовых серверов. Возможно ещё более глубокая настройка Postfix и Dovecot чтобы соответствовать нуждам всех заинтересованных сторон.

Автоматическая замена темы писем в postfix

Переходим к замене темы письма. Для этого добавляем в конфиг postfix /etc/postfix/main.cf следующий параметр.

header_checks = pcre:/etc/postfix/rewrite_subject

Создаем файл rewrite_subject следующего содержания:

/^Subject: (.*)$/ REPLACE Subject: (prox-centos7) $1

Это регулярное выражение, которое меняет заголовок письма, начинающийся с Subject. Оно добавляет в начало темы имя сервера в скобках — (prox-centos7). Вы можете добавлять что-то свое. Для тех, кто вообще не разбирается в регулярках, поясню, что в данном случае $1 это исходное содержание темы.

Перезапускаем postfix и проверяем, отправив через консоль письмо.

# df -h | mail -s "Disk usage" [email protected]

Проверяем ящик и видим там письмо.

Теперь вы можете настраивать отправку системных писем с разных серверов, используя один и тот же ящик, просто автоматически меняя тему всех почтовых сообщений сервера.

Устанавливаем Rainloop webmail

Все необходимые php модули для Rainloop уже были установлены скриптом. Скачиваем актуальную версию проекта, распаковываем, задаем права, включаем vhost на веб-сервере:

Логинимся в админку rainloop по адресу с логином и паролем . Пароль естественно надо будет сменить, это делается в разделе Security.

Далее добавляем наш почтовый сервер. Идем в раздел Domains, отключаем все прочие почтовые сервера и жмем по кнопке Add Domain:

Вводим параметры нашего домена и жмем Add:

Дополнительно в закладке Login можно так же указать домен:

Теперь можно пробовать заходить в webmail используя короткое имя пользователя (без @example.com):

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

В качестве небольшого тюнинга безопасности Apache добавим пару строк в файл . Это скроет данные о версии веб-сервера:

Для применения изменений перезагрузим Apache командой .

Получаем сертификат от 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

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

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

Заключение

Для того, чтобы любые работы на prod сервере прошли успешно, я всегда соблюдаю несколько правил:

1. Никогда не тороплюсь. Если реально нет необходимости спешить, я всегда довожу до руководства, что спешка не нужна. Она вредит и мешает все сделать хорошо. Пусть лучше я спокойно неделю или две подготовлюсь, все обдумаю, проверю и перенесу без проблем, нежели я буду спешить для соблюдения бессмысленных сроков.
2. Тщательно все проверяю и перепроверяю. Делаю все максимально незаметно. Если простой ожидается маленький, не шлю никому никаких уведомлений. Если вы предупредите, что будут работы с почтовым сервером, на следующие дни обязательно кто-то нажалуется, что после переноса все сломалось. Это мешает снимать реальные обратные связи. Когда никто не знает о переносе, отзывы будут только на реальные проблемы, а не надуманные.
3. У меня всегда есть запасной план на случай, если что-то пойдет не так. Всегда под рукой актуальные бэкапы и подменные системы. Я точно знаю, что буду делать, если новый сервер не будет введен в эксплуатацию.

Этого достаточно, чтобы успешно проводить любые работы на серверах. Главное, все запланировать заранее, чтобы не было спешки. А как вы планируете масштабные обновления или переносы prod серверов?

Онлайн курс Infrastructure as a code

Если у вас есть желание научиться автоматизировать свою работу, избавить себя и команду от рутины, рекомендую пройти онлайн курс Infrastructure as a code. в OTUS. Обучение длится 4 месяца.

Что даст вам этот курс:

• Познакомитесь с Terraform.
• Изучите систему управления конфигурацией Ansible.
• Познакомитесь с другими системами управления конфигурацией — Chef, Puppet, SaltStack.
• Узнаете, чем отличается изменяемая инфраструктура от неизменяемой, а также научитесь выбирать и управлять ей.
• В заключительном модуле изучите инструменты CI/CD: это GitLab и Jenkins

Смотрите подробнее программу по .