Resumo

  • O RFC 6844 permitiu que o titular de um domínio informasse quais autoridades certificadoras podiam emitir para aquele nome. A regra original podia seguir um CNAME ou DNAME e depois subir pelos nomes superiores do destino; assim, a política CAA de uma hospedagem podia entrar na consulta do cliente.
  • O RFC 8659 preservou a resolução normal de aliases do DNS, mas limitou a subida pelos nomes superiores ao FQDN que estava sendo verificado. A mudança separou com mais clareza a política do cliente da árvore de nomes da hospedagem.

A resposta do DNS abre outra pergunta

Considere o exemplo hipotético www.client.example como um CNAME de tenant.platform.example. O nome do cliente passa pelo espaço de nomes de uma hospedagem compartilhada. Antes de emitir um certificado, a autoridade certificadora precisa responder a outra pergunta: qual conjunto CAA vale para www.client.example?

A dificuldade aparece quando a consulta cruza uma fronteira. O cliente administra uma árvore DNS; o provedor administra outra. O resolvedor pode seguir um alias de uma para a outra em instantes. A CA também deveria subir pelos nomes superiores do provedor para aplicar uma regra que o cliente nunca publicou em sua zona?

Publicado em janeiro de 2013, o RFC 6844 definiu o registro DNS Certification Authority Authorization, tipo 257. O titular de um domínio podia indicar uma ou mais CAs autorizadas a emitir para aquele nome. Antes da emissão, uma CA em conformidade precisava consultar o conjunto CAA pertinente e rejeitar pedidos incompatíveis, salvo quando uma exceção prevista em sua política de certificação ou declaração de práticas se aplicasse.

O CAA colocou no DNS uma regra que o titular do domínio já podia publicar junto aos outros dados de seu nome. A CA ganhava um controle para consultar antes de emitir. Mas o alcance desse controle dependia do que “pertinente” queria dizer numa busca que atravessava nomes DNS.

Em 2013, a busca podia percorrer duas árvores

A regra de processamento do RFC 6844 não subia apenas do nome consultado aos seus pais. Se a consulta CAA não encontrasse um registro naquele rótulo e ali existisse um alias CNAME ou DNAME, o procedimento podia seguir o destino e recomeçar a busca. Se ainda não houvesse registro, subia ao pai do nome original.

Os nomes fictícios mostram o efeito. Suponha que www.client.example aponte para tenant.platform.example e que a hospedagem publique CAA 0 issue "issuer.example" em platform.example. A regra recursiva do RFC 6844 podia seguir o alias e depois chegar a platform.example, onde encontraria essa política. Um registro escrito na zona superior do provedor podia entrar na consulta de emissão para o nome do cliente.

A regra procurava o conjunto CAA aplicável; não transferia ao provedor a titularidade do domínio do cliente. Mesmo assim, a resolução DNS e a herança da política andavam juntas. O caminho do cliente seguia o alias da hospedagem e podia depois encontrar os nomes superiores dela. Num serviço compartilhado, cada alias de cliente podia herdar uma regra publicada acima na árvore do provedor.

Em 2019, a subida ficou na árvore do nome solicitado

Publicado em novembro de 2019, o RFC 8659 substituiu o RFC 6844 e alterou o algoritmo. A CA ainda consulta CAA para o FQDN solicitado segundo o funcionamento normal do DNS, que pode resolver aliases. Se a consulta não retornar um conjunto CAA, o algoritmo sobe pelos rótulos superiores do FQDN em análise. Ele deixou de subir separadamente pelas árvores superiores de cada alvo CNAME ou DNAME encontrado.

A diferença é estreita, mas decisiva. Uma consulta DNS ainda pode devolver um registro CAA localizado exatamente no alvo do alias. O que mudou foi a subida independente pelos pais desse alvo. A política na árvore do cliente ainda pode cobrir seus subdomínios; a política superior da hospedagem não entra na consulta do cliente apenas porque um CNAME aponta para o espaço de nomes do provedor.

O RFC 8659 explica a mudança ao comparar o algoritmo anterior: subir tanto pela árvore do nome quanto pela árvore de cada alias era ineficiente em cadeias longas e podia dificultar que uma hospedagem definisse uma política CAA para seus próprios FQDNs sem criar regras potencialmente indesejadas para clientes. A revisão formulou uma pergunta mais precisa: depois da resolução normal de DNS, que conjunto CAA vale para este nome solicitado e o que dizem os pais dele?

Autorização de emissão não é validação no navegador

O CAA atua antes da emissão. Ele não pede que um navegador reavalie um certificado já emitido, e uma mudança no DNS não revoga um certificado existente. O padrão proíbe que quem usa um certificado consulte o CAA atual para validá-lo. O registro descreve a autorização vigente na hora da emissão; o horário importa.

O registro também não autentica, por si só, a resposta DNS. O RFC 8659 recomenda fortemente DNSSEC para CAA, mas não o torna obrigatório. Se a consulta for bloqueada, a resposta vier malformada ou um retorno vazio for tratado incorretamente, a CA ainda não terá uma resposta confiável sobre a política. O capítulo de implantação do RFC enumera essas falhas porque a regra só funciona quando o emissor consegue obter e interpretar o registro.

O CAA tem propriedades diferentes. issue cobre certificados comuns; quando aparece, issuewild rege solicitações de certificados wildcard. Um valor de emissor vazio pode pedir que nenhuma CA emita para aquele nome. Essas tags registram o conteúdo da política. A revisão de 2019 define em que árvore a CA deve procurá-lo.

Essa é a mudança histórica: o primeiro padrão CAA deu ao titular do domínio um lugar no DNS para indicar quem podia emitir; o sucessor separou melhor essa árvore daquela do provedor de hospedagem. A resolução DNS continua seguindo aliases. A busca de autorização deixou de tratar os pais de cada destino como se fossem pais do nome do cliente.

Os nomes deste exemplo foram construídos a partir dos algoritmos; não descrevem um incidente relatado. Os RFCs registram a regra pretendida. Para medir a implementação de cada CA, seriam necessários seus logs de consulta e decisões de emissão associados aos nomes e horários.

Fontes