tls-ca-file

<smtp-user>

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

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

Работает при authentication-method со значением ca-file и требует шифрованного соединения.

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

Проверка мягче, чем у способа с одним файлом. Подойдёт любой сертификат от доверенного центра — в том числе выданный кому-то другому. Сузить можно проверкой имени: tls-certificate-san-or-cn.

Главная ловушка — забыть, что цепочка не проверяет, кто именно пришёл. Любой сертификат, выданный тем же центром, подойдёт этому логину. Если центр выдаёт сертификаты не только вам, проверка имени обязательна, а не желательна.
Что делает Хаб. Не пишет: подача идёт по логину и паролю. Способ пригодится там, где подающих много и у них общий центр сертификации — тогда добавление платформы не требует правки конфигурации узла.
Рекомендуемые значения

Значение — путь или несколько путей:

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

И почти всегда рядом — tls-certificate-san-or-cn: без него подойдёт любой сертификат этого центра.

Правило «подойдёт любая из цепочек», несколько файлов и требование PEM — из руководства (§ 3.3.8.4). Совет про обязательную проверку имени — наш.
Пример в конфигурации
# цепочки разных лет живут рядом, пока идёт переход
<smtp-user foo>
    authentication-method ca-file
    tls-ca-file /etc/pmta/ca-certs2020.pem    tls-ca-file /etc/pmta/ca-certs2021.pem, /etc/pmta/ca-certs2022.pem
    tls-certificate-san-or-cn pmta.messagebird.com
</smtp-user>
Пример руководства, дополненный последней строкой: без неё подойдёт любой сертификат от любого из перечисленных центров, а не только тот, что выдан этой платформе.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Полагаются на цепочку без проверки имени

наш опыт

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