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

Rotating cryptographic keys
Оба ключа живут рядом, пока очередь не опустеет

Порядок действий здесь важнее самих действий. Он существует в такой форме потому, что настройки применяются без остановки узла: оба ключа могут стоять в конфигурации одновременно, и переход ничего не стоит.

Новый ключ добавляется и включается раньше, чем трогают старый. Не наоборот. Сначала он появляется в конфигурации под другим селектором, настройки применяются, подпись переключается на него.

Удаление ждёт очередь. Старый ключ убирается только тогда, когда ни одно письмо в очереди на него больше не рассчитывает. Руководство приводит пример: письмо, выбравшее ключ своим заголовком, — ждать надо, пока такие письма не будут доставлены или отбиты.

Тот же порядок годится и для другого криптографического материала. Руководство называет сертификат TLS: форма процедуры та же — добавить, переключиться, дождаться, убрать.

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

Закрытые части Хаб кладёт на узел сам, в закрытый каталог (/etc/pmta/dkim, права 700, ключи 600), и правит строку подписи в блоке адреса отправки.

⚠️ Ошибка «подпись плохая» сразу после ротации — почти всегда кэш DNS, а не дефект. Это уже встречалось: проверять надо время жизни записи, а не искать поломку в подписи.

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

Порядок и сроки:

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

Селектор обязан отличаться. Два ключа под одним селектором — это не ротация, а замена: старая подпись перестанет проверяться мгновенно.

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

Сроки публикации и совет про кэш наши — из собственного опыта ротации. Из руководства здесь сам порядок шагов, требование другого селектора, ожидание ухода писем и указание, что та же форма годится для сертификата TLS.
Пример в конфигурации
# оба ключа стоят рядом, пока очередь не опустеет
<virtual-mta mta-news-1>
    domain-key sel2,example.com,/etc/pmta/dkim/private_key_example.com.txt    domain-key sel1,example.com,/etc/pmta/dkim/private_key_old.txt
</virtual-mta>
Выделенная строка — новый ключ, добавленный первым. Нижняя убирается позже, когда писем, зависящих от неё, в очереди не останется.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Убирают старый ключ сразу после переключения

§ 1.6.2

Чем чреватоПисьма, уже стоящие в очереди и выбравшие старый ключ, останутся без подписи или получат неверную. Отбиться они могут через сутки, и связать это с ротацией будет уже трудно.
Как заметитьЧасть писем после ротации приходит с непроверяемой подписью, и все они старше момента переключения.
Как правильноДержать оба ключа, пока очередь не опустеет. Убирать старый отдельным шагом, а не в той же правке.

Публикуют запись в DNS в день переключения

§ 1.6.2

Чем чреватоУ записи есть время жизни в кэше. Приёмник, спросивший её раньше, будет отвечать себе старым ответом — и подпись новым ключом у него не сойдётся. Выглядит как поломка подписи, лечится ожиданием.
Как заметитьСразу после ротации часть приёмников сообщает о плохой подписи, часть — нет.
Как правильноПубликовать открытую часть заранее, за время жизни записи до переключения. При жалобах — сначала проверять кэш, а не подпись.

Оставляют тот же селектор

§ 1.6.2

Чем чреватоДва ключа под одним селектором — это не ротация, а замена: старая подпись перестаёт проверяться мгновенно, и все письма в очереди оказываются с непроверяемой подписью разом.
Как заметитьПровал проверки подписи сразу и у всех приёмников.
Как правильноМенять селектор вместе с ключом. Именно разные селекторы и позволяют двум ключам жить рядом.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
⇄

Связанные записи

4 связи

Как проверить на узле
Проверять надо и подпись, и то, разошлась ли запись по кэшам:
dig +short sel2._domainkey.example.com TXT
pmta show queues '*/mta-news-1'
Первая покажет, опубликована ли открытая часть нового селектора. Вторая — есть ли ещё письма у адреса отправки, который подписывает этим доменом: старый ключ убирают после того, как его очереди опустели.
В Хабе
Цена ошибки
опасно: последствия переживут откат
Сценарии
Ротация ключей · Подпись и аутентификация писем