Perché usare questo analizzatore?
Valida ciò che apparirà sul tuo certificato prima di inviarlo a un'autorità.
Rileva un SAN mancante, una chiave troppo corta, un algoritmo debole, una codifica IDN sospetta.
Risparmia tempo durante l'onboarding o il rinnovo leggendo immediatamente i campi utili.
Cos'è un CSR?
Un Certificate Signing Request è un file di testo in formato PEM che contiene:
- la tua chiave pubblica
- informazioni di identità del soggetto e SAN
- una firma fatta con la tua chiave privata per dimostrare il possesso
Il CSR viene trasmesso a una CA—Let's Encrypt, DigiCert, GlobalSign…—che emette il certificato se la verifica passa: DV, OV, EV.
Quando generare un CSR?
- Creazione o rinnovo di un certificato TLS per server web, API, MTA
- Aggiunta di un nuovo sottodominio SAN, nuovo FQDN
- Passaggio da RSA a EC per migliori prestazioni
- Normalizzazione di un'infrastruttura eterogenea dove i campi sono incoerenti
Cosa deve contenere un buon CSR?
- Subject CN a volte ignorato dalle CA moderne, mantienilo ma non fare affidamento solo su di esso
- SAN Subject Alternative Name l'elenco di tutti i nomi coperti, incluso il dominio nudo se necessario
- Public Key tipo RSA 2048 min, ideale 3072 o EC P-256/P-384
- Signature SHA-256 raccomandato
- Key Usage e Extended Key Usage opzionali secondo le tue esigenze
Promemoria
Senza SAN, molte CA rifiutano. Un CN da solo non è più sufficiente.
Istruzioni
- Incolla il CSR completo tra
-----BEGIN CERTIFICATE REQUEST-----e-----END CERTIFICATE REQUEST-----. - Clicca su Analizza CSR.
- Leggi il riepilogo: soggetto, SAN, tipo e dimensione della chiave, algoritmo, impronte digitali.
- Correggi e rigenera se qualcosa blocca.
Esempi utili di OpenSSL
CSR RSA 3072 con SAN
# san.cnf
[ req ]
prompt = no
distinguished_name = dn
req_extensions = v3_req
[ dn ]
CN = www.esempio.com
[ v3_req ]
subjectAltName = @alt
[ alt ]
DNS.1 = www.esempio.com
DNS.2 = esempio.com
openssl req -new -newkey rsa:3072 -nodes -keyout site.key -out site.csr -config san.cnf
CSR EC P-256 con SAN
openssl ecparam -name prime256v1 -genkey -noout -out site.key
openssl req -new -key site.key -out site.csr -config san.cnf
IDN
Usa punycode xn--… nei SAN per evitare sorprese.
Risoluzione dei problemi ed errori comuni
- SAN mancanti il certificato coprirà meno nomi del previsto
- RSA 1024 o SHA-1 probabile rifiuto
- Chiave privata esposta non incollare mai la chiave privata qui o in un ticket
- Selettori di campo fantasiosi O, OU, L, ST, C inutili in DV e fonti di incoerenza in OV/EV
- IDN codificato in modo errato usa punycode esatto
- Wildcard *.esempio.com aggiungi anche esempio.com se vuoi coprire il dominio nudo
Buone pratiche
- Genera la coppia di chiavi lato server e mantieni la chiave privata fuori da qualsiasi condivisione
- Preferisci EC P-256/P-384 o RSA ≥ 3072 per nuove distribuzioni
- Limita l'elenco SAN a ciò che è effettivamente utile
- Mantieni un registro: data, soggetto, SAN, dimensione della chiave, persona di origine
- Testa la lettura del CSR dopo la generazione per evitare un andata e ritorno con la CA
Impegno sulla privacy
Il tuo CSR viene inviato all'API CaptainDNS solo per essere decodificato e visualizzato.
Il contenuto non viene conservato. Nessun campo viene registrato in chiaro.
Vengono registrate solo metriche tecniche anonime: tempo di elaborazione, dimensione, tipo di chiave e algoritmo per il monitoraggio della disponibilità.