Tema

Ferramentas populares

Gerador de CSR

Crie uma solicitação de assinatura de certificado e a chave privada que a acompanha, aqui mesmo nesta página. O par de chaves é gerado pelo Web Crypto do seu navegador e nunca sai do seu computador: nada do que você digita e nenhuma chave é enviado ao nosso servidor nem ao de ninguém.

RSA 2048/3072/4096 · ECDSA P-256/P-384/P-521 · Ed25519 · criado pelo Web Crypto no seu navegador, nunca enviado
Cada nome aparece aqui, com o seu tipo, à medida que você o digita.

Um por linha. O primeiro também vira o nome comum.

Experimente um
Tipo de chave

O padrão sensato: tão forte quanto o RSA 3072 e muito menor.

Para quem é o certificadoOpcional na maioria dos certificados

O nome jurídico da sua organização, como está registrado.

Escreva por extenso, sem abreviar.

Duas letras, o código ISO 3166-1.

O que pedirUma CA pública define isso pelo próprio perfil. Uma CA privada pode querer que você peça.
Uso de chave
Uso estendido de chave

Só se a sua CA pediu. A inscrição por SCEP a usa; um pedido de certificado web não.

O par é criado pelo seu navegador e nunca é enviado a lugar nenhum.

Envie este arquivoA solicitação de assinatura de certificadoCriado neste navegador quando você clicar no botão
Guarde este arquivoA chave privadaCriado neste navegador quando você clicar no botão

O que você está prestes a enviarECDSA P-256 · SHA-256

ECDSA P-256Criado neste navegador quando você clicar no botão
O que uma autoridade certificadora fará com ela

Digite um nome ou experimente um exemplo, e esta coluna mostra o que uma autoridade certificadora faria com a solicitação — antes de ela ser criada.

O par de chaves é criado pelo Web Crypto do seu navegador, em um quadro que não pode se conectar a lugar nenhum, e nunca é enviado. Abra o painel de rede e confira.

O que é um gerador de CSR?

Ele cria dois arquivos: uma solicitação de assinatura de certificado, que você envia a uma autoridade certificadora, e a chave privada, que fica com você. A solicitação leva a sua chave pública e os nomes que você quer certificar, assinados pela chave privada.

O formato é o PKCS#10, descrito na RFC 2986. Dentro da solicitação há um nome de titular, a sua chave pública, um conjunto de atributos com os nomes alternativos e uma assinatura feita com a sua chave privada sobre tudo isso. Essa autoassinatura é a prova de posse: mostra que quem envia tem a chave para a qual o certificado será emitido.

Os dois arquivos não são intercambiáveis. A solicitação existe para ser enviada — a uma CA, em um chamado de suporte, a qualquer lugar. A chave privada, nunca. Nesta página a chave é criada e fica no seu navegador. Você ainda precisa confiar no código da página, como em qualquer ferramenta web, mas pode conferir o que ela envia: abra o painel de rede e acompanhe enquanto gera uma.

Dois arquivos, criados juntosRFC 2986 · PKCS #8

A chave privadaGuarde este arquivo

-----BEGIN PRIVATE KEY-----
  • A metade privadaAssina a solicitação agora e, depois, cada conexão com o seu servidor
  • A sua metade públicaCopiada para dentro da solicitação

Uma única cópia, no seu computador

A solicitação de assinatura de certificadoEnvie este arquivo

-----BEGIN CERTIFICATE REQUEST-----
  1. Nome do titular108 bytesOpcional na maioria dos certificados
  2. Sua chave pública294 bytesO único campo que uma autoridade certificadora com certeza usa
  3. Os nomes que você pediu60 bytesOs nomes alternativos, levados como um atributo
  4. A assinatura261 bytesFeita pela chave privada, sobre tudo o que vem acima

Não contém nenhum segredo

Uma solicitação real, com 749 bytes no total, ao lado da chave que a criou. Só a solicitação precisa sair do seu computador: ela leva a metade pública da chave e uma assinatura que só a metade privada poderia ter feito.
Gerador de CSR: os campos do titular, os nomes alternativos e a solicitação pronta com a sua chave privadaGerador de CSR: os campos do titular, os nomes alternativos e a solicitação pronta com a sua chave privadaOs nomesOs nomes de host que o certificado deve cobrir. O primeiro vira o nome comum; os outros se juntam a ele.A chaveRSA ou uma curva elíptica. O par é criado pelo seu navegador, diante de você.Quem é vocêOs campos do titular. Uma CA pública valida esses dados por conta própria, então só poucos sobrevivem.Os dois arquivosA solicitação, que você envia, e a chave privada, que você guarda. A chave só existe no seu navegador até você salvá-la.O mesmo, como comandoA linha do OpenSSL que cria exatamente esta solicitação, para quando você preferir fazer por conta própria.
Uma solicitação sendo criada: os nomes, o tipo de chave e os dois arquivos que saem dela. Selecione um número para ver o que cada parte mostra.

Por que gerar a chave no seu navegador?

Porque uma chave privada que chega ao servidor de outra pessoa se enquadra na definição do próprio setor de chave comprometida — seja o que esse servidor faça com ela depois.

Os Baseline Requirements do CA/Browser Forum a definem sem margem para discussão: "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 lá basta.

Isso não é teoria. Em 2020, a DigiCert encontrou 337 chaves privadas que clientes tinham colado junto com as solicitações, revogou todos os certificados envolvidos e divulgou o caso publicamente: "ao enviar a chave privada à DigiCert junto com o CSR, o cliente comprometeu a chave privada", acrescentando que "a única parte de um CSR que usamos é a chave pública". Um gerador que cria a chave no próprio servidor e lhe entrega uma cópia já a comprometeu, por essa definição. Esta página não tem como fazer isso: crypto.subtle.generateKey roda no seu navegador, dentro de um quadro isolado que não pode se conectar a lugar nenhum, e a página ao redor só chega a ver a chave pública.

Onde a chave privada é criadaCA/Browser Forum TLS BR 2.3.1

Esta página

Seu navegador
  1. O Web Crypto cria o par de chaves crypto.subtle.generateKey
  2. A chave assina a solicitação
  3. Você salva os dois arquivos
Nada cruza esta linha
O servidor deles

A chave só existiu no seu computador

Um gerador que cria a chave no servidor dele

Seu navegador
  1. Seus nomes e dados vão para o servidor
A chave privada cruza esta linha
O servidor deles
  1. O servidor cria o par de chaves
  2. A chave privada é enviada de volta a você

Comprometida por definição, antes de qualquer instalação

“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 enviadas junto com solicitaçõesTodos os certificados envolvidos foram revogados

A diferença não está em como a chave é criada, mas em onde. Uma chave que passou pelo servidor de outra pessoa já se enquadra na definição do próprio setor de chave comprometida, seja o que for que esse servidor faça com ela depois.

Como criar um CSR

Digite os nomes de host, escolha um tipo de chave e clique no botão. O resto é opcional — um certificado moderno é identificado pelos nomes alternativos, não pelo titular.

Coloque no campo de nomes todos os nomes que o certificado deve cobrir: example.com, www.example.com, um curinga como *.api.example.com ou um endereço IP. O primeiro também vira o nome comum, que os Baseline Requirements exigem — quando há um nome comum — que repita exatamente um dos nomes alternativos.

País, organização e localidade só importam para um certificado com validação de organização ou validação estendida, e mesmo assim a CA precisa validá-los por conta própria antes de incluí-los em um certificado. Em um certificado com validação de domínio — o tipo que a Let's Encrypt emite — os únicos campos de titular que as regras permitem são o país e o nome comum. O gerador marca os dois campos que uma CA pública remove ou proíbe, a unidade organizacional e o endereço de e-mail, e a coluna ao lado do formulário mostra o que mudaria.

Dos nomes a dois arquivos/csr-generator

  1. Digite os nomes

    Todos os hosts que o certificado deve cobrir; o primeiro vira o nome comum

  2. Escolha um tipo de chave

    P-256, a menos que algo antigo precise lê-la

  3. Criar a solicitação

    Seu navegador cria a chave e assina a solicitação com ela

  4. Pegue os dois arquivos

    Envie a solicitação à sua autoridade certificadora; guarde a chave
O trabalho inteiro, como esta página o faz. Tudo depois dos nomes é opcional: um certificado moderno é identificado pelos nomes alternativos, então os campos do titular só importam em um pedido com validação de organização.

Que tipo de chave devo escolher?

ECDSA P-256 para qualquer coisa nova: é tão forte quanto uma chave RSA de 3072 bits, muito menor e permitida pelas regras que toda autoridade certificadora pública segue. RSA 2048 quando um dispositivo mais antigo precisar ler a chave.

O NIST coloca o P-256 e o RSA-3072 na mesma força de segurança de 128 bits e não dá ao RSA-4096 força nenhuma própria — o degrau seguinte da sua tabela é 7680 bits. Então o 4096 faz cada visitante gastar trabalho extra no handshake sem ganho documentado. O P-384 é o degrau de 192 bits, e os Baseline Requirements permitem também o P-521, mas a Let's Encrypt recusa o P-521: uma solicitação pode ser perfeitamente legal e ainda assim falhar na CA que você pretendia usar.

O Ed25519 é oferecido aqui porque é excelente para SSH, para assinatura e para uma CA privada — mas nenhuma autoridade certificadora pública emite um certificado TLS para ele. As regras listam o RSA e as três curvas do NIST e depois dizem que "nenhum outro algoritmo ou tamanho de chave é permitido". O mesmo vale para o ML-DSA pós-quântico: a votação que o permitiria no TLS público foi encerrada sem ser incorporada em outubro de 2026. O gerador avisa isso ao lado de cada opção, em vez de deixar você descobrir por um e-mail de rejeição.

Força de segurança, como a tabela do NISTNIST SP 800-57 Part 1 Rev 5, Table 2
112 bits128 bits192 bits256 bits
RSA20483072768015360
RSA 40964096
ECDSA—P-256P-384P-521

4096 bits: sem degrau próprio A tabela vai de um tamanho direto ao seguinte, então o trabalho extra de handshake não compra nada que esteja documentado

Fora da tabela

Ed25519Nenhuma autoridade certificadora pública emite para ele

ML-DSAPós-quântico: a votação que o permitiria foi encerrada sem ser incorporada em outubro de 2026

  • A mesma força
  • Oferecido aqui
  • Na tabela, não oferecido aqui
  • Aceita porLet's Encrypt
Leia na horizontal, não na vertical: o P-256 e uma chave RSA de 3072 bits têm a mesma força, e a curva a obtém com um doze avos do tamanho da chave. Uma chave pode estar dentro das regras e ainda assim ser recusada pela autoridade certificadora que você pretendia usar.

O que colocar em cada campo

Nomes: todos os hosts que o certificado cobre. País: duas letras. Organização: o seu nome jurídico, para um certificado OV ou EV. O resto é opcional, e parte dele agora é proibida.

A unidade organizacional é proibida. Pela votação SC047 do CA/Browser Forum, nenhum certificado TLS público emitido desde 1 de setembro de 2022 pode conter OU; a CA a remove em vez de recusar o pedido. Um endereço de e-mail no titular também não é permitido em um certificado com validação de domínio, e é desaconselhado nos demais. Este gerador ainda oferece os dois campos, para CAs privadas, e os marca.

O país é um código ISO 3166-1 alpha-2 — US, DE, GB, IN — e não o nome do país, nem três letras. O estado ou a província deve ser escrito por extenso, sem abreviar. Para um certificado de validação estendida você precisa também da jurisdição de constituição e do número de registro, que este gerador oferece.

Quais campos do titular acabam no certificadoCA/Browser Forum TLS BR 7.1.2.7
Na sua solicitaçãoDVValidação de domínioOVValidação de organizaçãoEVValidação estendida
Nome comumCN
PaísC
OrganizaçãoO
Cidade, estado ou provínciaL, ST
Rua, CEPstreet, postalCode
Unidade organizacionalOUProibida desde 1 de setembro de 2022
Endereço de e-mailemailAddress
Número de registro, categoria de negócio, jurisdiçãoserialNumber, businessCategory, jurisdictionC
  • No certificado, como a CA o validou
  • Permitido, mas desaconselhado
  • Não vai neste tipo de certificado
  • Nunca permitido
Preencha só o que o certificado que você está comprando pode levar: uma autoridade certificadora precisa validar cada campo do titular que mantém, e o gerador marca os campos que uma CA pública remove.

Posso reutilizar uma chave ou um CSR?

Pode — nada proíbe —, mas uma chave nova para cada certificado custa um segundo e limita o que uma única chave vazada pode alcançar.

Os Baseline Requirements são explícitos: "uma solicitação de certificado PODE bastar para vários certificados emitidos ao mesmo requerente", então reutilizar uma solicitação para renovar é permitido. O custo aparece quando algo dá errado. Se essa chave algum dia for comprometida, todo certificado que a carrega precisa ser revogado em 24 horas, e não só aquele que preocupava você.

E uma chave comprometida fica queimada para sempre: uma CA "DEVE rejeitar uma solicitação de certificado" se for informada de que a chave sofreu um comprometimento, então essa chave nunca mais poderá ser certificada por nenhuma CA que tenha sido avisada. Com a validade dos certificados caindo para 47 dias em 2029, uma chave reutilizada assinaria por anos, em dezenas de renovações. Criar uma nova leva um segundo.

Uma chave por trás de vários certificadosCA/Browser Forum TLS BR 4.9.1.1 · 6.1.1.3

Uma chave, reutilizada

A chave vaza
  • www.example.com
  • api.example.com
  • mail.example.com

3 certificados revogados em 24 horas

E a chave nunca mais poderá ser certificada por uma CA que tenha sido avisada

Uma chave nova para cada um

  • www.example.com
  • api.example.comIntactos
  • mail.example.comIntactos

1 certificado revogado em 24 horas

Reutilizar uma chave é permitido. O custo só aparece quando essa chave vaza: tudo o que a carrega cai de uma vez, e a chave passa a ser recusada daí em diante.

O que acontece depois que você envia o CSR

A CA valida os nomes, ignora a maior parte do resto e devolve um certificado. Guarde a chave privada — sem ela você não consegue instalar o certificado.

A validação é sobre os nomes, não sobre o arquivo: um registro DNS, um arquivo no servidor web ou um e-mail para um endereço do domínio. Passando isso, o certificado volta e a solicitação não serve mais para nada — não é necessária para instalar, renovar ou revogar coisa alguma. O que você precisa guardar é a chave privada, porque o certificado é inútil sem ela. Cole o certificado no decodificador de CSR e acrescente a chave privada ao lado para conferir se correspondem antes de reiniciar qualquer coisa.

O certificado será de curta duração. Um certificado TLS público emitido hoje não pode passar de 200 dias, caindo para 100 em 15 de março de 2027 e para 47 em 15 de março de 2029. Com essas durações a renovação precisa ser automática, o que significa ACME — e um cliente ACME faz a solicitação por você, então esta página serve para os casos que um cliente não cobre: um dispositivo, um equipamento, uma CA que quer uma solicitação feita à mão.

Da solicitação a um certificado funcionandoRFC 8555 · CA/Browser Forum TLS BR 6.3.2
  1. Seu computadorVocê envia a solicitação
  2. A autoridade certificadoraEla confere que você controla cada nomeUm registro DNSUm arquivo no servidor webUm e-mail para um endereço do domínio
  3. A autoridade certificadoraEla assina o certificado e o devolve
  4. Seu computadorVocê o instala ao lado da chaveDepois disto a solicitação não serve mais para nada
A chave privada nunca se move
Quanto tempo o certificado pode durar
  1. 398 diasEm vigor hoje
  2. 200 diasa partir de 15 de março de 2026
  3. 100 diasa partir de 15 de março de 2027
  4. 47 diasa partir de 15 de março de 2029
A validação é sobre os nomes, não sobre o arquivo. O certificado que volta é inútil sem a chave, e durações tão curtas são o motivo de a renovação agora precisar ser automática.

A mesma coisa com o OpenSSL

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes -keyout example.com.key -out example.com.csr cria a chave e a solicitação em uma só etapa.

O gerador escreve o comando para o que você tiver preenchido, com os nomes alternativos e cada extensão, e os nossos testes o executam no OpenSSL para conferir se ele cria o mesmo titular e as mesmas extensões que a página. Acrescente -subj "/CN=example.com" para pular as perguntas, -addext "subjectAltName=DNS:example.com,DNS:www.example.com" para os nomes e -utf8 para que um nome com acento sobreviva. -nodes deixa a chave sem criptografia: o OpenSSL 3 prefere a grafia mais nova -noenc, mas ainda aceita -nodes, a única grafia que o LibreSSL embutido no macOS conhece. Esse LibreSSL não consegue criar uma chave Ed25519; use o OpenSSL 1.1.1 ou posterior para isso.

Para conferir o que você criou: openssl req -in example.com.csr -text -verify -noout mostra todos os campos e verifica a autoassinatura, parando antes de imprimir qualquer coisa se a assinatura falhar. Para confirmar que a chave pertence à solicitação, compare openssl req -in example.com.csr -pubkey -noout com openssl pkey -in example.com.key -pubout. Nenhum padrão atribui uma extensão de arquivo a um CSR, então .csr, .pem, .req e .txt estão todas corretas.

Um comando, opção por opçãoOpenSSL 3 · openssl-req(1)

openssl req -new -utf8 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes -keyout example.com.key -out example.com.csr -sha256 -subj '/CN=example.com' -addext 'subjectAltName=DNS:example.com,DNS:www.example.com'

  1. openssl req -newCria uma solicitação de assinatura de certificado
  2. -utf8Lê o titular como UTF-8, para que um nome com acento sobreviva
  3. -newkey…e um novo par de chaves junto com ela
  4. -pkeyoptNa curva P-256
  5. -nodesDeixa o arquivo da chave sem criptografia (o OpenSSL 3.0 também aceita -noenc)
  6. -keyoutOnde a chave privada é gravada
  7. -outOnde a solicitação é gravada
  8. -sha256O hash com que a solicitação é assinada
  9. -subjO titular, para que ele não faça perguntas
  10. -addextOs nomes alternativos

Lê de volta e verifica a própria assinaturaopenssl req -in example.com.csr -text -verify -noout

A chave pertence à solicitação? As duas saídas têm de ser idênticasopenssl req -in example.com.csr -pubkey -nooutopenssl pkey -in example.com.key -pubout

O comando que esta página escreve para o primeiro exemplo, desmontado. O gerador escreve a mesma linha para o que você preencher, com cada nome e extensão que a solicitação leva.

Criar um CSR no Windows, no IIS e no macOS

O Windows tem o certreq e um arquivo .inf; o macOS tem o Acesso às Chaves. Os dois têm uma armadilha que vale conhecer antes de começar.

No Windows, certreq -new request.inf request.req lê um arquivo cuja seção [NewRequest] define o titular e o tamanho da chave, e cujos nomes alternativos vão em [Extensions] sob o OID 2.5.29.17 com linhas _continue_ — não existe uma chave SAN=, um erro fácil de cometer. A própria página de referência da Microsoft avisa que o exemplo usa SHA-1, e a Let's Encrypt recusa uma solicitação assinada com SHA-1, 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 uma; o tipo e o tamanho da chave ficam atrás da caixa "Permitir-me especificar as informações do par de chaves", e chaves RSA abaixo de 2048 bits não são mais oferecidas. Nenhum dos dois caminhos facilita os nomes alternativos, e é por isso que um comando costuma ser o caminho mais fácil.

Criar uma sem um navegadorMicrosoft Learn · Apple Support

certreqWindows Server e IIS

O certreq lê um arquivo de texto simples e grava a solicitaçãocertreq -new request.inf request.req
request.inf
[NewRequest]Subject = "CN=example.com"KeyAlgorithm = RSAKeyLength = 2048HashAlgorithm = sha256RequestType = PKCS10[Extensions]2.5.29.17 = "{text}"_continue_ = "DNS=example.com&"_continue_ = "DNS=www.example.com"

Os nomes alternativos: uma extensão identificada pelo OID, um nome por linha

Defina o hash por conta própria: o exemplo da própria Microsoft é escrito em torno do SHA-1, que uma autoridade certificadora recusa

Não existe uma chave SAN=

Keychain AccessmacOS

O Acesso às Chaves cria uma a partir do Assistente de Certificado
  1. Keychain Access
  2. Certificate Assistant
  3. Request a Certificate From a Certificate Authority
O seu Mac dá nome a estes menus no idioma dele

Let me specify key pair information

O tipo e o tamanho da chave ficam atrás desta caixaRSA até 4096; abaixo de 2048 não é mais oferecido
Os dois caminhos criam a chave na sua própria máquina, que é o que importa. Nenhum deles facilita os nomes alternativos, e é por isso que um comando costuma ser o caminho mais fácil.

Um gerador de CSR online é seguro?

Depende inteiramente de onde a chave é criada. Uma página que a cria no seu navegador é segura; uma página que a cria no servidor dela já teve acesso à sua chave privada.

O teste é simples e você mesmo pode fazê-lo: abra o painel de rede do navegador, gere uma solicitação e acompanhe. Se a chave é criada na página, nem ela nem nada do que você digitou sai: aqui, as únicas requisições são a da própria página e de duas listas públicas de nomes, iguais para todo visitante. Se uma requisição sai e uma chave volta, essa chave existiu antes em outro lugar e, pela definição do próprio setor, está comprometida antes mesmo de você instalá-la.

Esta página faz todo o trabalho no navegador: o par de chaves vem de crypto.subtle.generateKey dentro de um quadro isolado que não pode se conectar a lugar nenhum, a página escreve a solicitação em torno da chave pública e o quadro a assina uma vez com a chave privada, que nunca sai dele. Os dois arquivos aparecem no seu navegador e em nenhum outro lugar. Se você preferir não confiar em nenhuma página web para isso, o comando OpenSSL desta página faz a mesma coisa na sua própria máquina — nós o mostramos exatamente por esse motivo.

O painel de rede, enquanto uma chave é criadaFerramentas do desenvolvedor › Rede

Esta página

RequisiçãoO que ela leva
GETtlds.jsonA lista de domínios de nível superior — a mesma para todo visitante
GETsuffixes.jsonA lista de sufixos públicos — a mesma para todo visitante

Nada do que você digitou, e nenhuma chave, sai da página

Um gerador que cria a chave no servidor dele

RequisiçãoO que ela leva
POST…/generateSeus nomes e dados
200-----BEGIN PRIVATE KEY-----Uma chave privada, criada em outro lugar

Uma chave volta pela rede: ela existiu antes em outro lugar

Experimente: abra as ferramentas do desenvolvedor do navegador na aba Rede e crie uma solicitação. Além do código da própria página, ela busca duas listas públicas, iguais para todo visitante; a chave é criada pela criptografia do seu próprio navegador, em um quadro que não pode se conectar a lugar nenhum.

Gerador de CSR: perguntas e respostas

Como criar um CSR?

Digite os nomes de host que o certificado deve cobrir, escolha um tipo de chave — ECDSA P-256 é o padrão sensato — e clique no botão. Saem dois arquivos: a solicitação de assinatura de certificado, que você envia à sua autoridade certificadora, e a chave privada, que você guarda. Tudo acontece no seu navegador, então nada é enviado e nada é guardado.

É seguro gerar um CSR online?

Depende de onde a chave é criada. Se a página a cria no próprio servidor, esse servidor já teve acesso à sua chave privada, o que a definição do próprio CA/Browser Forum chama de comprometimento. Se a página a cria no seu navegador, a chave nunca sai dele. Esta faz a segunda coisa, e você pode confirmar: abra o painel de rede e acompanhe enquanto gera uma.

Que tipo de chave devo escolher?

ECDSA P-256 para qualquer coisa nova. O NIST lhe atribui a mesma força de 128 bits de uma chave RSA de 3072 bits, e ela é muito menor, então cada handshake sai mais barato. Escolha o RSA 2048 quando um equipamento ou balanceador de carga mais antigo precisar dele. O RSA 4096 não compra nada documentado sobre o 3072, e a Let's Encrypt não aceita o P-521, embora as regras o permitam.

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

Não, nenhuma autoridade certificadora pública emite para ela. Os Baseline Requirements listam o RSA e as curvas P-256, P-384 e P-521 e acrescentam que "nenhum outro algoritmo ou tamanho de chave é permitido". O Ed25519 é oferecido aqui porque serve para SSH, para assinatura e para uma CA privada — mas um pedido TLS público com ele será recusado.

Para que serve o arquivo da chave privada?

É a metade do par que prova que o certificado é seu, e nunca vai para ninguém. Salve-a ao lado da solicitação; você vai precisar dela para instalar o certificado que a CA devolver, e sem ela o certificado é inútil. Se você a perder, o único remédio é uma chave nova, uma solicitação nova e um certificado novo.

Preciso preencher a organização e o país?

Só para um certificado com validação de organização ou validação estendida, e mesmo assim a CA precisa validá-los por conta própria antes de incluí-los em um certificado. Em um certificado com validação de domínio, as regras permitem no titular apenas o país e o nome comum — todo o resto não pode aparecer. O gerador marca os dois campos que uma CA pública remove ou proíbe: a unidade organizacional e o endereço de e-mail.

Por que o campo de unidade organizacional me avisa?

Porque o OU é proibido em um certificado TLS público. Pela votação SC047 do CA/Browser Forum, nenhum certificado TLS público emitido desde 1 de setembro de 2022 pode contê-lo, então as autoridades certificadoras o removem do pedido em vez de recusá-lo. Este gerador ainda oferece o campo, para CAs privadas, e diz o que uma CA pública fará.

Posso colocar mais de um domínio em um CSR?

Sim — é para isso que servem os nomes alternativos do titular, e é assim que se pede um certificado multidomínio ou SAN. Adicione todos os hosts que o certificado deve cobrir, inclusive a forma com www, se você a quiser. Você pode misturar curingas e nomes simples e acrescentar endereços IP, embora nem toda CA venda certificados para um endereço.

Posso reutilizar um CSR ou uma chave no próximo certificado?

Pode: as regras dizem que uma solicitação pode servir a vários certificados do mesmo requerente. O motivo para não fazer isso é o tamanho do estrago. Se essa chave algum dia for comprometida, todo certificado que a carrega precisa ser revogado em 24 horas, e a chave nunca mais poderá ser certificada por nenhuma CA que tenha sido avisada. Criar uma nova leva um segundo.

O que é uma challenge password?

Um atributo opcional da RFC 2985, pensado como um segredo compartilhado que você citaria ao pedir uma revogação mais tarde. Ela ainda é usada na inscrição de dispositivos por SCEP, e alguns serviços de certificados da Microsoft pedem uma. Não tem papel em um pedido comum de certificado web, então deixe-a vazia, a menos que a sua CA a tenha pedido expressamente.

Isto funciona para um certificado curinga?

Sim. Coloque *.example.com nos nomes e acrescente também example.com se quiser cobrir o domínio sem prefixo — um curinga substitui exatamente um rótulo e não corresponde ao nome sob o qual está. O asterisco tem de ser o rótulo inteiro mais à esquerda, e nenhuma CA emite um curinga sobre um sufixo público como *.co.uk.

O que faço com os arquivos depois?

Envie a solicitação à sua autoridade certificadora e guarde a chave privada em um lugar seguro, legível só por você (permissão 600 no Linux e no macOS). Quando o certificado voltar, cole-o e a solicitação no decodificador de CSR para confirmar que compartilham uma chave antes de reiniciar qualquer coisa — uma chave que não corresponde ao certificado é um erro que você prefere descobrir antes que o seu servidor o faça.

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

Ferramentas relacionadas