Decodificador de CSR (Certificate Signing Request)

Cole um CSR (Certificate Signing Request) em formato PEM e veja instantaneamente o CN, SAN, nome da organização e algoritmo de chave pública solicitados, antes de enviar à autoridade certificadora. Ferramenta gratuita para detectar erros de digitação antecipadamente.

O que é o Decodificador de CSR

O Decodificador de CSR é uma ferramenta gratuita que permite colar um CSR (Certificate Signing Request, ou requisição de assinatura de certificado) em formato PEM e visualizar imediatamente o Subject solicitado (CN, nome da organização e demais campos), o SAN (Subject Alternative Name), o algoritmo de chave pública e o algoritmo de assinatura. Assim, antes de enviar o CSR a uma autoridade certificadora (CA), você pode confirmar na hora se as informações preenchidas correspondem exatamente ao que pretendia solicitar, evitando retrabalho e atrasos na emissão.

Enquanto a ferramenta irmã "Decodificador de certificados X.509" (dev.server.x509_decoder) foi pensada para analisar certificados já emitidos, este Decodificador de CSR trabalha com uma etapa anterior: o próprio pedido, antes de passar pela análise e emissão da CA. É especialmente útil quando o certificado ainda não foi emitido, ou como conferência final antes de gerar um novo par de chaves privada/pública.

Como usar o Decodificador de CSR

Cole o CSR em formato PEM Copie o texto completo que começa com "-----BEGIN CERTIFICATE REQUEST-----" e cole diretamente no campo de entrada, sem remover as linhas de início e fim.
É possível colar vários CSRs de uma vez Se você colar vários blocos de CSR juntos, a ferramenta detecta automaticamente cada um deles separadamente, sem necessidade de dividir o texto manualmente.
Clique em "Analisar" Confira quantos CSRs foram detectados e, em seguida, clique no botão para que a análise seja processada no servidor.
Confira o resultado O Subject, o SAN, o algoritmo de chave pública e demais campos solicitados aparecem listados de forma organizada para conferência rápida.

Dicas para aproveitar melhor

Antes de enviar o CSR, confirme se tanto o CN (Common Name) quanto o SAN incluem todos os nomes de host que você realmente pretende ter no certificado emitido. Um SAN incompleto costuma exigir uma nova solicitação e atrasar todo o processo.
Aproveite este momento para verificar se o algoritmo de chave pública não está usando RSA com menos de 2048 bits, ou uma curva elíptica já considerada obsoleta. Isso reduz bastante o risco de a CA recusar o pedido durante a análise.
Antes de reutilizar o mesmo CSR em vários servidores, reconfirme se o nome da organização e o domínio informados no Subject e no SAN correspondem de fato ao que está sendo solicitado naquele momento.
Lembre-se de que esta ferramenta mostra apenas o que foi solicitado no CSR. O conjunto de SANs efetivamente emitido pode variar de acordo com o resultado da análise feita pela autoridade certificadora.

Quando usar esta ferramenta

Conferência final antes do envio à CA

Antes de comprar um certificado SSL pago, confirme se o CN e o SAN preenchidos no momento da geração do CSR estão corretos.

Validação do processo interno de geração de CSR

Mesmo quem não está familiarizado com a linha de comando pode conferir visualmente se um CSR gerado com openssl req, ou ferramenta equivalente, contém exatamente os dados esperados.

Revisão de um CSR solicitado anteriormente

Reexamine com segurança o conteúdo de um CSR guardado em arquivo, sem nunca precisar manipular a chave privada correspondente.

Checagem de SANs ausentes em certificados multidomínio

Ao solicitar um único certificado que cubra vários nomes de host, use a ferramenta para identificar antecipadamente qualquer SAN que tenha ficado de fora do pedido.

Glossário

CSR (Certificate Signing Request): Sigla para Certificate Signing Request, ou requisição de assinatura de certificado. É o conjunto de dados enviado a uma CA para solicitar a emissão de um certificado, reunindo a chave pública e as informações do pedido, como Subject e SAN.
CA (Certificate Authority): Sigla para Certificate Authority, ou autoridade certificadora. É a entidade terceira responsável por analisar o conteúdo do CSR e, em seguida, emitir o certificado SSL/TLS propriamente dito.
CN (Common Name): Campo do Subject que representa o principal nome de host ou serviço coberto pelo certificado. No passado, os navegadores validavam apenas o CN, mas hoje o SAN tem prioridade nessa verificação.
SAN (Subject Alternative Name): Campo de extensão que lista nomes de host ou endereços IP adicionais para os quais o certificado também é válido. Na etapa do CSR, ele aparece registrado dentro das chamadas "Requested Extensions" (extensões solicitadas).
Requested Extensions: Conjunto de atributos com os quais o solicitante do CSR pede que determinadas extensões, como o SAN, sejam incluídas no certificado final. A CA não é obrigada a reproduzir esses valores exatamente como foram solicitados.
Algoritmo de chave pública: Método usado para gerar a chave pública incluída no CSR. Os mais comuns são RSA e EC (criptografia de curva elíptica), cuja força de segurança varia conforme o comprimento da chave ou a curva escolhida.

Perguntas frequentes

O CSR é enviado ao servidor uma única vez, apenas para ser analisado, e não é armazenado nem registrado permanentemente em logs. Embora o CSR não contenha a chave privada, evite colar solicitações cujo conteúdo você prefira manter em sigilo.

Não. Esta ferramenta aceita exclusivamente arquivos CSR que comecem com "-----BEGIN CERTIFICATE REQUEST-----". Nunca cole uma chave privada em nenhuma ferramenta on-line, seja qual for.

As causas mais comuns são: as linhas BEGIN/END estão ausentes, o trecho em Base64 está corrompido, ou o texto colado é na verdade um certificado já emitido ou uma chave privada, e não um CSR.

O Decodificador de certificados X.509 analisa certificados que já foram emitidos pela CA. Já este Decodificador de CSR analisa o próprio pedido, antes de chegar à CA. Por isso, informações como data de validade e fingerprint não aparecem aqui, pois simplesmente não existem em um CSR.

Na maioria dos casos sim, mas a decisão final cabe à análise da autoridade certificadora. Algumas CAs chegam a ignorar o SAN informado no CSR e priorizam o que foi indicado posteriormente em um formulário web no momento do pedido.

Curiosidade — por que o CSR contém uma "assinatura"

Ao examinar com atenção o conteúdo de um CSR, é possível notar que, logo após o Subject e as informações da chave pública, ficam armazenados também um algoritmo de assinatura e o próprio valor da assinatura. À primeira vista, isso pode parecer estranho: por que um documento cujo propósito é pedir a uma CA "por favor, me certifique" já viria com uma assinatura própria? A resposta está no conceito de Proof of Possession, ou prova de posse da chave privada. Ao assinar todo o conteúdo do CSR (Subject, chave pública e demais dados) usando justamente a chave privada correspondente à chave pública declarada no próprio CSR, o solicitante demonstra à CA que realmente possui a chave privada associada àquela chave pública. Se alguém tentasse montar um CSR incluindo a chave pública de outra pessoa, não conseguiria gerar uma assinatura válida sem ter acesso à chave privada correspondente, o que impede pedidos fraudulentos em nome de terceiros.

O mecanismo do CSR foi definido em 1986 como parte do PKCS (Public-Key Cryptography Standards), a família de padrões de criptografia de chave pública desenvolvida pela RSA, especificamente como o PKCS#10. Atualmente, o IETF redefine essa especificação como a RFC 2986, mas, na prática do dia a dia, o nome PKCS#10 continua sendo amplamente utilizado. É um elemento discreto dentro do universo dos certificados TLS, mas funciona como o ponto de partida indispensável de todo o fluxo de emissão de certificados.

A padronização de incluir o SAN dentro das Requested Extensions do CSR é, na verdade, relativamente recente. O padrão original do CSR (PKCS#10) previa pouco mais do que o Subject e o CN, e foi somente com a popularização dos certificados multidomínio e wildcard que cada CA passou a aceitar o SAN por meios próprios e não padronizados. Hoje em dia, ferramentas amplamente usadas, como o openssl, oferecem suporte padrão para incluir o SAN no CSR por meio do mecanismo Extension Request, descrito na RFC 2985, e é justamente dessa posição padrão (o atributo extensionRequest dentro de Attributes) que esta ferramenta extrai o SAN.

Ver todas as curiosidades