Tema

Ferramentas populares

Decodificador de CSR

Cole uma solicitação de assinatura de certificado e leia cada campo que ela contém: o titular, a chave, cada nome alternativo e cada extensão. A página também confere a solicitação com as regras que uma CA pública aplica e diz se a sua chave privada corresponde a ela. Um certificado SSL também é decodificado aqui.

Decodificado no seu navegador com Web Crypto · nada é enviado, nada é guardado · Baseline Requirements do CA/Browser Forum v2.3.1

Decodificado no seu navegador. Nada é enviado, nada é guardado.
Solte o arquivo em qualquer lugar desta página PEM, DER, .csr, .cer, .crt, .pem, .req, .txt

Experimente um

Tudo nesta página acontece no seu navegador. Abra o painel de rede e confira: nenhuma requisição leva os seus dados.

O que é um CSR?

Uma solicitação de assinatura de certificado é um pequeno arquivo assinado que pede um certificado a uma autoridade certificadora. Ela leva a sua chave pública, os nomes que você quer no certificado e uma assinatura feita com a sua chave privada.

O formato é o PKCS#10, descrito na RFC 2986. A parte que é assinada tem apenas quatro coisas: um número de versão, um nome de titular, um SubjectPublicKeyInfo com a sua chave pública e um conjunto de atributos. Tudo isso é então assinado pela chave privada que corresponde à chave pública que está lá dentro, de modo que um CSR é autoassinado. Essa assinatura é a prova de posse: qualquer pessoa pode ler a sua chave pública, mas só quem tem a chave privada consegue assinar uma solicitação que confira com ela.

A sua chave privada não está no arquivo e nunca deve estar. Um CSR é seguro para enviar por e-mail, colar no formulário de uma CA e decodificar aqui — e é por isso que esta página faz todo o trabalho no seu navegador, sem enviar nada a lugar nenhum.

Uma solicitação, byte a byteRFC 2986 · PKCS#10

O arquivo inteiro

  • Invólucro4 bytes
  • A parte que é assinada469 bytes
  • Qual algoritmo de assinatura15 bytes
  • A assinatura em si261 bytes

Dentro da parte que é assinada

  1. Versão3 bytesSempre zero: a única versão que o formato define
  2. Nome do titular108 bytesO nome distinto que você digitou no formulário
  3. Sua chave pública294 bytesAlgoritmo, tamanho e a chave — o único campo que uma autoridade certificadora com certeza usa
  4. Atributos60 bytesPor onde viajam os nomes alternativos que você pediu

Sua chave privadaassina a parte acimaProva de que você tem a chave privada correspondente · A assinatura cobre apenas essa parte, não o arquivo inteiro

A solicitação de exemplo que esta página oferece: 749 bytes no total. Quatro coisas entram na parte que é assinada; a chave privada correspondente à chave pública de dentro assina exatamente essa parte, e o que sai são os últimos 261 bytes.
Decodificador de CSR com uma solicitação decodificada: titular, chave, nomes alternativos e regras da CADecodificador de CSR com uma solicitação decodificada: titular, chave, nomes alternativos e regras da CACole ou solteUm CSR, um certificado ou uma chave pública — PEM, base64, um dump hexadecimal ou um arquivo. Vários de uma vez, sem problema.O vereditoO que uma CA pública faz com esta solicitação: emitir, alterar ou recusar, com o motivo de cada caso.Os nomesCada nome que o certificado cobriria, com o nome comum conferido contra eles.A chave e a assinaturaAlgoritmo, tamanho, curva e expoente, e se a assinatura da própria solicitação confere.Correspondência de chavesAdicione a chave privada ou o certificado emitido para ver se ele pertence a esta solicitação. Nenhum dos dois sai do seu navegador.
Uma solicitação de assinatura de certificado desmontada: o veredito, os nomes que ela pede, a chave por trás dela e um lugar para conferir a sua própria chave. Selecione um número para ver o que cada parte mostra.

Como verificar um CSR antes de enviar

Vale conferir três coisas: se os nomes são os que você queria, se a assinatura confere e se nada nele quebra uma regra que a sua CA aplica.

Cole a solicitação acima. A página lê o titular atributo por atributo, lista cada nome alternativo do titular, mostra o algoritmo e o tamanho da chave e depois confere a assinatura da própria solicitação. Uma solicitação cuja assinatura não confere foi editada, cortada ou corrompida depois de criada — gere-a de novo em vez de enviá-la.

Depois vêm as regras. Uma autoridade certificadora aplica os Baseline Requirements do CA/Browser Forum, e uma solicitação que quebra algum deles é recusada ou alterada em silêncio. Os achados desta página são marcados como causa de rejeição quando a CA não pode emitir o que você pediu, correção automática quando ela emite, mas remove ou altera um campo, e nota quando nada está errado, mas algo merece um olhar.

Três verificações, na ordem em que rodamCA/Browser Forum TLS BR 2.3.1
  1. Os nomesCada nome que o certificado cobriria, e se o nome comum está entre eles
  2. A assinaturaVerificada com a criptografia do próprio navegador
  3. As regras da autoridade certificadoraAplicadas uma a uma, cada uma com o documento de onde vem
  • EnvieNada na solicitação quebra uma regra
  • Será recusadaO arquivo está íntegro; o que ele pede não é permitido
  • Crie de novoUma assinatura que não confere significa que o arquivo foi editado, cortado ou copiado errado depois de criado
As duas primeiras verificações são sobre o arquivo em si e a terceira é sobre o que uma autoridade certificadora permite. Uma solicitação pode passar nas duas primeiras e ainda assim ser recusada.

O que há em um CSR — e o que a sua CA realmente usa

De tudo o que há em um CSR, uma CA pública usa com certeza um campo: a chave pública. A maior parte do resto ela mesma valida, sobrescreve ou está proibida de copiar.

A DigiCert diz isso com clareza na própria documentação: "A DigiCert usa a chave pública incorporada ao CSR para criar o seu certificado de cliente. Todos os outros campos do CSR são ignorados." Em um certificado OV ou EV, a CA precisa validar por conta própria a organização, a localidade e o país antes de incluí-los; o que você digitou não é aceito na confiança. As datas de validade nunca são tiradas de uma solicitação: seguem o cronograma dos Baseline Requirements.

Dois campos do titular não são apenas ignorados, são proibidos. O organizationalUnitName (OU) não pode aparecer em um certificado TLS público — pela votação SC047 do CA/Browser Forum, nenhum certificado emitido desde 1 de setembro de 2022 pode contê-lo — e o emailAddress não é permitido de forma alguma em um certificado com validação de domínio. Um nome comum é permitido, mas desaconselhado, e, se existir, tem de repetir exatamente um dos nomes alternativos do titular. Essa última regra é o motivo de a página sinalizar um nome comum que falta na lista SAN.

O que uma autoridade certificadora faz com cada campoCA/Browser Forum TLS BR 2.3.1
Na sua solicitaçãoO que acontece com elePor quê
Chave públicaSubjectPublicKeyInfoUsado como você enviouA única coisa que uma autoridade certificadora com certeza toma de você
Nomes alternativossubjectAltName2.5.29.17Usado como você enviouA CA confirma que você controla cada nome antes de escrever qualquer um deles
Nome comumCN2.5.4.3Validado e depois escrito pela CADesaconselhado; se existir, tem de repetir exatamente um dos nomes alternativos
Organização, localidade, estadoO, L, ST2.5.4.10Validado e depois escrito pela CAEm um certificado com validação de organização, eles vêm dos registros validados da própria CA, não do que você digitou
PaísC2.5.4.6Validado e depois escrito pela CAPode aparecer, seja qual for o nível de validação
Unidade organizacionalOU2.5.4.11Não é permitido de jeito nenhumProibida em um certificado público desde 1 de setembro de 2022
Endereço de e-mailemailAddress1.2.840.113549.1.9.1Não é permitido de jeito nenhumNão é permitido em um certificado com validação de domínio
Válido de, válido aténotBefore, notAfterNunca vem da solicitaçãoDefinida pelo cronograma que a autoridade certificadora segue, nunca pela sua solicitação

“A DigiCert usa a chave pública incorporada ao CSR para criar o seu certificado de cliente. Todos os outros campos do CSR são ignorados.”

DigiCert, a própria documentação dela
Os campos com que as pessoas se angustiam e quanto cada um realmente vale. Sua chave e seus nomes sobrevivem; a unidade organizacional não pode aparecer de jeito nenhum, e um endereço de e-mail também não em um certificado validado por domínio, seja o que for que você digite; e as datas nunca foram suas para definir.

Por que uma CA rejeita um CSR

Quase toda rejeição se resume a um nome que a CA não pode certificar, um curinga amplo demais, um endereço IP reservado, uma chave pequena demais, um hash de assinatura antigo demais ou uma solicitação cuja assinatura não confere.

Uma autoridade certificadora não pode emitir para um nome interno — um que "não termina com um domínio de nível superior registrado no Root Zone Database da IANA". Isso pega server.local, intranet, um nome de rótulo único sem nenhum ponto e qualquer sufixo inventado. Os rótulos só podem ter letras, dígitos e hifens, então um sublinhado em um nome de host é recusado, e um nome não pode ser escrito com ponto no final. Um curinga só pode substituir o rótulo inteiro mais à esquerda, e nunca um sufixo público: *.example.com pode, *.co.uk não. Um endereço IP pode aparecer, mas não um reservado — nada de 10.0.0.0/8, 192.168.0.0/16, 127.0.0.1 ou fc00::/7.

Quanto às chaves, os Baseline Requirements são exatos: um módulo RSA de pelo menos 2048 bits, divisível por 8, ou um ponto em P-256, P-384 ou P-521, e "nenhum outro algoritmo ou tamanho de chave é permitido". Uma CA também tem de recusar uma chave que consiga fatorar, inclusive uma "que possa ser fatorada em 100 rodadas pelo método de fatoração de Fermat" — esta página executa esse teste na chave da sua solicitação. E embora o hash da assinatura de um CSR não seja o do certificado, a Let's Encrypt deixou de aceitar autoassinaturas SHA-1 em 2022, então uma ferramenta antiga que ainda assina com SHA-1 terá a solicitação recusada.

Nomes que uma autoridade certificadora não vai certificarCA/Browser Forum TLS BR 2.3.1
  • server.local
    Um nome internoEle não termina em um domínio de nível superior que exista na zona raiz pública, então ninguém pode provar que é seu
    Recusado
  • intranet
    Um rótulo únicoUm nome sem nenhum ponto cai na mesma definição
    Recusado
  • my_host.example.com
    Um sublinhadoUm rótulo pode ter letras, dígitos e hifens, e mais nada
    Recusado
  • *.co.uk
    Um curinga sobre um registro inteiroUm curinga pode substituir o rótulo mais à esquerda, nunca um sufixo público
    Recusado
  • 192.168.1.10
    Um endereço reservadoUm endereço público pode ser certificado; um de uma faixa privada ou de uso especial nunca pode
    Recusado
  • example.com.
    Um ponto no finalO rótulo raiz vazio não deve ser escrito
    Recusado
Seis nomes, cada um quebrando uma regra diferente — e todos são rejeições que você poderia ter visto antes de enviar a solicitação.

Como saber se a minha chave privada corresponde ao meu CSR?

Um arquivo de chave privada já carrega a própria chave pública, então a correspondência é uma comparação de duas chaves públicas — nenhum segredo é necessário e nada precisa ser enviado a lugar nenhum.

Abra Comparar uma chave ou certificado acima e adicione a chave ao lado da solicitação. A página lê só a metade pública do arquivo — chaves PKCS#8, PKCS#1 e SEC1 são todas entendidas —, compara com a chave da solicitação e responde. Nada é enviado, nada é guardado, e a chave é apagada quando você sai do campo. A mesma verificação funciona entre uma solicitação e o certificado que voltou da CA, e assim detecta "o certificado e a chave privada não correspondem" antes de um servidor se recusar a iniciar.

Se você prefere não colar uma chave em nenhuma página da web, a mesma resposta são dois comandos na sua própria máquina. openssl req -in request.csr -pubkey -noout imprime a chave pública da solicitação e openssl pkey -in private.key -pubout a imprime a partir da chave: saídas idênticas significam que correspondem. A forma antiga com -modulus funciona só para chaves RSA; -pubkey funciona para todos os tipos de chave.

Dois arquivos, uma comparaçãoRFC 2986 · OpenSSL manual
Seu navegador
  • O arquivo da chave privadaO arquivo que você nunca deve enviar a lugar nenhumA metade pública é lida dele
  • A solicitaçãoO arquivo que você envia à autoridade certificadoraEla já carrega a chave pública

É a mesma chave?

  • CorrespondemO certificado que voltar será instalado com esta chave
  • Não correspondemEsta é a divergência que um servidor web informa quando se recusa a iniciar

Nada cruza esta linha · A comparação funciona com a rede desligadaQualquer outro lugar

Ou faça na sua própria máquinaopenssl req -in request.csr -pubkey -nooutopenssl pkey -in private.key -puboutSaídas idênticas significam que correspondem
Um arquivo de chave privada já carrega a própria chave pública, então a pergunta se resolve comparando duas chaves públicas. Nenhum segredo precisa se mover para isso, e nenhum se move.

CSR, certificado, chave privada: qual é a diferença?

A chave privada é o segredo. O CSR é uma solicitação que prova que você a tem. O certificado é a resposta assinada da CA e é o único dos três que é público por definição.

Os três arquivos costumam ficar na mesma pasta, com nomes confusamente parecidos. Uma chave privada começa com -----BEGIN PRIVATE KEY----- ou -----BEGIN RSA PRIVATE KEY----- e nunca deve ser enviada a ninguém, nem a uma autoridade certificadora. Uma solicitação de assinatura de certificado começa com -----BEGIN CERTIFICATE REQUEST-----, é assinada por essa chave e é segura para enviar. Um certificado começa com -----BEGIN CERTIFICATE-----, é assinado pela CA e é enviado a todo visitante do seu site de qualquer maneira.

Depois que o certificado é emitido, a solicitação não serve mais para nada: não é necessária para instalar, renovar ou revogar coisa alguma. A chave é o que você precisa guardar, e guardar bem. Cole qualquer um dos três acima e esta página diz qual deles é.

Três arquivos, uma pasta, nomes confusamente parecidosRFC 7468

  • A chave privadaSecreta

    Sua primeira linha-----BEGIN PRIVATE KEY-----Também muito usadas-----BEGIN RSA PRIVATE KEY-----

    Assinado por
    Ninguém — é ela que assina
    Quem pode ver
    Você, e mais ninguém
    Para que serve
    Prova que este servidor é aquele para o qual o certificado foi emitido

  • A solicitação de assinatura de certificadoPública

    Sua primeira linha-----BEGIN CERTIFICATE REQUEST-----Também muito usadas-----BEGIN NEW CERTIFICATE REQUEST-----

    Assinado por
    Ela mesma, com a chave privada
    Quem pode ver
    Você e a autoridade certificadora
    Para que serve
    Pede um certificado e prova que você tem a chave a que ele se destina

  • O certificadoPública

    Sua primeira linha-----BEGIN CERTIFICATE-----

    Assinado por
    A autoridade certificadora
    Quem pode ver
    Todo visitante do seu site
    Para que serve
    Diz a um navegador que esta chave pertence a estes nomes

.csr.pem.req.txtNenhum padrão atribui uma extensão de arquivo a uma solicitação; todas estas estão em uso, e esta página lê o conteúdo, não o nome

Só a primeira das três é um segredo. A última é entregue a todo visitante de qualquer maneira, e a do meio não serve mais para nada no momento em que o certificado chega.

É seguro decodificar um CSR online?

Um CSR não tem nenhum segredo, então decodificá-lo em qualquer lugar é inofensivo. Uma chave privada é outra história, e é o arquivo com que as pessoas o confundem.

Tudo nesta página roda no seu navegador. A solicitação é interpretada por código baixado junto com a página, a assinatura é conferida pelo Web Crypto do próprio navegador e nenhuma requisição com os seus dados é feita a servidor algum — você pode acompanhar o painel de rede enquanto usa. Isso é uma propriedade de como a página foi construída, não uma promessa que pedimos que você aceite na confiança.

O motivo de isso importar é o arquivo que fica ao lado do CSR. A definição do próprio CA/Browser Forum é implacável: "Uma chave privada é considerada comprometida se o seu valor foi revelado a uma pessoa não autorizada, ou se uma pessoa não autorizada teve acesso a ela." Não é preciso nenhum uso indevido — chegar ao servidor de outra pessoa basta. Em 2020, a DigiCert encontrou 337 chaves privadas que clientes tinham colado junto com os CSRs e revogou todos os certificados envolvidos, escrevendo que "ao enviar a chave privada à DigiCert junto com o CSR, o cliente comprometeu a chave privada". Se esta página algum dia ler uma chave privada que você colar, ela avisa, se recusa a decodificá-la e não guarda nada dela.

Para onde o arquivo realmente vaiCA/Browser Forum TLS BR 2.3.1

Esta página

Seu navegador
  1. O arquivo é lido
  2. É desmontado por código que chegou com a página
  3. A assinatura é conferida pelo próprio navegador
  4. O resultado é desenhado

Nenhuma requisição sai levando os seus dadosAbra o painel de rede e acompanhe enquanto usa

Uma página que o envia

Seu navegador

O arquivo é enviado…junto com o que mais tiver sido colado ao lado

O servidor de outra pessoa

Uma chave privada que chega lá fica comprometida só por isso

“Uma chave privada é considerada comprometida se o seu valor foi revelado a uma pessoa não autorizada, ou se uma pessoa não autorizada teve acesso a ela.”

a definição que as próprias autoridades certificadoras escreveram para si

Já aconteceuEm 2020, uma autoridade certificadora encontrou 337 chaves privadas coladas ao lado de uma solicitaçãoTodos os certificados envolvidos foram revogados

Nada em uma solicitação é secreto, então decodificar uma em qualquer lugar é inofensivo. O arquivo com que as pessoas a confundem é outra história, e o dano não precisa de nenhum uso indevido — ser visto basta.

RSA ou ECDSA: que chave um CSR deve pedir?

Uma chave ECDSA P-256 é tão forte quanto uma RSA de 3072 bits e muito menor, então é o melhor padrão. O RSA 2048 continua sendo aceito em toda parte.

O NIST coloca o P-256 e o RSA-3072 na mesma força de segurança de 128 bits, e a sua tabela nem sequer tem uma linha para o RSA-4096: a linha seguinte é o RSA-7680, com 192 bits, o nível que o P-384 alcança. Então uma chave RSA de 4096 bits faz cada visitante gastar trabalho extra no handshake sem ganho documentado sobre 3072. Os Baseline Requirements permitem também o P-521, mas a Let's Encrypt o recusa, então uma solicitação P-521 pode ser perfeitamente legal e ainda assim falhar na CA que você pretendia usar.

O Ed25519 não é uma opção para um certificado TLS público hoje, por melhor que seja o algoritmo: os Baseline Requirements listam o RSA e as três curvas do NIST e acrescentam que "nenhum outro algoritmo ou tamanho de chave é permitido". Uma chave pós-quântica também não — a votação que permitiria o ML-DSA no TLS público foi encerrada sem ser incorporada em outubro de 2026. Ed25519 e ML-DSA continuam úteis para SSH, para assinatura e para uma CA privada, e esta página lê solicitações que os usam.

A mesma força, em dois tamanhos muito diferentesNIST SP 800-57 Part 1 Rev 5, Table 2
ForçaChave RSACurva
112 bits de segurança2.048 bitsQualquer CA públicaNenhuma curva que uma autoridade certificadora pública permita fica nesta força
128 bits de segurança3.072 bitsQualquer CA públicaP-256Qualquer CA pública
4.096 bitsQualquer CA pública4.096 bits não está na tabela
192 bits de segurança7.680 bitsQualquer CA públicaP-384Qualquer CA pública
256 bits de segurança15.360 bitsQualquer CA públicaP-521Qualquer CA pública
  • Chave RSA
  • Curva
  • Os degraus vão direto de um tamanho ao seguinte e pulam o popular que fica no meio, então o trabalho extra de handshake que ele custa a cada visitante não compra nada que alguém tenha documentado
  • Aceita porLet's Encrypt

Uma curva carrega a mesma força em uma fração dos bytes

A comparação publicada, com as duas coisas que decidem se você pode de fato usar uma chave: o que as regras permitem e o que a autoridade certificadora que você pretendia usar permite.

Como criar um CSR em qualquer plataforma

Um comando do OpenSSL cobre Linux, macOS e Windows com OpenSSL instalado. O IIS tem o certreq, o macOS tem o Acesso às Chaves e este site tem um gerador que nunca envia a sua chave a lugar nenhum.

Com o OpenSSL, openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" cria a chave e a solicitação em uma só etapa. (-nodes deixa a chave sem criptografia. O OpenSSL 3 também escreve -noenc, mas o LibreSSL embutido no macOS só conhece -nodes.) Depois, openssl req -in example.com.csr -text -verify -noout mostra e verifica o arquivo. No Windows, certreq -new request.inf request.req lê um arquivo .inf cujos nomes alternativos ficam sob o OID 2.5.29.17 com linhas _continue_ — não existe uma chave SAN=. A própria página de referência da Microsoft avisa que o exemplo usa SHA-1, que uma CA hoje recusa, então defina o hash por conta própria.

No Mac, Acesso às Chaves > Assistente de Certificado > Solicitar um Certificado de uma Autoridade de Certificação cria um, com o tamanho da chave atrás da caixa "Permitir-me especificar as informações do par de chaves". Ou use o nosso gerador de CSR, que cria a chave com o Web Crypto do seu navegador e entrega os dois arquivos sem que passem por um servidor. Nenhum padrão atribui uma extensão de arquivo a um CSR: .csr, .pem, .req e .txt estão todas em uso, e esta página lê o conteúdo em vez de confiar no nome.

Quatro formas de criar umOpenSSL · Microsoft Learn · Apple Support

  1. OpenSSLLinux, macOS, Windows

    Cria a chave e a solicitação em um único comandoopenssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com"Depois leia de volta e verifique a assinatura delaopenssl req -in example.com.csr -text -verify -noout

  2. certreqWindows Server e IIS

    Lê um arquivo de texto simples; os nomes alternativos vão em uma seção de extensões, um por linhacertreq -new request.inf request.req[Extensions] 2.5.29.17 = "{text}" _continue_ = "DNS=example.com&" _continue_ = "DNS=www.example.com"A própria página de exemplo da Microsoft ainda é escrita em torno de um hash que uma autoridade certificadora hoje recusa, então defina o hash por conta própria

  3. Keychain AccessmacOS

    Keychain Access › Certificate Assistant › Request a Certificate From a Certificate AuthorityO seu Mac dá nome a estes menus no idioma deleO tipo e o tamanho da chave ficam atrás da caixa que permite especificar o par de chavesChaves RSA de 2048 a 4096 bits; as menores não são mais oferecidas

  4. DNS RobotQualquer navegador

    Cria a chave com a criptografia do próprio navegador e entrega os dois arquivos sem que nenhum passe por um servidorAbrir o gerador
Um único comando do OpenSSL funciona no Linux, no macOS e no Windows. As outras três formas são para as máquinas em que ele não está à mão.

Quanto tempo vai durar o certificado?

Um certificado TLS público emitido hoje não pode passar de 200 dias. Isso cai para 100 dias em março de 2027 e para 47 dias em março de 2029.

O cronograma vem da votação SC-081v3 do CA/Browser Forum, adotada em abril de 2025, e um CSR não tem como influenciá-lo: a validade nunca vem da solicitação. Cada etapa tem dois números, um SHOULD NOT um dia abaixo do MUST NOT — 199 e 200 hoje, 99 e 100 a partir de 15 de março de 2027, 46 e 47 a partir de 15 de março de 2029. Para efeito de contagem, "um dia é medido como 86.400 segundos", e qualquer parte de um dia adicional conta como um dia inteiro.

A consequência prática é que a renovação precisa ser automática. Se você ainda cria um CSR à mão todo ano, é hora de passar para o ACME, em que o cliente faz a solicitação por você — e em que, aliás, o PKCS#10 é de fato obrigatório, embora os próprios Baseline Requirements peçam apenas "uma solicitação de certificado em um formato prescrito pela CA".

Quanto tempo um certificado pode durarCA/Browser Forum TLS BR 2.3.1 §6.3.2
  1. antes de 15 de março de 2026Onde hoje se encaixa397 dias398 dias
  2. a partir de 15 de março de 2026199 dias200 dias
  3. a partir de 15 de março de 202799 dias100 dias
  4. a partir de 15 de março de 202946 dias47 dias
  • O cronograma inteiro vem de uma única votação, SC-081v3, adotada em 11 de abril de 2025
  • Um dia é contado como exatamente 86.400 segundos e qualquer parte de um dia adicional conta como um dia inteiro
  • Nada em uma solicitação muda isso
Quatro etapas, cada uma com dois números: o que as regras desaconselham e o que elas proíbem. As datas já estão fixadas, e é isso que faz da renovação automática a única resposta viável.

O que o ASN.1 bruto mostra

Por baixo do base64, um CSR é uma árvore codificada em DER. O decodificador a desenha com deslocamentos de bytes e nomeia cada identificador de objeto que conhece, que é o que o openssl asn1parse imprime.

É a forma honesta de mostrar um campo para o qual ninguém tem um nome amigável. Abra Estrutura bruta em qualquer item decodificado e você verá o CertificationRequestInfo, os nomes distintos relativos do titular um a um, o SubjectPublicKeyInfo, o conjunto attributes [0] e, dentro dele, o atributo extensionRequest — identificador de objeto 1.2.840.113549.1.9.14, definido não na RFC 2986, mas na RFC 2985 §5.4.2 — levando as próprias extensões X.509 da RFC 5280.

O outro atributo que você pode encontrar ali é o challengePassword (1.2.840.113549.1.9.7). Ele foi pensado como um segredo compartilhado para revogar um certificado depois, ainda é usado na inscrição por SCEP e não tem papel em um pedido de certificado web comum. Esta página o mostra quando ele existe, porque um campo que você não vê é um campo que você não pode conferir.

A mesma solicitação, em bytesRFC 2986 · RFC 2985 · RFC 5280
No byteEstruturaTamanho
0SEQUENCE749 bytes
4SEQUENCE469 bytes
8INTEGER03 bytes
11SEQUENCE108 bytes
13SET13 bytes
15SEQUENCE11 bytes
17OBJECT IDENTIFIERC2.5.4.65 bytes
22PrintableStringUS4 bytes
26SET21 bytes
28SEQUENCE19 bytes
30OBJECT IDENTIFIERST2.5.4.85 bytes
35UTF8StringCalifornia12 bytes
47SET24 bytes
49SEQUENCE22 bytes
51OBJECT IDENTIFIERL2.5.4.75 bytes
56UTF8StringSan Francisco15 bytes
71SET22 bytes
73SEQUENCE20 bytes
75OBJECT IDENTIFIERO2.5.4.105 bytes
80UTF8StringExample Inc13 bytes
93SET26 bytes
95SEQUENCE24 bytes
97OBJECT IDENTIFIERCN2.5.4.35 bytes
102UTF8Stringwww.example.com17 bytes
119SEQUENCE294 bytes
123SEQUENCE15 bytes
125OBJECT IDENTIFIERrsaEncryption1.2.840.113549.1.1.111 bytes
136NULL2 bytes
138BIT STRING2.160 bits30 82 01 0a 02 82 01 01 00 c5 47 47 1d 26 1c bf275 bytes
413[0]60 bytes
415SEQUENCE58 bytes
417OBJECT IDENTIFIERextensionRequest1.2.840.113549.1.9.1411 bytes
428SET45 bytes
430SEQUENCE43 bytes
432SEQUENCE41 bytes
434OBJECT IDENTIFIERSubject Alternative Name2.5.29.175 bytes
439OCTET STRING32 bytes30 1e 82 0f 77 77 77 2e 65 78 61 6d 70 6c 65 2e34 bytes
473SEQUENCE15 bytes
475OBJECT IDENTIFIERsha256WithRSAEncryption1.2.840.113549.1.1.1111 bytes
486NULL2 bytes
488BIT STRING2.048 bits00 57 41 c5 09 98 14 78 8c ee c3 61 d4 c0 e0 2d261 bytes
  • Contém outras coisas
  • Contém um valor
  • Nomeado pela posição

  • O atributo que leva as extensões

    1.2.840.113549.1.9.14Ele é definido em um documento diferente daquele que define a própria solicitação, e é por isso que os nomes alternativos viajam dentro de um atributo em vez de ficarem ao lado do titular

  • O outro atributo que você pode encontrarNão está nesta solicitação

    1.2.840.113549.1.9.7Um segredo compartilhado, pensado para pedir depois que o certificado seja revogado, e ainda usado quando um dispositivo se inscreve em uma rede
Cada byte da solicitação de exemplo, com cada identificador de objeto nomeado. É o que um decodificador de linha de comando imprime, desenhado em vez de impresso, para você ver onde um campo termina e o seguinte começa.

Decodificador de CSR: perguntas e respostas

Como decodificar um CSR?

Cole a solicitação inteira na caixa acima, com as linhas -----BEGIN CERTIFICATE REQUEST----- e -----END CERTIFICATE REQUEST-----, ou solte o arquivo na página. Ela é decodificada enquanto você cola: o titular, a chave pública, cada nome alternativo do titular, cada extensão solicitada e as impressões digitais. Você também pode colar só o corpo base64, um dump hexadecimal ou enviar um arquivo DER binário.

Este decodificador de CSR é seguro?

Sim, por dois motivos. Uma solicitação de assinatura de certificado não contém nenhum segredo — ela existe para ser enviada a uma autoridade certificadora —, então decodificá-la em qualquer lugar é inofensivo. E esta página faz o trabalho no seu navegador: a solicitação é interpretada por código baixado junto com a página e nada é enviado a servidor algum. Se você colar uma chave privada por engano, a página avisa, se recusa a decodificá-la e não guarda nada dela.

Como verificar se o meu CSR é válido?

Decodifique-o aqui e leia o veredito. A página confere a assinatura da própria solicitação, que prova que quem a enviou tem a chave privada correspondente, e depois aplica as regras que uma autoridade certificadora pública aplica: nomes que ela não pode certificar, curingas amplos demais, endereços IP reservados, chaves pequenas demais ou fatoráveis, campos de titular obsoletos e hashes de assinatura ultrapassados. Cada achado diz se a CA vai recusá-lo (rejeição), alterá-lo (correção) ou apenas anotá-lo (nota).

Por que a minha autoridade certificadora rejeita o meu CSR?

As causas comuns são um nome interno como server.local ou um nome de host de rótulo único, um sublinhado em um nome de host, um curinga sobre um sufixo público como *.co.uk, um endereço IP privado nos nomes alternativos, uma chave RSA abaixo de 2048 bits ou uma solicitação ainda assinada com SHA-1. Decodifique a solicitação acima e cada uma dessas causas é nomeada explicitamente, com a regra que ela quebra.

Como saber se a minha chave privada corresponde ao meu CSR?

Use Comparar uma chave ou certificado acima: adicione a chave ao lado da solicitação e a página compara a chave pública que está no arquivo da chave com a da solicitação, no seu navegador. Ou faça você mesmo — openssl req -in request.csr -pubkey -noout e openssl pkey -in private.key -pubout imprimem a mesma chave pública quando correspondem. A mesma comparação funciona entre uma chave e um certificado emitido.

Isto também decodifica um certificado SSL?

Sim. Cole um certificado e ele é decodificado como certificado: emissor e titular, número de série, datas de validade, cada nome alternativo, uso de chave e uso estendido de chave, os identificadores de chave da autoridade e do titular, URLs de OCSP e de emissores da CA, políticas de certificado e quaisquer timestamps de Certificate Transparency incorporados. Cole um certificado e a sua solicitação juntos e a página também diz se eles compartilham uma chave.

Que campos uma autoridade certificadora realmente usa do meu CSR?

Com certeza, um: a chave pública. A documentação da própria DigiCert diz que o resto é ignorado. Em um certificado OV ou EV, a CA precisa validar por conta própria a organização e o país antes de incluí-los; as datas de validade sempre vêm do cronograma dos Baseline Requirements, nunca da solicitação. Dois campos não são apenas ignorados, mas proibidos em um certificado TLS público: o OU e, em certificados com validação de domínio, o emailAddress.

O nome comum ainda importa?

Só como cópia de outra coisa. Os navegadores ignoram o nome comum para comparar o host desde 2017 e usam apenas os nomes alternativos do titular. Os Baseline Requirements classificam o nome comum como NOT RECOMMENDED e exigem que, se ele existir, "DEVE conter exatamente uma entrada que seja um dos valores contidos na extensão subjectAltName do certificado". Um nome comum que não está entre os seus nomes alternativos é uma rejeição, e esta página o sinaliza.

Posso decodificar vários arquivos de uma vez?

Sim. Cole uma solicitação, o certificado dela e os intermediários juntos e cada bloco é decodificado em um cartão próprio, na ordem em que você os colou. Um bloco corrompido não impede os outros. Se houver uma chave privada no que você colou, ela é nomeada e ignorada, nunca decodificada. Até quarenta blocos são decodificados e o que passar disso é contado e informado em vez de descartado em silêncio.

O que é uma challenge password em um CSR?

Um atributo opcional da RFC 2985, originalmente um segredo compartilhado que você citaria ao pedir a revogação do certificado. Ele ainda tem papel na inscrição por SCEP, em que um dispositivo prova que tem permissão para pedir. Não tem papel em um pedido comum de certificado web e, como é um campo que poucas ferramentas mostram, esta página o exibe sempre que uma solicitação o traz.

Posso usar uma chave Ed25519 em um certificado público?

Hoje não. Os Baseline Requirements permitem RSA e as curvas P-256, P-384 e P-521 e depois afirmam que "nenhum outro algoritmo ou tamanho de chave é permitido", então nenhuma autoridade certificadora pública vai emitir para uma solicitação Ed25519. É uma ótima chave para SSH, para assinatura e para uma CA privada, e este decodificador lê solicitações Ed25519 e Ed448, e chaves ML-DSA pós-quânticas, sem reclamar.

Por quanto tempo um certificado é válido hoje?

Um certificado TLS público emitido hoje não pode passar de 200 dias, contra 398 antes de 15 de março de 2026. Cai para 100 dias em 15 de março de 2027 e para 47 dias em 15 de março de 2029, pela votação SC-081v3 do CA/Browser Forum. Nada em um CSR afeta isso; a validade é definida pela CA. Com essas durações, a renovação precisa ser automatizada, o que na prática significa ACME.

Sentiu falta de algo?Sugira um recurso ou uma nova ferramenta

Ferramentas relacionadas