Vai al contenuto principale

Analizzatore di CSR

Ispeziona un CSR in pochi secondi

Valida ciò che apparirà sul tuo certificato SSL/TLS prima di inviarlo a un'Autorità di Certificazione. Rileva SAN mancanti, chiavi deboli o algoritmi obsoleti.

Decodifica istantanea

Incolla il tuo CSR e ottieni immediatamente soggetto, SAN, tipo di chiave e algoritmo di firma. Nessuna installazione richiesta.

Validazione pre-invio

Verifica che tutti i domini siano presenti nei SAN prima di inviare il CSR alla tua CA. Evita costosi scambi.

Analisi di sicurezza

Controlla la dimensione della chiave (RSA 2048+ o EC P-256/P-384) e l'algoritmo di firma (SHA-256 minimo) per rispettare gli standard attuali.

Rilevamento errori

Identifica problemi comuni: SAN mancanti, CN obsoleto, chiave debole, codifica IDN errata. Correggi prima dell'invio.

Esempi OpenSSL

Vedi i comandi OpenSSL per generare CSR RSA o EC con SAN. Copia, incolla e adatta al tuo dominio.

Perché usare questo analizzatore?

Valida ciò che apparirà sul tuo certificato prima di inviarlo a un'Autorità di Certificazione (CA). Rileva un SAN mancante, una chiave debole, un algoritmo obsoleto o una codifica IDN dubbia. Risparmia tempo durante l'onboarding o il rinnovo leggendo subito i campi utili.


Cos'è un CSR?

Un Certificate Signing Request è un file di testo in formato PEM che contiene:

  • La tua chiave pubblica (RSA o EC)
  • Informazioni di identità: soggetto (CN, O, OU, L, ST, C) e SAN
  • Una firma fatta con la tua chiave privata per dimostrare il possesso

Il CSR viene inviato a una CA (Let's Encrypt, DigiCert, GlobalSign, Sectigo...) che emette il certificato se la validazione passa (DV, OV o EV).


Quando generare un CSR?

Caso d'usoDescrizione
Nuovo certificatoCreazione di un certificato TLS per server web, API, MTA
RinnovoRinnovo di un certificato esistente con una nuova coppia di chiavi
Aggiunta SANAggiunta di un nuovo sottodominio o FQDN al certificato
Migrazione RSA a ECPassaggio a chiave EC per prestazioni migliori
StandardizzazioneArmonizzazione dei campi in un'infrastruttura eterogenea

Cosa deve contenere un buon CSR?

Campi obbligatori

  • SAN (Subject Alternative Names): elenco di tutti i nomi coperti, incluso il dominio nudo se necessario. Senza SAN, molte CA rifiuteranno.
  • Chiave pubblica: RSA 2048 bit minimo (idealmente 3072) o EC P-256/P-384
  • Firma: SHA-256 raccomandato (SHA-1 rifiutato)

Campi opzionali

  • Subject CN: spesso ignorato dalle CA moderne, ma mantienilo per compatibilità
  • O, OU, L, ST, C: utili per OV/EV, non necessari per DV
  • Key Usage / Extended Key Usage: a seconda delle tue esigenze specifiche

Importante: Un CN da solo non è più sufficiente. I SAN sono obbligatori per la maggior parte delle CA.


Esempi OpenSSL

CSR RSA 3072 con SAN

File 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

Comando:

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

Nomi di Dominio Internazionalizzati (IDN)

Usa punycode (xn--...) nei SAN per evitare sorprese di codifica.


Errori comuni

ErroreImpattoSoluzione
SAN mancantiIl certificato copre meno nomi del previstoAggiungere tutti i domini nella sezione [alt]
RSA 1024 o SHA-1Probabile rifiuto dalla CAUsare RSA 2048+ e SHA-256
Chiave privata espostaCompromissione della sicurezzaMai incollare la chiave privata online
Codifica IDN errataDominio non riconosciutoUsare punycode esatto
Wildcard senza dominio nudo*.esempio.com non copre esempio.comAggiungere entrambi nei SAN

Best practice

  1. Generare la coppia di chiavi lato server e tenere la chiave privata lontana da qualsiasi sistema condiviso
  2. Preferire EC P-256/P-384 o RSA 3072+ per nuove implementazioni
  3. Limitare la lista SAN a ciò che è effettivamente necessario
  4. Tenere un registro: data, soggetto, SAN, dimensione chiave, persona responsabile
  5. Testare il CSR dopo la generazione per evitare scambi con la CA

Privacy

Il tuo CSR viene inviato all'API CaptainDNS solo per essere decodificato e visualizzato. Il contenuto non viene memorizzato. Nessun campo viene registrato in chiaro. Vengono registrate solo metriche tecniche anonime (tempo di elaborazione, dimensione, tipo di chiave, algoritmo) per il monitoraggio della disponibilità.