Кратко

  • Имя владельца TLSA включает порт, транспорт и базовый домен. Совпадение подтверждает связь сертификата с этим сервисным кортежем и способом проверки, а не всеобщее доверие к хосту.
  • Для повторной проверки нужны точное имя запроса, состояние DNSSEC, certificate usage, selector, matching type, материал рукопожатия, правило приложения и время. Метка «DANE pass» стирает область действия.

Другой порт — другое утверждение

Рассмотрим учебный тест. service.example показывает одинаковый сертификат на TCP 443 и 8443. Подписанная зона публикует пригодный TLSA RRset лишь по имени _443._tcp.service.example. Клиент порта 443 проверяет DNSSEC и сопоставляет указанный объект. Для 8443 требуется запрос _8443._tcp.service.example; прежний успех нельзя перенести.

Это синтетический пример, а не обвинение продукта. Он проверяет распространённое сокращение: «сертификат уже прошёл DANE на этом сервере». RFC 6698 не выдаёт сертификату репутацию на весь хост. Порт и транспорт входят в DNS-имя именно затем, чтобы соседние сервисы могли иметь разные связи, владельцев и графики ротации.

Хранилище, оставляющее только hostname и fingerprint, удаляет границу полномочий. При последующем повторном использовании ключа оно уже не покажет, для какого сервиса было получено решение.

Путь получения имени — часть доказательства

Для прямого TLS через TCP типичная форма — _порт._tcp.базовый-домен. Порт записывается десятичным числом, транспортный label разделяет механизмы, базовый домен выбирается правилами приложения.

CNAME способен перенести разрешение. Протоколы с SRV выводят имя согласно RFC 7673. SMTP DANE начинает с MX и отдельно определяет базовый домен, reference identifiers, обработку DNS-ошибок и fallback. Конечный IP в журнале сокета не всегда объясняет источник полномочий.

Следует сохранять исходное назначение, шаги MX/SRV/CNAME, имена до и после раскрытия, порт, транспорт, итоговый TLSA owner name, результат DNSSEC и применённое нормативное правило. Без этого вердикт нельзя воспроизвести.

Четыре usage задают разные модели доверия

PKIX-TA(0) ограничивает центр сертификации при сохранении проверки PKIX. PKIX-EE(1) ограничивает конечный сертификат и также требует корректный PKIX path. DANE-TA(2) публикует trust anchor через DNSSEC. DANE-EE(3) напрямую связывает сервис с конечным сертификатом или ключом.

Совпадение байтов не делает usage взаимозаменяемыми. При usage 1 оно не оправдывает просроченный сертификат или неверную цепочку. При usage 3 нельзя автоматически добавлять не предусмотренные приложением правила Web PKI. SMTP DANE дополнительно сужает подходящие варианты для своей оппортунистической модели.

Полное решение отвечает, какой usage опубликован, какой подписанной зоной, для какого сервиса, каким клиентом и с какой политикой отказа.

Selector выбирает объект, matching type — сравнение

Selector 0 выбирает полный DER-сертификат, selector 1 — SubjectPublicKeyInfo. При продлении сертификата с прежним ключом первый объект меняется, второй может остаться прежним.

Matching type 0 сравнивает выбранные байты, type 1 — SHA-256, type 2 — SHA-512. Одна hex-строка без этих полей не объясняет предмет проверки.

Выбор влияет на восстановление. Привязка полного сертификата узка, но требует обновления DNS при продлении. SPKI упрощает продление с тем же ключом, одновременно увеличивая последствия его компрометации. Trust anchor имеет иной радиус изменений. Правильный tuple определяется хранением ключей и возможностью rollback.

Полномочия публикации даёт DNSSEC

Синтаксически правильный RR type 52 недостаточен. Валидатор различает secure, insecure, bogus и indeterminate. Extended DNS Error помогает диагностике, но не заменяет проверку DS, DNSKEY и RRSIG.

Неподписанный ответ не должен ослаблять проверку сертификата. С другой стороны, бесшумный fallback после ошибки снова открывает downgrade, если профиль считает secure и пригодный RRset обязательством. SMTP DANE не разрешает доставку через сервер, который не удалось аутентифицировать по найденной безопасной связи.

DNSSEC удостоверяет публикацию под именем. Он не доказывает исключительное владение TLS-ключом и исправность приложения. Компрометация DNS-подписи может опубликовать новый DANE-EE, а компрометация TLS-ключа — удовлетворить старую запись. Это отдельные контуры контроля.

Совпадение ещё не разрешает действие

TLSA показывает, что выбранный материал рукопожатия удовлетворил связи. Он не решает, верен ли ALPN, допустим ли HTTP authority, аутентифицирован ли клиент, разрешена ли операция и завершилась ли транзакция.

Прокси завершает проверенное соединение и создаёт новую границу к backend. Ей нужны собственные доказательства. Общий конечный сертификат у функционально разных серверов позволяет подмену внутри набора; RFC 7672 рекомендует избегать такого общего использования.

Проверяемая формулировка узка: «в это время представленный SPKI совпал с secure TLSA usage 3 для этого имени». Формула «домен разрешил запрос» выходит за доказательство.

Ротация — интервал, а не момент

Новую связь сначала публикуют, затем некоторое время сохраняют старую и новую, наблюдают кэши и клиентов и только после учёта TTL, подписей и endpoint удаляют прежний материал.

Продление с тем же ключом может сохранить SPKI; смена ключа не может. Смена trust anchor отличается от смены конечного сертификата. Нужно датировать авторитативную публикацию, рекурсивную видимость, развёртывание, удаление и срок RRSIG. Один успешный resolver не доказывает конвергенцию.

Проверка должна пытаться пересечь границу

Покажите сертификат на двух портах, опубликовав TLSA для одного. Смените transport. Добавьте CNAME, SRV и MX. При usage 1 оставьте байты совпадающими, но сломайте PKIX path. Обновите сертификат сначала с тем же ключом, затем с новым.

Создайте secure, insecure, bogus и indeterminate. Наконец, добейтесь успеха TLSA и отказа ALPN или приложения. Корректная система оставит эти результаты раздельными.