Demo
Demo
База знаний PMTA›Блок <domain>›Директива§ 3.3.10.108.13

smtp-client-certificate

<domain>

Собственный сертификат, предъявляемый приёмнику
в конфигурации это строкаsmtp-client-certificateвнутри блока <domain>
Когда приёмник хочет знать, кто к нему пришёл

Обычно проверка односторонняя: узел смотрит на сертификат приёмника, а сам ничего не предъявляет. Эта строка включает обратное направление — узел показывает свой сертификат.

Нужно это редко и по договорённости. Публичные приёмники клиентских сертификатов не спрашивают; они встречаются у корпоративных шлюзов и партнёрских каналов, где стороны договорились именно так.

Пароль — вторым словом и необязателен: если ключ в файле не зашифрован, слова не будет.

Проверка приёмника этой строкой не включается. Она про то, что предъявляем мы; за то, чему верим мы, отвечает smtp-tls-ca-file.

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

Значение — путь к файлу и, при необходимости, пароль:

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

Что предусмотреть до включения: срок действия сертификата и кто его продлевает. Истёкший клиентский сертификат приёмник отвергнет, и это будет выглядеть как отказ доставки без внятной причины.

Форма записи и необязательность пароля — из руководства (§ 3.3.10.108.13). Замечания про хранение ключа и срок действия — наши.
Пример в конфигурации
# партнёрский шлюз требует взаимной проверки
<domain partner-gw.example.net>
    use-starttls yes
    require-starttls yes
    smtp-client-certificate /etc/pmta/client.pem</domain>
Пароль здесь не указан — значит ключ в файле не зашифрован, и права на него должны быть такими же узкими, как на конфигурацию.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Ставят клиентский сертификат в общий блок получателей

наш опыт

Чем чреватоУзел начинает предъявлять свой сертификат всем приёмникам. Пользы нет, а лишняя информация о нашей инфраструктуре уходит наружу с каждым соединением.
Как заметитьСтрока стоит в <domain *>.
Как правильноСтавить только тем приёмникам, с которыми есть договорённость.

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

наш опыт

Чем чреватоИстёкший сертификат приёмник отвергнет. Доставка прекратится, а причина в отказе будет названа общими словами — искать придётся долго.
Как заметитьДоставка к одному приёмнику останавливается в конкретный день без изменений в конфигурации.
Как правильноЗавести напоминание по дате из notAfter и проверять её командой из справки при каждом разборе.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
smtp-client-certificate <path>
Значения
путь к файлу сертификата, при необходимости пароль вторым словом
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <domain> и сливается по обычному правилу блоков получателей: побеждает самое точное совпадение по имени приёмника. Те же три уровня действуют по адресу отправки — узел, <virtual-mta-pool>, <virtual-mta>. В <domain *> строку не ставят: предъявлять свой сертификат всем подряд незачем.
⇄

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

1 связь

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

use-starttls<domain>Клиентский сертификат предъявляется в ходе шифрованного согласования и без него не участвует. § 3.3.10.108.13

Как проверить на узле
Что сертификат читается и не истёк, проверяют до включения:
openssl x509 -in /etc/pmta/client.pem -noout -subject -enddate
Дата в notAfter — то, за чем придётся следить. Истёкший клиентский сертификат приёмник отвергнет, и в отказе причина будет названа расплывчато.
◇

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

3 статьи

◇Подача по HTTPS на своём приёмнике, по образцу SparkPostОтдельный вход: свой приёмник с сертификатом, свои ключи и зарезервированное имя источника, через которое к такой почте применяются обычные настройки подачи.◇Приёмник объявляет требование шифрования на своём сайтеУзел забирает политику получателя по HTTPS и, если та в режиме принуждения, доставляет только при совпадении MX, шифровании и проверенном сертификате.◇Приёмник объявляет требование шифрования в своей зоне DNSУзел смотрит записи DANE получателя и, если тот требует STARTTLS, отправляет только по зашифрованному каналу с проверенным по отпечатку сертификатом.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Шифрование соединений
Соседние настройки блока <domain>:use-starttlssmtp-tls-min-versionuse-daneuse-mta-stsrequire-starttlsВсе 135 директив блока →