Якорь доверия DANE - Самоподписанный или нет
Мы запускаем частный CA и используем как DNSSEC, так и DANE. Недавно мы решили повторно выпустить наши корневые ключи CA и ключи эмитента, поскольку они были сгенерированы с 1024 битами, когда наша PKI была настроена в 2008 году. Наша исходная TLSA RR указала на выдающий CA как на якорь доверия. Однако при повторном чтении RFC и различных комментариев, связанных с DANE, возникает вопрос, следует ли вместо этого использовать открытый ключ ROOT.
В настоящее время мы испытываем эту идею параллельно с нашими существующими записями DANE. Когда мы используем https://dane.sys4.de/smtp/ для проверки, тогда проверяется наш существующий ключ сервера, но также сообщается новая запись ROOT TLSA, даже если мы не переключили ключ сервера в новую цепочку сертификатов. Кроме того, новая RR TLSA привязки доверия сообщается следующим образом:
Используемые записи TLSA
2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e - self signed certificate in certificate chain: (19)
В то время как текущая RR TLSA для того же хоста сообщается следующим образом:
2, 0, 2 67274b3554289058[...]5fd3917510e6722a
Первая сообщенная запись относится к новому корневому CA. Второй относится к исходному ЦС-эмитенту (подписанному исходным корневым ЦС).
Когда я проверяю наличие самоподписанного сертификата сообщения в цепочке сертификатов: (19) , у меня складывается впечатление, что это ошибка. Однако, если это ошибка, то где именно открытый ключ CA Root вписывается в схему DANE?
Экспериментируя, я обнаружил следующее:
Если поместить и корневой, и выдающий CA TLSA RR в зону пересылки DNS, то указанная выше ошибка исчезнет. . Например:
Для этого хоста RR:
_443._tcp.inet04.hamilton.harte-lyne.ca. 300 IN CNAME _tlsa._dane.trust.harte-lyne.ca.
Если для самозаверяющего корневого CA в зоне прямого доступа существует только следующая запись, то мы видим ошибку (или предупреждение, которое я не уверен, какое именно), сообщаемое в исходный вопрос:
;# CA_HLL_ROOT_2016 public key hashed sha512 Trust Anchor (active)
_tlsa._dane.trust.harte-lyne.ca. 300 IN TLSA ( 2 1 2
c26e0ec16a46a97386e8f31f8ecc971f2d73136aa377dfdaac2b2b00f7cab4bb29b
17d913c82093b41fd0d9e40b66a68361c126f1f4017f9ce60eabc5adba90e )
Проверка на этом тестовом сайте:
https://dane.sys4.de/smtp/inet04.hamilton.harte-lyne.ca
Выдает эту ошибку или предупреждение:
Usable TLSA Records
2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e - self signed certificate in certificate chain: (19)
Однако, если следующий TLSA RR добавлен для выдающего CA, подписанного корневым CA вместе с самоподписанный корневой ЦС; и хост RR остается без изменений; тогда оба TLSA RR сообщаются как пригодные для использования без каких-либо сообщений об ошибках или предупреждениях:
;# CA_HLL_ISSUER_2016 public key hashed sha512 Trust Anchor (active)
_tlsa._dane.trust.harte-lyne.ca. 300 IN TLSA ( 2 1 2
380259229e21a1946b38cfc594cbc993b61bc93762b7b6c6637b3eef9c5a2bb70c5
89b91beb73bd1304eac11b3917e33819e2b47d25d4966435a2a3e83c1f80f )
Посещение тестового сайта после истечения срока действия TTL:
https://dane.sys4.de/smtp/inet04.hamilton.harte-lyne.ca
Дает следующее:
Usable TLSA Records
2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e
2, 1, 2 380259229e21a194[...]435a2a3e83c1f80f
Вывод состоит в том, что самоподписанный сертификат «возможно» действителен, но ненадежен, тогда как вся цепочка сертификатов действительна и надежна.
Тем не менее, я хотел бы получить объяснение механики процесса.