Porque usar este analisador?
Valide o que vai aparecer no seu certificado antes de o enviar a uma Autoridade de Certificação (CA). Detete um SAN em falta, uma chave fraca, um algoritmo obsoleto ou uma codificação IDN duvidosa. Poupe tempo durante a integração ou renovação lendo os campos úteis de imediato.
O que é um CSR?
Um Certificate Signing Request é um ficheiro de texto em formato PEM que contém:
- A sua chave pública (RSA ou EC)
- Informações de identidade: sujeito (CN, O, OU, L, ST, C) e SANs
- Uma assinatura feita com a sua chave privada para provar posse
O CSR é enviado a uma CA (Let's Encrypt, DigiCert, GlobalSign, Sectigo...) que emite o certificado se a validação passar (DV, OV ou EV).
Quando gerar um CSR?
| Caso de uso | Descrição |
|---|---|
| Novo certificado | Criar um certificado TLS para servidor web, API, MTA |
| Renovação | Renovar um certificado existente com um novo par de chaves |
| Adicionar SANs | Adicionar um novo subdomínio ou FQDN ao certificado |
| Migração RSA para EC | Mudar para chave EC para melhor desempenho |
| Padronização | Harmonizar campos numa infraestrutura heterogénea |
O que deve conter um bom CSR?
Campos obrigatórios
- SAN (Subject Alternative Names): lista de todos os nomes cobertos, incluindo o domínio nu se necessário. Sem SANs, muitas CAs rejeitarão.
- Chave pública: RSA 2048 bits mínimo (idealmente 3072) ou EC P-256/P-384
- Assinatura: SHA-256 recomendado (SHA-1 rejeitado)
Campos opcionais
- Subject CN: frequentemente ignorado pelas CAs modernas, mas mantenha por compatibilidade
- O, OU, L, ST, C: úteis para OV/EV, desnecessários para DV
- Key Usage / Extended Key Usage: dependendo das suas necessidades específicas
Importante: Um CN sozinho já não é suficiente. Os SANs são obrigatórios para a maioria das CAs.
Exemplos OpenSSL
CSR RSA 3072 com SANs
Ficheiro 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
Comando:
openssl req -new -newkey rsa:3072 -nodes -keyout site.key -out site.csr -config san.cnf
CSR EC P-256 com SANs
openssl ecparam -name prime256v1 -genkey -noout -out site.key
openssl req -new -key site.key -out site.csr -config san.cnf
Nomes de Domínio Internacionalizados (IDN)
Use punycode (xn--...) nos SANs para evitar surpresas de codificação.
Erros comuns
| Erro | Impacto | Solução |
|---|---|---|
| SANs em falta | Certificado cobre menos nomes do que esperado | Adicionar todos os domínios na secção [alt] |
| RSA 1024 ou SHA-1 | Provável rejeição pela CA | Usar RSA 2048+ e SHA-256 |
| Chave privada exposta | Comprometimento de segurança | Nunca colar chave privada online |
| Codificação IDN incorreta | Domínio não reconhecido | Usar punycode exato |
| Wildcard sem domínio nu | *.exemplo.com não cobre exemplo.com | Adicionar ambos nos SANs |
Boas práticas
- Gerar par de chaves do lado do servidor e manter chave privada longe de qualquer sistema partilhado
- Preferir EC P-256/P-384 ou RSA 3072+ para novas implementações
- Limitar a lista de SANs ao que é realmente necessário
- Manter um registo: data, sujeito, SANs, tamanho da chave, pessoa responsável
- Testar o CSR após geração para evitar trocas com a CA
Privacidade
O seu CSR é enviado à API CaptainDNS apenas para ser descodificado e exibido. O conteúdo não é armazenado. Nenhum campo é registado em texto claro. Apenas métricas técnicas anónimas são registadas (tempo de processamento, tamanho, tipo de chave, algoritmo) para monitorização de disponibilidade.