У нас есть частный центр сертификации и используются как DNSSEC, так и DANE. Недавно мы решили повторно выпустить наши корневые ключи CA и ключи эмитента, поскольку они были сгенерированы с 1024 битами, когда наша PKI была настроена в 2008 году. Наша первоначальная запись TLSA RR указала на выдающий CA как на якорь доверия. Однако при повторном чтении RFC и различных комментариев, связанных с DANE, возникает вопрос, следует ли вместо этого использовать открытый ключ ROOT.
В настоящее время мы испытываем эту идею параллельно с нашими существующими записями DANE. Когда мы используем https://dane.sys4.de/smtp/ чтобы проверить, то наш существующий ключ сервера проверяется, но также сообщается о новой записи ROOT TLSA, даже если мы не переключили ключ сервера на новую цепочку сертификатов. Далее, новый якорь доверия TLSA RR сообщается следующим образом:
Используемые записи TLSA
2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e - self signed certificate in certificate chain: (19)
В то время как текущий TLSA RR для того же хоста сообщается следующим образом:
2, 0, 2 67274b3554289058[...]5fd3917510e6722a
Первая сообщенная запись относится к новому корневому центру сертификации. Второй относится к исходному ЦС-эмитенту (подписанному исходным корневым ЦС).
Когда я проверяю сообщение self signed certificate in certificate chain: (19) у меня складывается впечатление, что это ошибка. Однако, если это ошибка, то где именно открытый ключ CA Root вписывается в схему DANE?
В результате экспериментов я обнаружил следующее:
Если разместить как корневой, так и выдающий CA TLSA RRs в зоне переадресации DNS, тогда указанная выше ошибка исчезнет. Например:
Учитывая этот хост RR:
_443._tcp.inet04.hamilton.harte-lyne.ca. 300 IN CNAME _tlsa._dane.trust.harte-lyne.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 вместе с самозаверяющим корневым 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
Подразумевается, что самозаверяющий сертификат «возможно» действителен, но ненадежен, тогда как вся цепочка сертификатов действительна и надежна.
Тем не менее, я хотел бы получить объяснение механики этого процесса.