Demo
Demo
База знаний PMTA›Блок <smtp-user>›Директива§ 3.3.8.5

tls-certificate-san-or-cn

<smtp-user>

Имя, которое должно стоять в сертификате подающего
в конфигурации это строкаtls-certificate-san-or-cnвнутри блока <smtp-user>
Не просто «от нашего центра», а «именно от этого клиента»

Проверка цепочки отвечает на вопрос «свой ли центр выдал сертификат». Эта строка отвечает на второй, куда более важный: тот ли клиент пришёл.

Значение — полное доменное имя без подстановочных знаков. Оно сверяется с полем SAN или CN клиентского сертификата.

Подстановка разрешена со стороны сертификата. Руководство приводит пример: сертификат с SAN *.messagebird.com подойдёт под заданное имя pmta.messagebird.com. То есть звёздочку ставит клиент, а не мы, и покрывает она только первую метку.

Работает при authentication-method со значением ca-file, поверх tls-ca-file.

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

Значение — полное доменное имя. Что оно даёт и чего не даёт:

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

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

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

Пишут подстановку в значении

§ 3.3.8.5

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

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

1 связь

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

tls-ca-file<smtp-user>Проверка имени работает поверх проверки цепочки и без неё не применяется. § 3.3.8.5

Как проверить на узле
Какие имена стоят в сертификате клиента, видно до настройки:
openssl x509 -in client.pem -noout -text | grep -A1 "Subject Alternative Name"
Если в SAN стоит подстановка, проверка сузит круг до домена, а не до машины. Это стоит знать заранее и, если нужно строже, попросить клиента о сертификате без подстановки.
◇

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

3 статьи

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

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Безопасность узла
Соседние настройки блока <smtp-user>:tls-ca-filetls-certificateauthentication-methodpasswordsourceВсе 6 директив блока →