База знаний PMTA›Блок <transmissions-api-listener>›Директива§ 3.3.21.12

tls-ca-file

<transmissions-api-listener>

Файл доверенных центров для клиентских сертификатов входа API

в конфигурации это строкаtls-ca-fileвнутри блока <transmissions-api-listener>

То же имя ещё 2:<smtp-listener><smtp-user><transmissions-api-listener>— часть из них другие настройки, часть та же самая

Кому вход по API верит на входе

Файл в формате PEM с сертификатами удостоверяющих центров. По ним вход проверяет сертификат, который прислал подающий клиент. Умолчания нет.

Своего сертификата вход здесь не берёт — для этого есть tls-certificate. Эта строка про чужие сертификаты.

Руководство противоречит само себе о том, где писать строку. Раздел § 8.1.2 велит класть её «внутрь тега <transmissions-api>», а справочник § 3.3.21.12 и указатель главы 15 — внутрь <transmissions-api-listener>. Правы последние двое: настройка относится к входу. Написанная не в тот блок, она молча ничего не делает.

Клиентский сертификат — не замена ключу. Право подавать письма даёт api-key в заголовке; проверка сертификата — дополнительный слой поверх.

Главная ловушка — написать строку в блок <transmissions-api>, как советует § 8.1.2. Ошибки не будет, проверки тоже. Класть надо в блок входа.

Что делает Хаб. Не пишет: подача у нас идёт по SMTP, блока входа по API в конфигурации нет.

Рекомендуемые значения

Строка нужна только там, где клиенты представляются сертификатом:

Значение	Когда
не задавать (умолчание)	клиенты подают по ключу
путь к PEM	подающий клиент представляется своим сертификатом

Файл кладут в блок входа, а не в <transmissions-api>.

Формат PEM и назначение — из руководства (§ 3.3.21.12). Расхождение с § 8.1.2 о том, в какой блок писать строку, — наша находка; указатель главы 15 подтверждает блок входа.

Пример в конфигурации

# доверенные центры для клиентских сертификатов — в блоке ВХОДА
<transmissions-api-listener 1.2.3.4:8585>
    tls-certificate /etc/pmta/transmissions-api-certificate.pem
    tls-ca-file /etc/pmta/certchain.pem</transmissions-api-listener>

Раздел § 8.1.2 показывает эту строку внутри <transmissions-api> — там она не сработает.

жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.

▲

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

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

Пишут строку в блок transmissions-api по совету главы 8

§ 8.1.2

Чем чреватоНастройка относится ко входу, а не к общему блоку API. В общем блоке она молча ничего не делает — ни ошибки, ни проверки.

Как заметитьФайл задан, а клиентские сертификаты не проверяются.

Как правильноПеренести строку в <transmissions-api-listener>.

Кладут в строку собственный сертификат входа

наш опыт

Чем чреватоВход его не подхватит: строка задаёт доверенные центры для чужих сертификатов, а свой берётся из tls-certificate.

Как заметитьСтрока задана, а клиент по-прежнему ругается на сертификат входа.

Как правильноСвой сертификат — в tls-certificate, чужие центры — сюда.

Совместимость

PowerMTA 6.0

описана в руководстве этой версии · платформа: любая

С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.

Справочные данные

Синтаксис: tls-ca-file <path>
Значения: путь к файлу PEM
Применение: reload, перезапуск не нужен
Очередь: уже поставленное в очередь не затронет
Где писать: <transmissions-api-listener>
Сколько раз: один раз в блоке

Всё здесь — из руководства, с разделом.

Наследование

Наследования нет: строка действует внутри своего <transmissions-api-listener>. У каждого входа свой список доверенных центров.

⇄

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

2 связи

То же имя в других блоках

tls-ca-file<smtp-listener>Одноимённая строка у слушателя почты; здесь она про отдельный вход, свой у API. § 3.3.21.12

Работают в паре

tls-certificate<transmissions-api-listener>Одна строка говорит, кто этот вход; другая — чьим клиентским сертификатам он верит. inference

Как проверить на узле

Сначала смотрим, что вход вообще предъявляет и просит:

openssl s_client -connect NODE:8585 -msg </dev/null | grep -c CertificateRequest

1 — вход просит клиентский сертификат, значит файлу есть что проверять; 0 — не просит, и строка бесполезна. Сам файл разбирается командой openssl crl2pkcs7 -nocrl -certfile ФАЙЛ | openssl pkcs7 -print_certs -noout.

◇

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

3 статьи

◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Группа, дающая право управлятьЧленство в группе pmta даёт непривилегированному пользователю право звать команды узла и пользоваться подачей.◇Как узел выбирает источник и складывает его настройкиСоединение попадает под все блоки источника, чьи адреса его накрывают, и действуют они слитно — узкий перекрывает широкий; именованные блоки подключаются только по прямой ссылке.

В Хабе

Цена ошибки: обратимо: вредит, пока стоит
Сценарии: Безопасность узла

Соседние настройки блока <transmissions-api-listener>:tls-certificate tls-min-version tls-max-version tls-cipher-server-preference tls-ciphers Все 15 директив блока →