Sumário de CSR X.509 (resumo)

Entendendo o Certificate Signing Request X.509

Um CSR — Certificate Signing Request — é o arquivo que o administrador envia a uma Autoridade Certificadora para obter um certificado TLS/SSL. Tecnicamente é uma estrutura PKCS#10 (RFC 2986) que contém a chave pública do solicitante, um Subject Distinguished Name, extensões opcionais como Subject Alternative Names e uma autoassinatura feita com a chave privada correspondente, que prova que o requisitante realmente a possui. A CA inspeciona o CSR, valida posse do domínio (DV) ou identidade organizacional (OV/EV), descarta partes que não quer honrar e emite um certificado X.509 v3 (RFC 5280) ligando a chave pública ao nome verificado.

Um one-liner típico do OpenSSL gera chave e CSR de uma vez:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout exemplo.key -out exemplo.csr \
  -subj "/C=BR/ST=SP/L=Sao Paulo/O=ACME Inc/CN=exemplo.com" \
  -addext "subjectAltName=DNS:exemplo.com,DNS:www.exemplo.com"

Inspecione o resultado com openssl req -in exemplo.csr -noout -text. A saída enumera os mesmos campos que esta ferramenta extrai: Subject DN, algoritmo e tamanho da chave pública, lista de SAN, algoritmo de assinatura e a fingerprint do request.

Subject DN e a morte do Common Name

O Subject Distinguished Name é uma lista de RDNs separados por vírgula: CN (Common Name), O (Organização), OU (Unidade Organizacional), L (Localidade), ST (Estado), C (País, ISO 2 letras). Historicamente o CN carregava o domínio a ser protegido. Desde 2017 (Chrome 58) os navegadores ignoram o CN por completo e dependem exclusivamente da extensão Subject Alternative Names. Emitir um certificado sem SAN hoje é erro fatal em qualquer cliente moderno — sempre popule subjectAltName.

Wildcards, listas SAN e seus trade-offs

• Lista SAN — entradas DNS explícitas: DNS:api.exemplo.com, DNS:app.exemplo.com. Granular e a opção mais segura; logs de CT vão expor cada nome.
• Wildcard — *.exemplo.com bate em um único label (api, www) mas não em aninhados (a.b.exemplo.com) nem no apex (exemplo.com). Comprometer um host com certificado wildcard expõe todos os irmãos.
• Multi-domínio (UCC/SAN) — um cert único cobrindo apex domains não relacionados, útil em Microsoft Exchange e hospedagem compartilhada; caro em PKI comercial, grátis via Let's Encrypt.

Chaves, formatos e Certificate Transparency

Orientação atual: RSA 2048 mínimo (3072 recomendado pelo NIST após 2030); ECDSA P-256 é mais rápido, menor e tão seguro quanto. Os arquivos vêm em dois formatos: PEM (Base64 envolvido em -----BEGIN CERTIFICATE REQUEST-----, padrão do OpenSSL e de servidores Linux) e DER (binário cru, comum em Windows e keystores Java). Converta com openssl req -in csr.pem -outform der -out csr.der. Desde abr/2018 o Chrome exige que todo certificado publicamente confiável apareça em pelo menos dois logs de Certificate Transparency; você audita seu domínio em crt.sh ou no https://transparencyreport.google.com/https/certificates.

Perguntas frequentes

Preciso de root para gerar um CSR? Não — OpenSSL roda como usuário comum. Apenas proteja a chave privada (chmod 600 exemplo.key) e nunca commite em repositório.

Posso reusar um CSR antigo ao renovar? Tecnicamente sim, mas gerar um novo par de chaves a cada renovação é boa prática; uma chave vazada há anos é mais difícil de detectar que rotacionar com cadência. Let's Encrypt e clientes ACME fazem isso automaticamente por padrão.

O que é um certificado autoassinado? Aquele em que o emissor é a mesma entidade do subject — útil para desenvolvimento, serviços internos ou como root de uma PKI privada. Navegadores não confiam sem instalação manual. Gere com openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 365.

Let's Encrypt e ZeroSSL são mesmo grátis? Sim. Ambas são baseadas em ACME e emitem certificados de Domain Validation sem custo. Os certificados Let's Encrypt duram 90 dias e foram desenhados para serem renovados automaticamente por clientes como Certbot, acme.sh ou Caddy.