Demo
Demo
База знаний PMTA›Блок <domain>›Директива§ 3.3.10.108.14

smtp-tls-ca-file

<domain>

Список доверенных корневых сертификатов для проверки приёмника
в конфигурации это строкаsmtp-tls-ca-fileвнутри блока <domain>
Кому верить, проверяя сертификат приёмника

Обычный STARTTLS не проверяет подлинность — приёмник может предъявить любой сертификат, хоть самоподписанный. Проверку включает эта строка: она называет файл с корневыми сертификатами, по которым сверяется предъявленная цепочка.

Что происходит при неудачной проверке, зависит от соседа. При оппортунистическом шифровании узел откатится к открытому тексту; при включённом require-starttls — вернёт временный отказ 4xx, и письмо останется в очереди.

По умолчанию используется список из поставки — набор Mozilla CA. Эта строка его заменяет, а не дополняет.

Механизмы MTA-STS и DANE проверяют сертификат сами, но по-разному: MTA-STS — по цепочке и имени, то есть тем же списком; DANE — по отпечатку из DNS, и список ему не нужен вовсе.

Главная ловушка — молчаливый откат. Без require-starttls неудачная проверка не отказ, а отправка открытым текстом: то есть строка, добавленная ради безопасности, в худшем случае оставляет письмо вовсе без шифрования. Проверка сертификата имеет смысл только вместе с обязательностью.
Что делает Хаб. Не пишет — оставляет список из поставки. Он обновляется вместе с PowerMTA и покрывает всех крупных приёмников; свой список нужен там, где приёмник предъявляет сертификат внутреннего удостоверяющего центра. Проверку у крупных приёмников обеспечивает use-mta-sts, который делает её сам.
Рекомендуемые значения

Значение — путь к файлу. Решается здесь одно: чей список брать:

Что Когда
не задавать (умолчание) всегда: список Mozilla из поставки покрывает публичные центры
свой файл приёмник предъявляет сертификат внутреннего центра

И обязательно рядом — require-starttls. Без него неудачная проверка молча превращается в незашифрованную доставку.

Поведение при неудачной проверке в двух режимах и список из поставки — из руководства (§ 3.3.10.108.14 и § 10.6). Совет про пару с обязательностью — наш.
Пример в конфигурации
# проверка сертификата имеет смысл только вместе с обязательностью
<domain internal.example.com>
    use-starttls yes
    require-starttls yes
    smtp-tls-ca-file /etc/pmta/certchain.pem</domain>
Убрать вторую строку — и неудачная проверка приведёт не к отказу, а к отправке открытым текстом. Собственный список нужен именно здесь: у внутреннего приёмника сертификат от своего центра.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается2 ошибки▶

Включают проверку без обязательного шифрования

§ 3.3.10.108.14

Чем чреватоПри оппортунистическом шифровании неудачная проверка приводит к откату на открытый текст. Настройка, добавленная ради безопасности, ухудшает результат.
Как заметитьПосле включения проверки в учёте у приёмника появляются письма без версии протокола.
Как правильноСтавить рядом require-starttls. Тогда неудачная проверка — это временный отказ, а не незашифрованная доставка.

Заменяют список из поставки своим ради одного приёмника

наш опыт

Чем чреватоСтрока заменяет набор целиком. Свой файл с одним внутренним центром, поставленный в <domain *>, оставляет узел без публичных корневых сертификатов.
Как заметитьПроверка перестаёт проходить у всех приёмников сразу.
Как правильноСтавить строку в блок конкретного приёмника — или включать в файл и публичные корни тоже.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
smtp-tls-ca-file <path>
Значения
путь к файлу с одним или несколькими корневыми сертификатами
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <domain> и сливается по обычному правилу блоков получателей: побеждает самое точное совпадение по имени приёмника. Те же три уровня действуют по адресу отправки — узел, <virtual-mta-pool>, <virtual-mta>. Список заменяет набор из поставки, а не дополняет его.
⇄

Связанные директивы

2 связи

Без чего не работает

use-starttls<domain>Проверять цепочку сертификата можно только у шифрованного соединения. § 3.3.10.108.14

На что влияет

require-starttls<domain>Обязательность шифрования решает, чем обернётся неудачная проверка: временным отказом или отправкой открытым текстом. § 3.3.10.108.14

Сюда ссылаются

use-dane<domain>DANE сверяет отпечаток из DNS, а не цепочку удостоверяющих центров — список доверенных ему не нужен. § 3.3.10.108.14

Как проверить на узле
Что предъявляет приёмник и сходится ли цепочка, проще проверить снаружи:
openssl s_client -starttls smtp -connect mx.example.com:25 -CAfile /etc/pmta/certchain.pem
Строка Verify return code: 0 (ok) означает, что цепочка сходится. Ненулевой код — проверка не пройдёт и на узле: при обязательном шифровании это временный отказ, без него — доставка открытым текстом.
◇

Что ещё почитать

3 статьи

◇Подача по HTTPS на своём приёмнике, по образцу SparkPostОтдельный вход: свой приёмник с сертификатом, свои ключи и зарезервированное имя источника, через которое к такой почте применяются обычные настройки подачи.◇Приёмник объявляет требование шифрования на своём сайтеУзел забирает политику получателя по HTTPS и, если та в режиме принуждения, доставляет только при совпадении MX, шифровании и проверенном сертификате.◇Приёмник объявляет требование шифрования в своей зоне DNSУзел смотрит записи DANE получателя и, если тот требует STARTTLS, отправляет только по зашифрованному каналу с проверенным по отпечатку сертификатом.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Шифрование соединений
Соседние настройки блока <domain>:use-starttlsuse-danesmtp-tls-min-versionuse-mta-stsrequire-starttlsВсе 135 директив блока →