DANE Trust Anchor - auto-assinado ou não

Question

Executamos uma CA privada e empregamos tanto DNSSEC quanto DANE. Recentemente, decidimos reemitir nossas chaves de raiz e emissor da CA, pois elas foram geradas a 1024 bits quando nossa PKI foi configurada em 2008. Nosso TLSA RR original apontou para a CA de emissão como a âncora de confiança. No entanto, a releitura dos RFCs e vários comentários relacionados ao DANE levantam a questão de se a chave pública ROOT deve ser usada no lugar.

No momento, estamos testando essa ideia paralelamente aos nossos registros DANE existentes. Quando usamos link para validar, então nossa chave de servidor existente faz o check-out, mas o novo registro ROOT TLSA também é relatado, embora tenhamos não mudou a chave do servidor para a nova cadeia de certificados. Além disso, a nova âncora de confiança TLSA RR é relatada da seguinte forma:

Registros TLSA utilizáveis

2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e - self signed certificate in certificate chain: (19)

Considerando que o atual TLSA RR para o mesmo host é relatado desta maneira:

2, 0, 2 67274b3554289058[...]5fd3917510e6722a

O primeiro registro relatado refere-se à nova CA raiz. O segundo refere-se à CA de emissão original (assinada pela CA raiz original).

Quando eu verifico a mensagem self signed certificate in certificate chain: (19) , a impressão que eu faço é que isso é um erro. No entanto, se for um erro, exatamente onde a chave pública da CA Root se encaixa no esquema DANE?

    

Answer 1

O que descobri através da experimentação é o seguinte:

Se colocarmos a raiz e a CA de emissão TLSA RRs na zona de encaminhamento de DNS, o erro relatado acima desaparecerá. Por exemplo:

Dado este host RR:

_443._tcp.inet04.hamilton.harte-lyne.ca.        300 IN  CNAME   _tlsa._dane.trust.harte-lyne.ca.

Se apenas o registro a seguir existir para a AC raiz autoassinada na zona de encaminhamento, veremos o erro (ou o aviso não tenho certeza de qual é) relatado na pergunta original:

;# 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 )

Verificando com este site de teste:

https://dane.sys4.de/smtp/inet04.hamilton.harte-lyne.ca

Produz esse erro ou aviso:

Usable TLSA Records
2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e - self signed certificate in certificate chain: (19)

No entanto, se o seguinte TLSA RR for adicionado para a CA de emissão assinada pela CA raiz juntamente com a CA raiz auto-assinada; e o hospedeiro RR permanece inalterado; então ambos TLSA RRs são relatados como utilizáveis sem nenhum erro ou mensagem de aviso:

;# 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 )

Visitando o site de teste após o vencimento do TTL:

https://dane.sys4.de/smtp/inet04.hamilton.harte-lyne.ca

Dá isto:

Usable TLSA Records
2, 1, 2 c26e0ec16a46a973[...]ce60eabc5adba90e
2, 1, 2 380259229e21a194[...]435a2a3e83c1f80f

A inferência é que um certificado autoassinado é 'possivelmente' válido, mas não confiável, enquanto a cadeia completa de certificados é válida e confiável.

Eu gostaria de ter a mecânica do processo explicada, no entanto.