tls-ca-file

<smtp-listener>

Доверенные центры для клиентов этого слушателя
в конфигурации это строкаtls-ca-fileвнутри блока <smtp-listener>
То же имя ещё 2:<smtp-listener><smtp-user><transmissions-api-listener>— часть из них другие настройки, часть та же самая
Кому верить на этом входе

Строка называет файл с корневыми сертификатами, по которым проверяются сертификаты клиентов, пришедших на этот вход.

Наследуется от smtp-server-tls-ca-file — не задали здесь, действует список узла.

Сама по себе ничего не требует. Она называет, кому верить; требование предъявить сертификат задаётся способом проверки логина — authentication-method в <smtp-user>.

Главная ловушка — считать, что строка включает взаимную проверку. Не включает. Без способа проверки логина, требующего сертификат, список не участвует ни в одном соединении.
Что делает Хаб. Не пишет: подача идёт по логину и паролю либо с разрешённых адресов, клиентских сертификатов нет. Строка понадобится вместе со способом проверки ca-file — и настраивать их надо в паре.
Рекомендуемые значения

Файл слушателю задают отдельно — наследования от узла руководство не обещает:

Что Когда
не задавать проверки клиентов на этом входе нет
файл клиентов этого входа проверяют по сертификату — даже если такой же файл задан на узле
Наследование от списка узла — из руководства (§ 3.3.17.15). Замечание о том, что строка ничего не требует, — наше.
Пример в конфигурации
# настройка одного входа, остальные берут значение узла
<smtp-listener 10.0.0.1:2525>
    tls-ca-file /etc/pmta/partner-ca.pem</smtp-listener>
Отдельный вход для партнёрской подачи со своим кругом доверия. Проверка включается не здесь, а способом проверки логина.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Настраивают слушатель вместо узла при единственном входе

§ 3.3.17.15

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

Меняют у одного слушателя, ожидая изменения у всех

наш опыт

Чем чреватоСтрока действует только на свой адрес и порт. Соседний вход продолжает работать по значению узла, и разница обнаруживается по поведению разных клиентов.
Как заметитьОдни подающие видят новое поведение, другие прежнее.
Как правильноМенять на уровне узла — тогда изменение достанется всем входам, где не задано своё.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
tls-ca-file <path>
Значения
путь к файлу с корневыми сертификатами в формате PEM
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<smtp-listener>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <smtp-listener> и действует на соединения его адреса и порта. Наследования от smtp-server-tls-ca-file руководство не обещает: «наследуется от узла» сказано только про tls-certificate. Нужна проверка клиентов на этом входе — задайте файл здесь явно.
Как проверить на узле
Проверять надо порт того слушателя, о котором речь, — у соседнего значение может быть другим:
openssl crl2pkcs7 -nocrl -certfile /etc/pmta/partner-ca.pem | openssl pkcs7 -print_certs -noout
В выводе перечислены субъекты сертификатов файла. Если проверка не срабатывает, ищите способ проверки логина: без него список не участвует.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Безопасность узла · Подключить платформу отправки