Propagação e diagnóstico

Compare resolvedores no mundo inteiro e inspecione as respostas devolvidas.

Analisador de CSR

Porque usar este analisador?

Valide o que vai aparecer no seu certificado antes de enviá-lo a uma autoridade.
Detete um SAN em falta, uma chave demasiado curta, um algoritmo fraco, uma codificação IDN suspeita.
Poupe tempo durante a integração ou renovação lendo imediatamente os campos úteis.

O que é um CSR?

Um Certificate Signing Request é um ficheiro de texto em formato PEM que contém:

  • a sua chave pública
  • informações de identidade do sujeito e SAN
  • uma assinatura feita com a sua chave privada para provar posse

O CSR é transmitido a uma AC—Let's Encrypt, DigiCert, GlobalSign…—que emite o certificado se a verificação passar: DV, OV, EV.

Quando gerar um CSR?

  • Criação ou renovação de um certificado TLS para servidor web, API, MTA
  • Adição de um novo subdomínio SAN, novo FQDN
  • Mudança de RSA para EC para melhor desempenho
  • Normalização de uma infraestrutura heterogénea onde os campos são inconsistentes

O que deve conter um bom CSR?

  • Subject CN às vezes ignorado pelas AC modernas, mantenha-o mas não confie apenas nele
  • SAN Subject Alternative Name a lista de todos os nomes cobertos, incluindo o domínio nu se necessário
  • Public Key tipo RSA 2048 mín, ideal 3072 ou EC P-256/P-384
  • Signature SHA-256 recomendado
  • Key Usage e Extended Key Usage opcionais de acordo com as suas necessidades

Lembrete
Sem SAN, muitas AC recusam. Um CN sozinho já não é suficiente.

Instruções

  1. Cole o CSR completo entre -----BEGIN CERTIFICATE REQUEST----- e -----END CERTIFICATE REQUEST-----.
  2. Clique em Analisar CSR.
  3. Leia o resumo: sujeito, SAN, tipo e tamanho da chave, algoritmo, impressões digitais.
  4. Corrija e regenere se algo estiver a bloquear.

Exemplos úteis de OpenSSL

CSR RSA 3072 com SAN

# san.cnf
[ req ]
prompt = no
distinguished_name = dn
req_extensions = v3_req
[ dn ]
CN = www.exemplo.com
[ v3_req ]
subjectAltName = @alt
[ alt ]
DNS.1 = www.exemplo.com
DNS.2 = exemplo.com
openssl req -new -newkey rsa:3072 -nodes -keyout site.key -out site.csr -config san.cnf

CSR EC P-256 com SAN

openssl ecparam -name prime256v1 -genkey -noout -out site.key
openssl req -new -key site.key -out site.csr -config san.cnf

IDN

Use punycode xn--… nos SAN para evitar surpresas.

Resolução de problemas e erros comuns

  • SAN em falta o certificado vai cobrir menos nomes do que o esperado
  • RSA 1024 ou SHA-1 provável recusa
  • Chave privada exposta nunca cole a chave privada aqui nem num ticket
  • Seletores de campo extravagantes O, OU, L, ST, C inúteis em DV e fontes de inconsistência em OV/EV
  • IDN mal codificado use punycode exato
  • Wildcard *.exemplo.com adicione também exemplo.com se quiser cobrir o domínio nu

Boas práticas

  • Gere o par de chaves do lado do servidor e mantenha a chave privada fora de qualquer partilha
  • Prefira EC P-256/P-384 ou RSA ≥ 3072 para novas implementações
  • Limite a lista de SAN ao que é realmente útil
  • Mantenha um registo: data, sujeito, SAN, tamanho da chave, pessoa de origem
  • Teste a leitura do CSR após a geração para evitar uma ida e volta com a AC

Compromisso de privacidade

O seu CSR é enviado para a API do CaptainDNS apenas para ser descodificado e exibido.
O conteúdo não é retido. Nenhum campo é registado em texto claro.
Apenas métricas técnicas anónimas são registadas: tempo de processamento, tamanho, tipo de chave e algoritmo para monitorização de disponibilidade.