Verificação do Registro de Recurso CAA de DNS

Autoridades de certificação verificam os registros de recursos CAA antes de emitirem um certificado

Antes de uma autoridade de certificação (CA) poder emitir um certificado SSL/TLS para o seu domínio, eles devem verificar, processar e respeitar os registros de recurso (RRs) da Autoridade de Autoridade de Certificação DNS (CAA) do domínio. (Veja Votação 125 – Registros CAA[PASSADO], RFC 6844, e votação 219: Esclarecer o manuseio dos conjuntos de registros CAA sem" emitir"/"emitir" tag de propriedade selvagem.)

Um registro de recurso da CAA NÃO É NECESSÁRIO para a DigiCert emitir certificados SSL/TLS para seus domínios. As informações fornecidas aqui são importantes apenas se você estiver em uma destas situações:

  • Você já possui registros de recursos CAA configurados para seus domínios.
  • Você deseja adicionar registros de recursos CAA para seus domínios.

Para obter informações sobre os benefícios do CAA, consulte Os benefícios de segurança do CAA.

Como o processo RR CAA funciona

Antes de emitir um certificado SSL/TLS para o seu domínio, uma CA (como a DigiCert) verifica os RRs da CAA para determinar se eles podem emitir um certificado para o seu domínio. Uma CA pode emitir um certificado para o seu domínio se uma das seguintes condições for atendida:

  • Eles não encontram um RR CAA para o seu domínio.
  • Eles encontram um RR CAA para o seu domínio que os autoriza a emitir esse tipo de certificado para ele.
  • Eles encontram apenas RRs da CAA sem "emitir "ou emitir" tags de propriedades selvagens" neles para o seu domínio.

Potência de um único RR CAA

Depois de criar um registro de recurso da CAA (RR) para autorizar a DigiCert a emitir certificados SSL/TLS para um domínio, você efetivamente excluiu todas as outras autoridades de certificação (CAs) de emitir um certificado para esse domínio. A única maneira de autorizar outra CA a emitir certificados para esse domínio é criar outro RR CAA para essa CA.

Se não houver RR CAA para o domínio, isso significa que qualquer CA pode emitir todos os tipos de certificados SSL/TLS para o domínio.

Se você tiver um RR de CAA para o domínio, isso significa que uma CA deve encontrar um RR de CAA que os autorize a emitir um certificado SSL/TLS para o domínio. Ao criar seu primeiro RR CAA para um domínio, é importante entender que agora você deve criar políticas suficientes para esse domínio para suportar os requisitos de certificado SSL/TLS da sua organização.

Dessa maneira, os registros de recursos da CAA permitem um controle preciso sobre a emissão de certificados para o domínio. Esse controle pode ser usado para impedir que autoridades de certificação não autorizadas emitam certificados para o seu domínio.

Autorização da CA para os certificados de marca DigiCert, Symantec, Thawte, GeoTrust, RapidSSL

Com a aquisição do site de segurança da Symantec e soluções PKI relacionadas, A DigiCert reuniu as principais marcas de certificados do setor sob uma Autoridade de Certificação - DigiCert. Ao criar um RR CAA para yourdoman.com e autorizar a DigiCert a emitir certificados SSL/TLS para ele (yourdomain CAA 0 issue "digicert.com"), você autoriza a DigiCert a emitir os certificados SSL/TLS das marcas DigiCert, Symantec, Thawte, GeoTrust e RapidSSL para esse domínio.

O mesmo acontece quando você cria um RR CAA e autoriza a Symantec a emitir certificados SSL/TLS para yourdomain.com (yourdomain CAA 0 issue "symantec.com"). Esse registro único permite a DigiCert emitir certificados SSL/TLS das marcas DigiCert, Symantec, Thawte, GeoTrust e RapidSSL para esse domínio.

Valores válidos de registro de recurso CAA

Abaixo estão os valores válidos de RR CAA que você pode usar atualmente em seus registros CAA para autorizar a DigiCert a emitir seu certificado SSL/TLS

  • digicert.com
  • www.digicert.com
  • digicert.ne.jp
  • cybertrust.ne.jp
  • symantec.com
  • thawte.com
  • geotrust.com
  • rapidssl.com

Todos os valores listados são equivalentes. Em outras palavras, você pode usar qualquer um dos valores para permitir que a DigiCert emita certificados SSL/TLS para todas as marcas, portais, produtos certificados DigiCert.

Verifique se os RRs da CAA estão configurados corretamente

Você tem ou planeja criar RRs de CAA DNS para seus domínios? É importante garantir que seus registros estejam atualizados e precisos.

Na DigiCert, recomendamos verificar seus RRs DNS CAA existentes para seus domínios antes de solicitar certificados SSL/TLS para eles. Verifique se você possui os registros necessários para cada CA autorizada a emitir certificados SSL/TLS para seus domínios. Também recomendamos que aqueles que criam novos RRs de CAA DNS entendam como o processo funciona. Não permita que um RR de CAA mal configurado acidentalmente impeça uma CA de emitir um certificado necessário o mais rápido possível.

Veja Como editar o RR da CAA do DNS de um domínio para obter marcas de certificado DigiCert.

O que é um registro de recurso CAA DNS?

Os registros de recurso (RRs) da Autoridade de Autorização de Certificação (CAA) permitem que os proprietários de domínio criem políticas que autorizem autoridades de certificação específicas a emitir certificados SSL para seus domínios associados. Os proprietários do domínio podem usar os RRs CAA para criar políticas de segurança para um domínio inteiro (por ex., example.com) ou para um hostname específico (por exemplo, mail.example.com).

Ao criar um RR CAA para seu domínio base, você está essencialmente criando uma política abrangente para seus subdomínios nessa política, a menos que você crie um RR CAA separado para um subdomínio específico. Você tem um registro RR CAA para example.com), mas deseja criar uma política de segurança diferente para mail.example.com? Crie um RR de CAA adicional especificamente para o subdomínio de e-mail.

Com esse registro criado, quando você solicita um certificado SSL/TLS para mail.example.com, a CA consulta seu DNS em busca de RRs CAA para esse subdomínio. Se a CA encontrar um registro para mail.example.com, a pesquisa será interrompida e eles aplicarão essa política ao pedido de certificado. Se a CA não encontrar um registro para mail.example.com, eles continuarão sua consulta DNS para RRs de CAA em seu domínio principal, example.com. Se a CA encontrar um registro para o example.com, eles aplicarão a política do domínio principal ao pedido de certificado para mail.example.com.

Sintaxe do Registro de Recurso CAA DNS

Um registro de recurso (RR) da Autoridade da Autoridade de Certificação (CAA) consiste em um sinalizador de byte único e um par de valor-tag referido como uma propriedade (RFC 6844 seções 3, 5.1). O sinalizador é um número inteiro não atribuído entre 0 e 255. A tag no par valor-tag pode consistir em letras e números US-ASCII, enquanto o valor é uma sequência de octetos que representa o valor da propriedade valor-tag.

Tags de propriedade RR CAA

Você pode associar várias propriedades ao mesmo domínio publicando vários RR de CAA para esse nome de domínio. Contudo, cada RR da CAA pode autorizar apenas uma CA a emitir certificados (ou, em alguns casos, um tipo de certificado) para o seu domínio.

Para permitir que várias autoridades de certificação emitam certificados para seu domínio, você precisa criar pelo menos um RR de CAA para cada CA (e, em alguns casos, dois RR de CAA). Para obter ajuda na configuração dos RRs da CAA, visite Ajudante de registro CAA .

"emitir" property tag

Use esta tag de propriedade para autorizar uma CA (como DigiCert) a emitir apenas certificados curinga para um domínio. Ao processar um pedido de certificado curinga para * .yourdomain, a CA consulta o DNS do domínio em busca de RRs CAA que contêm a marca de propriedade "issuewild" . Se a CA encontrar uma tag de propriedade "issuewild" , todos os RR de CAA com a tag de propriedade de "emissão" desse domínio serão ignorados. Para autorizar outras CAs a emitir apenas certificados curinga para o mesmo domínio, você precisará criar um RR de CAA exclusivo para cada CA.

generic
yourdomain CAA 0 issuewild "digicert.com"

Como a"issuewild" funciona

A marca de propriedade "issuewild" autoriza uma CA a emitir apenas certificados curinga para um domínio (*.domain.com, *.sub.domain.com, *.sub.sub.domain.com, etc.). Ela não permite que uma CA emita certificados não curinga para um domínio (domain.com, sub.domain.com, sub.sub.domain.com, etc.).

Usando"issuewild" property tag

Quando usada corretamente, a propriedade "issuewild" pode ser uma ferramenta eficaz para criar políticas de emissão de certificados curinga.

Por exemplo, você cria três RRs de CAA de "emissão" para yourdomain. Mais tarde, você decide que deseja que apenas uma dessas autoridades de certificação emita certificados curinga para yourdomain. Portanto, você cria um RR de CAA "issuewild" autorizando a CA a emitir certificados curinga *.yourdomain. Todas as três autoridades de certificação podem continuar emitindo certificados não curinga para yourdomain, mas agora apenas uma CA pode emitir certificados curinga para ele.

Autorizar a DigiCert a emitir certificados curinga para um domínio

Quando você solicita um certificado curinga para *.yourdomain, a DigiCert inclui seu domínio no certificado, sem nenhum custo extra. Isso cria um problema ao criar RRs CAA "issuewild" (yourdomain CAA 0 issuewild "digicert.com") para autorizar a DigiCert a emitir apenas certificados curinga para sua base e subdomínios.

Como incluímos yourdomain (ou mail.yourdomain) com seu pedido de certificado curinga para *.yourdomain (ou * .mail.yourdomain), você deve usar uma das opções abaixo para que possamos emitir seu certificado curinga.

  1. Crie uma“emissão” RR CAA para DigiCert

    A menos que você tenha um motivo específico para criar um RR de CAA "issuewild" para yourdomain, não o faça. Gerenciar somente "emissão" RRs CAA é muito mais simples:

generic
yourdomain CAA 0 issue "digicert.com"
  1. Crie uma“emissão” CAA RR e um “issuewild”para DigiCert

    Se as políticas da sua organização o permitirem, e você deve criar RRs CAA “issuewild” para yourdomain, então crie duas regras:

generic
yourdomain CAA 0 issue "digicert.com"
yourdomain CAA 0 issuewild "digicert.com"
  1. Fale conosco

    Se as políticas da sua organização impedirem que você autorize a DigiCert a emitir certificados não curinga para o seu domínio,fale conosco, e trabalharemos com você para encontrar uma solução para o problema, para que possamos emitir seu certificado curinga.

Indevidamente usando o"issuewild" propriedade

Quando não usada corretamente, a propriedade "issuewild" pode efetivamente impedir que CAs emitam os certificados necessários para um domínio. Ao processar pedidos de certificado, as CAs ignoram todos os RRs CAA com a tag de propriedade "issuewild" , a menos que (1) a CA esteja processando um pedido para um certificado curinga ou (2) uma tag "issuewild" seja o único RR CAA para o domínio.

  1. A CA processa o pedido do certificado curinga

    Ao criar um único registro "issuewild" para seu domínio (yourdomain CAA 0 issuewild "digicert.com"), você efetivamente exclui todas as outras autoridades de certificação sem um registro "issuewild" de emitir um certificado curinga para esse domínio. Se esse não foi o seu objetivo ao criar o registro, será necessário criar um registro "issuewild" adicional para cada CA que você deseja autorizar a emitir certificados curinga para yourdomain.

  2. "issuewild" RR CAA – único tipo de registro criado para o domínio

    Quando você solicita um certificado que não seja curinga para o seu domínio, a CA ignorará quaisquer RRs de CAA "issuewild", a menos que o RR de CAA "issuewild" seja o único tipo de registro encontrado. Quando isso acontece, uma CA não pode emitir um certificado não curinga para seu domínio.

    O motivo básico para usar os RRs da CAA é criar políticas de emissão de certificados para um domínio. Ao criar um único registro "issuewild" para o seu domínio (yourdomain CAA 0 issuewild "digicert.com"), sem nenhum registro de "emissão" associado, você está dizendo duas coisas:

    1. Você autoriza essa CA (e somente essa CA) a emitir certificados curinga para yourdomain.
    2. Você não deseja que nenhuma autoridade de certificação emita certificados não curinga para yourdomain.
      É assim que os RRs CAA funcionam e deve ser sua intenção quando você cria apenas emitir RRs CAA "issuewild" para yourdomain.com.

    Ao criar esse primeiro RR CAA "issuewild"para um domínio, é importante entender que agora você deve criar uma política (RR CAA) para os dois tipos de autorização de certificado SSL/TLS (sem curinga e curinga) no futuro.

Como o RR CAA e CNAME funcionam juntos

Quando você solicita um certificado SSL/TLS para um domínio (por exemplo, my.blog.example.com) que contém um registro CNAME apontando para outro domínio (por exemplo, my.blog.example.net), a Autoridade de Certificação (CA) segue um processo específico (estabelecido nos Requisitos da linha de base[BRs]) para localizar RR CAA as autorizando a emitir seu certificado.

CNAME destinos

Como medida preventiva contra ataques de exaustão de recursos, uma CA é necessária apenas para acompanhar até 8 destinos CNAME (8 ou menos registros CNAME: blog.example.com é um CNAME para blog.example.net que é um CNAME para blog.example.org e assim por diante em 8 níveis).

O processo inicia no nome de domínio na solicitação de certificado e continua no domínio de nível superior. O processo será interrompido a qualquer momento, se forem encontrados RRs da CAA. Os RRs da CAA determinam se a CA está autorizada a emitir seu certificado.

Exemplo de fluxo de trabalho de verificação RR CAA com CNAME presente

Para ver a versão maior do diagrama, clique aqui.

Etapa 1: A CA verifica os RRs da CAA quanto ao nome de domínio na solicitação de certificado–my.blog.example.com.

Se a CA encontrar um registro CAA para o domínio na solicitação de certificado, a pesquisa será interrompida. A CA verifica se há um registro CAA que a autoriza a emitir o seu certificado. Se encontrar o registro, a CA emite o certificado. Se não encontrar o registro, a CA não pode emitir o certificado.

Se a CA não encontrar um registro CAA para o domínio na solicitação de certificado, a pesquisa por registro CAA continua.

Etapa 2: A CA verifica os RRs da CAA para o domínio de destino CNAME - my.blog.example.net.

Se a CA encontrar um registro CAA para o domínio de destino CNAME, a pesquisa será interrompida. A CA verifica se há um registro CAA que a autoriza a emitir o seu certificado. Se encontrar o registro, a CA emite o certificado. Se não encontrar o registro, a CA não pode emitir o certificado.

Se a CA não encontrar um registro CAA para o domínio de destino CNAME, a pesquisa por registro CAA continua.

Etapa 3: A CA verifica os RRs da CAA para o domínio principal do domínio original–blog.example.com.

Se a CA encontrar um registro CAA para o domínio principal do domínio original, a pesquisa será interrompida. A CA verifica se há um registro CAA que a autoriza a emitir o seu certificado. Se encontrar o registro, a CA emite o certificado. Se não encontrar o registro, a CA não pode emitir o certificado.

Se a CA não encontrar um registro CAA para o domínio principal do domínio original, a pesquisa do registro CAA continua.

Etapa 4: A CA verifica os RRs da CAA para o domínio base do domínio original–example.com.

Se a CA encontrar um registro CAA para o domínio base do domínio original, a pesquisa será interrompida. A CA verifica se há um registro CAA que a autoriza a emitir o seu certificado. Se encontrar o registro, a CA emite o certificado. Se não encontrar o registro, a CA não pode emitir o certificado.

Se a CA não encontrar um registro CAA para o domínio base do domínio original, a pesquisa do registro CAA continua.

Etapa 5: A CA verifica os RRs da CAA para o domínio de nível superior do domínio original–com.

Se a CA encontrar um registro CAA para o domínio de nível superior do domínio original, a pesquisa será interrompida. A CA verifica se há um registro CAA que a autoriza a emitir o seu certificado. Se encontrar o registro, a CA emite o certificado. Se não encontrar o registro, a CA não pode emitir o certificado.

Se a CA não encontrar um registro CAA para o domínio de nível superior do domínio original, a CAA emite o certificado.

Informações adicionais: