Analisador de CSR

Por que analisar um CSR antes de enviá-lo?

Um decodificador de CSR mostra campos. Ele responde a "o que está neste arquivo", nunca à pergunta que se coloca antes de pagar um certificado: a minha autoridade certificadora vai aceitá-lo e, se não, por quê.

A diferença é mensurável. Um Common Name ausente dos SAN, um wildcard colocado sobre *.co.uk, um underscore em um nome DNS, um nome em .local, um endereço IP privado nos SAN, ou nenhum SAN: são todos pedidos que uma autoridade pública recusa e que os decodificadores do mercado mostram sem dizer uma palavra.

Este analisador decodifica o CSR integralmente e depois confronta cada dado medido com os CA/Browser Forum Baseline Requirements e com os RFC aplicáveis. Ele emite um veredicto de três estados, conforme, aviso ou não conforme, com as constatações e a respectiva fonte. O catálogo tem 58 códigos; o número de controles executados depende do CSR analisado.

Três usos que se repetem:

• Antes do envio: corrigir os pontos bloqueantes e enviar apenas uma vez o CSR certo.
• No recebimento do certificado: verificar que ele vem mesmo desse CSR, com a impressão digital de chave pública como prova.
• Ao retomar uma PKI herdada: localizar nomes internos, chaves curtas e campos proibidos.

O que contém um CSR

Um Certificate Signing Request é um objeto ASN.1 definido pelo RFC 2986, codificado em DER e depois transportado em base64 dentro de um envelope PEM. Ele contém três coisas:

• uma chave pública, RSA ou de curva elíptica, e só ela;
• identificadores pedidos: o sujeito (CN, O, L, ST, C) e, dentro de um atributo PKCS#9 chamado extensionRequest, as extensões pretendidas, entre elas os SAN;
• uma assinatura produzida com a chave privada correspondente.

Os SAN não são, portanto, um campo de primeiro nível: eles viajam dentro de um atributo. É isso que explica que uma configuração openssl incompleta produza um CSR sem um único SAN sem que nada proteste.

O que a sua autoridade certificadora faz realmente com o CSR

Este é o ponto que quase todos os decodificadores ignoram: a autoridade reconstrói o certificado, ela não copia o CSR. Ela gera por conta própria o authorityInformationAccess, o authorityKeyIdentifier, as certificatePolicies, o extKeyUsage e até o subjectAltName do certificado emitido. Um único campo é retomado byte a byte: o SubjectPublicKeyInfo, a sua chave pública e o respectivo identificador de algoritmo.

É isso que dita a gravidade de cada constatação, e é a calibração central da ferramenta. Um conteúdo só se torna bloqueante se tornar impossível um certificado conforme: chave fora do perfil, chave comprometida, identificador ilícito, ou violação do RFC 2986 pelo próprio CSR. Tudo o que a autoridade sobrescreve ou ignora, uma unidade organizacional ou uma extensão exótica, fica no máximo em aviso.

O que a assinatura prova e o que não prova

A assinatura de um CSR estabelece uma coisa: no momento da criação, o autor detinha a chave privada associada à chave pública, e o trio sujeito, chave e atributos não se moveu desde então. Ela não prova nenhum controle do domínio, nenhuma autoridade do requerente, nenhuma garantia de atualidade (o PKCS#10 não leva marca temporal) nem nenhuma exclusividade: a chave pode estar esquecida em um repositório público.

Uma assinatura inválida não interrompe, portanto, a análise; ela é uma constatação entre outras, e a causa muitas vezes é benigna: truncamento ao copiar e colar, CSR recodificado pelo painel de uma hospedagem. A ferramenta distingue três estados e não dois, válida, inválida e não verificável; ela nunca acusa de adulteração um CSR que não conseguiu verificar.

As recusas que uma simples decodificação não vê

O CN precisa constar nos SAN

O Common Name é facultativo e desaconselhado nos perfis atuais. Mas se estiver presente, ele precisa reproduzir exatamente um dos valores do subjectAltName: um CN que não aparece em nenhum dos SAN torna o certificado não conforme.

O caso análogo é ainda mais comum, o CSR sem nenhum SAN. Com um CN, ele depende de uma reconstrução benevolente por parte da autoridade, o que deve ser evitado. Sem CN nem SAN, a autoridade não tem nada para validar e a recusa é certa.

As duas camadas de regras sobre os wildcards

A camada sintática vem do RFC 9525: um único wildcard, conteúdo exclusivo do rótulo mais à esquerda. *.captaindns.com é válido; *.*.captaindns.com e www*.captaindns.com não são, e um cliente conforme deve ignorar o nome. O certificado seria emitido e depois ficaria inutilizável.

A camada política vem dos Baseline Requirements: uma autoridade deve recusar um wildcard colocado sobre um sufixo público da seção ICANN, *.co.uk por exemplo. Na seção privada da mesma lista, a recusa é apenas uma recomendação, daí um simples aviso.

Lembrete muitas vezes esquecido: um wildcard só desce um nível. *.captaindns.com não cobre nem captaindns.com nem a.b.captaindns.com.

Os nomes internos deixaram de poder ser emitidos em 2015

servidor.local, intranet.corp, nas.lan, localhost, um rótulo único sem ponto, ou um TLD ausente da zona raiz: são nomes internos. A emissão deles está proibida desde 1º de novembro de 2015 e os certificados existentes foram revogados à força em 1º de outubro de 2016. Mesmo assim, eles continuam aparecendo em CSR oriundos de antigas PKI internas, reciclados para uma autoridade pública.

Mesma lógica para os endereços IP reservados nos SAN, sejam eles do RFC 1918, de loopback, de link local, de CGNAT ou ULA: uma autoridade não valida o que não consegue alcançar. Novidade: desde 15 de março de 2026, um nome terminado em .in-addr.arpa ou .ip6.arpa também está proibido.

A unidade organizacional desapareceu dos certificados

O campo organizationalUnit está proibido desde 1º de setembro de 2022, em aplicação do ballot SC047v2 adotado em 29 de junho de 2021; a referência corrente ao "ballot SC62" é inexata. A autoridade não recusa o CSR por causa disso, ela remove o campo, daí um aviso.

Um endereço de email no sujeito é considerado obsoleto pelo RFC 5280 e não tem nenhum destino legítimo em um certificado TLS de servidor. E um ponto contraintuitivo: um sujeito vazio é conforme, e até moderno. O perfil de validação de domínio só aceita o país, facultativo, e o Common Name, desaconselhado.

Tamanhos de chave, algoritmos e chaves já comprometidas

RSA 2048 continua conforme: 3072 bits é uma recomendação com horizonte 2030, assinalada a título informativo. Uma assinatura em SHA-1 não é bloqueante no sentido dos Baseline Requirements, cuja cláusula anti-SHA-1 visa os objetos assinados por uma autoridade e não pelo subscritor; ela é classificada como aviso, com a nuance de que na prática as autoridades a recusam desde 2016.

Dois controles vão mais longe. São os únicos pontos dos Baseline Requirements onde está escrito que a autoridade deve rejeitar o pedido:

• ROCA (CVE-2017-15361): as chaves RSA produzidas por uma biblioteca muito difundida nos cartões inteligentes e nos TPM têm uma estrutura reconhecível que faz ruir a entropia delas. A detecção não fatoriza nada, é um teste de impressão digital sobre o modulus.
• Chaves fracas Debian (CVE-2008-0166): entre setembro de 2006 e maio de 2008, um gerador de números aleatórios defeituoso reduziu o espaço das chaves a algumas dezenas de milhares de valores por tamanho. A lista está integrada no serviço e é consultada offline.

Nos dois casos, é preciso regenerar o par de chaves por inteiro: reutilizar a mesma chave em um novo CSR arrastaria a fraqueza.

A impressão digital SPKI, aquela que emparelha todo o resto

Todos os decodificadores mostram uma "impressão digital" do CSR. É o hash do arquivo inteiro: ele muda se você regenerar o CSR com a mesma chave, e não tem nenhuma relação com o certificado que você vai receber.

A impressão digital que serve é a do SubjectPublicKeyInfo, definida pelo RFC 7469: o hash SHA-256 da estrutura de chave pública codificada em DER. Como é o único campo copiado byte a byte, o mesmo valor se encontra no CSR, no certificado emitido e na chave privada correspondente, e sobrevive a uma reemissão.

Três usos imediatos: emparelhar um certificado recebido com o seu CSR, sem comparar sujeitos que a autoridade reescreveu de qualquer forma; verificar localmente que a sua chave privada é a correta, com o comando indicado mais abaixo; compor um registro DANE 3 1 1, cujo seletor 1 é exatamente essa impressão digital, que o verificador DANE/TLSA controla depois no DNS. A impressão digital é publicada em hexadecimal e em base64.

Comparar o CSR com o certificado em produção

Opção facultativa, desmarcada por padrão: indique um host e o analisador recupera o certificado que ele serve realmente, e depois compara as duas impressões digitais SPKI. Três casos, mesma chave, outra chave, ou host inacessível, sendo este último o mais frequente já que um CSR se analisa antes da emissão.

É o único caminho de rede da ferramenta: caixa desmarcada, nenhuma conexão de saída. O resultado nunca entra no veredicto de conformidade, porque o que está em produção em outro lugar nada diz sobre a validade de um pedido, e nada do CSR é transmitido ao host.

Para julgar o próprio certificado em produção, cadeia de confiança e prazo de validade incluídos, a ferramenta dedicada é o SSL Certificate Checker. Depois vem a gestão do ciclo de vida dos certificados, ainda mais porque a duração de validade cai para 47 dias até 2029.

Comandos openssl úteis

Arquivo san.cnf, sem o qual o openssl produz um CSR sem nenhum SAN:

[ req ]
prompt = no
distinguished_name = dn
req_extensions = v3_req
[ dn ]
CN = www.captaindns.com
[ v3_req ]
subjectAltName = @alt
[ alt ]
DNS.1 = www.captaindns.com
DNS.2 = captaindns.com

# RSA 3072
openssl req -new -newkey rsa:3072 -nodes -keyout captaindns.key -out captaindns.csr -config san.cnf

# ECDSA P-256
openssl ecparam -name prime256v1 -genkey -noout -out captaindns.key
openssl req -new -key captaindns.key -out captaindns.csr -config san.cnf

Calcular a impressão digital SPKI do CSR, do certificado recebido e da chave privada, e depois verificar que as três coincidem, sem enviar nada para lugar nenhum:

openssl req  -in captaindns.csr -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
openssl x509 -in captaindns.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
openssl pkey -in captaindns.key -pubout       | openssl pkey -pubin -outform DER | openssl dgst -sha256

Para um domínio internacionalizado, escreva a forma punycode (prefixo xn--) nos SAN: o analisador mostra a forma Unicode ao lado e nunca invalida um rótulo xn-- correto.

Confidencialidade

Nunca cole a sua chave privada, aqui ou em qualquer outro lugar: um CSR contém apenas a chave pública. Um cabeçalho PEM de chave privada é detectado antes de qualquer envio e a análise é recusada de imediato. Se a chave já foi colada em um formulário web, considere-a comprometida e regenere o par.

O CSR, por sua vez, não é um segredo: ele contém identificadores destinados a figurar em um certificado, publicado em seguida nos registros de Certificate Transparency. Ele é processado em memória para ser analisado e apresentado. Única exceção, o valor do atributo challengePassword nunca é devolvido, nem apresentado, nem registrado: apenas a presença dele é assinalada.

FAQ - Perguntas frequentes

P: O que é um CSR (Certificate Signing Request)?

R: Um arquivo PKCS#10, transportado em PEM, que contém a sua chave pública, os identificadores pedidos (sujeito e SAN) e uma assinatura produzida com a chave privada correspondente. Nunca contém a chave privada. Você o envia para uma autoridade certificadora, que verifica o seu controle dos domínios e depois emite o certificado.

P: Por que uma autoridade certificadora recusa um CSR?

R: Na maioria das vezes um Common Name ausente dos SAN, um wildcard malformado ou colocado sobre um sufixo público, um caractere ilegal em um nome DNS (o underscore em primeiro lugar), um nome interno em .local ou .corp, um endereço IP privado nos SAN, uma chave abaixo de 2048 bits, ou a ausência total de SAN.

P: O Common Name precisa constar nos SAN?

R: Sim, a partir do momento em que está presente: os Baseline Requirements impõem que ele reproduza exatamente um dos valores do subjectAltName. O mais simples é não preencher, já que os navegadores leem apenas os SAN há anos.

P: O meu CSR está assinado em SHA-1, isso é bloqueante?

R: Não no sentido dos Baseline Requirements: a cláusula que proíbe SHA-1 visa os objetos assinados com a chave privada de uma autoridade, ao passo que um CSR é assinado pelo subscritor. A ferramenta o classifica como aviso. Na prática, as autoridades públicas recusam os CSR em SHA-1 desde 2016, por isso regenere-o em SHA-256. MD5 e MD2 são bloqueantes.

P: É preciso preencher os campos O, OU, L e ST do sujeito?

R: Não para um certificado de validação de domínio: o perfil só aceita o país, facultativo, e o Common Name, desaconselhado. Um sujeito vazio é perfeitamente conforme. A unidade organizacional está inclusive proibida desde 1º de setembro de 2022.

P: Para que serve a impressão digital SPKI?

R: É o hash SHA-256 da estrutura de chave pública, o único campo que uma autoridade copia byte a byte do CSR para o certificado. Prova que um CSR, um certificado recebido e uma chave privada contêm a mesma chave, e serve de seletor 1 em um registro DANE TLSA. A impressão digital publicada pelos outros decodificadores incide sobre o arquivo inteiro e não permite nenhuma dessas comparações.

P: O certificado já em produção corresponde ao meu CSR?

R: Marque a opção de comparação e indique o host. O analisador recupera o certificado servido e compara a impressão digital SPKI dele com a do CSR: mesma chave, outra chave, ou host inacessível. Essa comparação nunca influencia o veredicto de conformidade e não transmite nada do CSR ao host consultado.

P: Como gerar um CSR com SAN usando o openssl?

R: Crie um arquivo de configuração que liste DNS.1, DNS.2, etc., e depois execute openssl req -new -newkey rsa:3072 -nodes -keyout captaindns.key -out captaindns.csr -config san.cnf. Para uma chave elíptica, gere primeiro a chave com openssl ecparam -name prime256v1 -genkey -noout e depois chame openssl req -new -key. Sem esse arquivo, o openssl produz um CSR sem nenhum SAN.

Ferramentas complementares

Recursos úteis

• RFC 2986 - sintaxe de pedido de certificação (estrutura PKCS#10 do CSR)
• RFC 9525 - verificação da identidade de serviço (regras de wildcard, substitui o RFC 6125)
• RFC 7469 - pinning de chave pública (definição normativa da impressão digital SPKI)
• CA/Browser Forum - Baseline Requirements (regras de emissão dos certificados TLS)