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

tls-certificate

<smtp-user>

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

Строка называет тот самый файл сертификата, который клиент обязан предъявить при авторизации. Не «сертификат от такого-то центра», а именно этот.

Работает только при authentication-method со значением certificate. И требует шифрованного соединения — сертификат предъявляется в ходе согласования TLS.

Сертификат можно выпустить инструментом из поставки — pmtakeytool, — или обычным OpenSSL.

Отличие от способа с доверенным центром. Здесь проверка буквальная: подойдёт один файл. Там — любой сертификат, сходящийся к цепочке; удобнее, когда логинов много, и слабее, когда логин один.

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

Значение — путь к файлу. Что решается вместе с ним:

Что Замечание
кто выпускает pmtakeytool из поставки или OpenSSL
срок действия подача остановится в день истечения
где лежит закрытый ключ клиента у подающей стороны, не у нас
шифрование соединения обязательно, иначе способ не работает
Требование способа «сертификат», необходимость TLS и упоминание pmtakeytool — из руководства (§ 3.3.8.3). Замечания про срок и ответственность — наши.
Пример в конфигурации
# логин подтверждается конкретным файлом, а не паролем
<smtp-user foo>
    authentication-method certificate
    tls-certificate /etc/pmta/bar-cert.pem</smtp-user>
Пример руководства. Обе строки нужны вместе: без первой вторая не участвует. И соединение обязано быть зашифровано.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Не следят за сроком действия

наш опыт

Чем чреватоВ день истечения логин перестаёт авторизоваться. Конфигурация не менялась, и причину ищут в чём угодно.
Как заметитьПодача одного логина останавливается в конкретную дату.
Как правильноЗнать notAfter и продлевать заранее. Проверка — одна команда.

Задают файл без выбора способа проверки

§ 3.3.8.3

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

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

1 связь

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

authentication-method<smtp-user>Строка работает при способе «сертификат» и только при нём. § 3.3.8.3

Как проверить на узле
Срок действия сертификата стоит проверять до того, как он кончится:
openssl x509 -in /etc/pmta/bar-cert.pem -noout -subject -enddate
Дата notAfter — день, когда подача этого логина остановится. Заводить напоминание стоит сразу при выпуске.
◇

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

3 статьи

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

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