Visualizador CSR

O Visualizador de CSR analisa Certificate Signing Requests codificadas em PEM e exibe todas as informações que aparecerão no certificado resultante -- campos de subject, SANs, detalhes de chave pública e algoritmo de assinatura -- para que você possa detectar erros antes de submeter para uma Certificate Authority. Cole um CSR começando com -----BEGIN CERTIFICATE REQUEST----- e instantaneamente revise cada campo.

Compreendendo Certificate Signing Requests

Um Certificate Signing Request é a aplicação formal que você envia a uma Certificate Authority quando precisa um novo certificado. Contém sua informação de identidade (nome de domínio, detalhes de organização), sua chave pública, e uma lista de extensões solicitadas como Subject Alternative Names. O CSR é assinado com sua chave privada para provar que você possui o par de chaves correspondente. A CA revisa essa informação, verifica sua identidade através de validação de domínio ou validação de organização, e emite um certificado baseado no conteúdo do CSR.

A coisa crítica de compreender é que uma vez um certificado é emitido, consertar erros é caro. Se você submeteu um CSR com um typo no Common Name, uma entrada SAN faltando ou o algoritmo de chave errado, você terá que gerar um novo CSR, resubmeter e esperar pela CA processar novamente. Para certificados Domain Validation através de Let's Encrypt, isso é um inconveniente menor. Para certificados Organization Validation ou Extended Validation de CAs comerciais, reemissão pode levar dias e pode envolver taxas adicionais. Verificar o CSR antes de submissão sempre vale os trinta segundos que leva.

Esse visualizador decodifica o CSR e apresenta cada campo em formato legível para humanos. Você pode verificar que o Common Name combina seu domínio pretendido, que todos os Subject Alternative Names estão presentes e corretamente digitados, que o algoritmo de chave e tamanho atendem seus requisitos, e que o algoritmo de assinatura é atual. O visualizador também sinaliza problemas potenciais como tamanhos de chave fracos, algoritmos deprecados, ou entradas SAN faltando que poderiam causar problemas durante emissão.

Como Visualizar um Certificate Signing Request

1. Cole seu CSR codificado em PEM (começando com -----BEGIN CERTIFICATE REQUEST-----)
2. O visualizador extrai e exibe todos os campos de CSR
3. Revise detalhes de subject, SANs, informação de chave e quaisquer avisos de validação
4. Verifique acurácia antes de submeter o CSR para sua CA

Exemplo de Saída de CSR

Colando um CSR multi-domínio típico:

Subject:
  Common Name (CN):  www.example.com
  Organization (O):  Example Inc.
  Locality (L):      San Francisco
  State (ST):        California
  Country (C):       US

SANs Solicitados:
  DNS: www.example.com
  DNS: example.com
  DNS: api.example.com
  DNS: cdn.example.com

Chave Pública:
  Algorithm:  RSA
  Key Size:   2048 bits

Assinatura:
  Algorithm:  SHA-256 with RSA

Verificações de Validação de Chave

O visualizador sinaliza problemas potenciais automaticamente:

Quando Usar Esta Ferramenta

• Verificação de pré-submissão -- revise um CSR antes de enviá-lo para uma Certificate Authority, especialmente para certificados caros EV (Extended Validation) ou OV (Organization Validation) onde reemissão custa tempo e dinheiro
• Auditoria automática de CSR -- verifique que CSRs gerados por clientes ACME, Terraform, Ansible ou outras ferramentas de automação contêm domínios e detalhes de organização corretos
• Depurando falhas de emissão de certificado -- quando uma CA rejeita um CSR, inspecione-o para identificar chaves fracas, campos faltando ou problemas de formatação
• Revisão de equipe -- audite CSRs criados por outros membros da equipe antes deles serem submetidos, assegurando convenções de nomeação e cobertura de domínio corretas
• Comparando CSR com certificado emitido -- verifique que a CA emitiu um certificado combinando o que foi solicitado
• Verificação de algoritmo de chave -- confirme se um CSR usa RSA ou ECDSA antes de submeter, especialmente ao migrar tipos de chave

Como Certificate Signing Requests Funcionam

Um CSR é uma mensagem enviada de um solicitante a uma Certificate Authority para aplicar para um certificado de identidade digital. O CSR contém:

1. Subject Distinguished Name -- identifica quem está solicitando o certificado (campos CN, O, OU, L, ST, C)
2. Chave pública -- a chave pública do solicitante que será embarcada no certificado
3. Extensões solicitadas -- atributos adicionais como Subject Alternative Names
4. Assinatura -- o CSR é assinado com a chave privada do solicitante, provando que ele possui o par de chaves correspondente

Gerando um CSR com OpenSSL

Um comando típico de geração de CSR:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -subj "/C=US/ST=California/L=San Francisco/O=Example Inc./CN=www.example.com"

Para CSRs com SANs, você precisa de um arquivo de configuração OpenSSL especificando a extensão subjectAltName ou use a flag -addext:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -subj "/CN=www.example.com" \
  -addext "subjectAltName=DNS:www.example.com,DNS:example.com"

CSR vs. Certificado

Melhores Práticas de Revisão de CSR

O erro mais comum e singular em CSR é esquecer de incluir o Common Name nos Subject Alternative Names. Desde Chrome 58 (lançado em 2017), navegadores ignoram o campo CN inteiramente para validação de hostname e apenas verificam SANs. Se seu CSR tem CN=www.example.com mas nenhuma entrada SAN DNS:www.example.com, o certificado emitido produzirá erros de hostname mismatch em todo navegador moderno. Sempre certifique-se de que todo domínio que deveria ser coberto aparece como uma entrada SAN, incluindo o próprio CN.

Outro problema frequente é gerar um CSR com uma chave muito pequena. CAs não emitirão certificados para chaves RSA menores que 2048 bits, e alguns frameworks de conformidade requerem RSA de 4096 bits ou ECDSA P-384. Se suas ferramentas de automação têm tamanhos de chave padrão, verifique-os antes de fazer deploy em produção. Regenerar um CSR com uma chave maior é simples; descobrir o problema após o certificado ter sido emitido e feito deploy não é.

Para equipes usando ferramentas infrastructure-as-code como Terraform ou Ansible para gerar CSRs, construa um passo de verificação em seu pipeline. Tenha o CSR analisado e validado automaticamente antes dele ser submetido à CA. Isso detecta drift de configuração, substituições de variáveis incorretas e erros de template que resultariam em certificados com domínios errados ou SANs faltando. Uma verificação simples de uma linha que valida a lista de CN e SAN do CSR combina com os valores esperados pode economizar horas de troubleshooting.

Perguntas Frequentes

Uma CA pode mudar o que está em meu CSR? Sim. A CA controla o que entra no certificado final. Para certificados DV, CAs tipicamente removem campos de organização e apenas mantêm o CN e SANs. Para certificados OV/EV, a CA verifica e pode ajustar detalhes de organização. A CA sempre define o período de validade, número serial e campos de issuer. Revisar ambos seu CSR e o certificado emitido é boa prática.

Por que meu CSR mostra SHA-256 com RSA mas gerei com uma chave ECDSA? O algoritmo de assinatura no CSR reflete como o próprio CSR foi assinado, que depende de seu tipo de chave. Uma chave ECDSA produz ecdsa-with-SHA256 ou similar. Se você vê sha256WithRSAEncryption, sua chave é RSA. Verifique a seção Chave Pública para confirmar que o algoritmo e tamanho de chave combinam suas expectativas.

Preciso incluir SANs no CSR ou a CA pode adicioná-los? Isso depende da CA. A maioria das CAs modernas permite que você especifique SANs durante o processo de ordenação, mesmo que não estejam no CSR. No entanto, incluir SANs no CSR é boa prática porque documenta sua intenção e é requerido por algumas CAs. Sempre verifique que o certificado emitido inclui todos os SANs esperados.

Como verifico que um CSR e uma chave privada combinam? Extraia a chave pública de ambos o CSR e a chave privada, então compare. Com OpenSSL: openssl req -in csr.pem -noout -pubkey e openssl pkey -in key.pem -pubout. Se a saída é idêntica, o CSR foi gerado com aquela chave privada. O Extrator de Chave Pública também pode ajudar com essa comparação.

Qual é a diferença entre PKCS#10 e um Certificate Signing Request? Eles são a mesma coisa. PKCS#10 (RFC 2986) é o padrão formal que define o formato CSR. Quando ferramentas referem a uma "requisição PKCS#10" ou um "CSR", significam a mesma estrutura de dados. O cabeçalho PEM -----BEGIN CERTIFICATE REQUEST----- é usado para CSRs PKCS#10.

Posso reutilizar um CSR depois que o certificado expira? Tecnicamente sim, se você ainda tem a chave privada correspondente. No entanto, boa prática é gerar um novo par de chaves e CSR para cada renovação. Isso limita a janela de exposição se a chave privada foi comprometida em algum ponto durante a lifetime do certificado anterior.

Ferramentas Relacionadas

• Visualizador de Certificado X.509 - Visualize o certificado emitido para comparar contra o CSR original
• Extrator de Chave Pública - Extraia a chave pública de ambos CSR e certificado para verificar que combinam
• Extrator de SAN - Extraia SANs do certificado emitido para confirmar que todos domínios solicitados estão cobertos
• Gerador de Fingerprint de Certificado - Gere fingerprints para o certificado emitido
• Verificador de Expiração de Certificado - Verifique o período de validade do certificado emitido