Decodificatore CSR (Richiesta di Firma del Certificato)

Incolla una CSR (richiesta di firma del certificato) in formato PEM per verificare all'istante CN, SAN, nome dell'organizzazione e algoritmo di chiave pubblica prima di inviarla a una CA. Strumento gratuito utile per individuare errori di compilazione prima dell'invio.

Cos'è il Decodificatore CSR

Il Decodificatore CSR è uno strumento gratuito che, a partire da una CSR (Certificate Signing Request, richiesta di firma del certificato) in formato PEM incollata dall'utente, elenca in un colpo d'occhio il Soggetto previsto per la richiesta (CN, nome dell'organizzazione, ecc.), il SAN (Subject Alternative Name), l'algoritmo di chiave pubblica e l'algoritmo di firma. Prima di inviare la richiesta a una CA (autorità di certificazione), permette di verificare all'istante che i dati compilati corrispondano esattamente a quanto previsto, senza dover ricorrere alla riga di comando OpenSSL.

Mentre lo strumento gemello "Decodificatore di Certificati SSL (X.509)" analizza certificati già emessi, questo strumento è pensato per la fase precedente all'emissione: la CSR stessa, prima ancora che la CA la esamini. È utile quando il certificato non è ancora stato rilasciato, oppure come controllo finale prima di generare una nuova coppia di chiavi.

Come usare il Decodificatore CSR

Incolla la tua CSR in formato PEM Incolla il testo che inizia con "-----BEGIN CERTIFICATE REQUEST-----" direttamente nel campo di testo, senza modificarlo.
Sono supportate anche più CSR insieme Incollando più CSR in un unico blocco, ciascuna viene rilevata e separata automaticamente.
Clicca sul pulsante "Analizza" Dopo aver verificato il numero di CSR rilevate, clicca sul pulsante per avviare l'analisi lato server.
Esamina i risultati Soggetto, SAN, algoritmo di chiave pubblica e algoritmo di firma vengono elencati per ciascuna CSR.

Consigli per sfruttarlo al meglio

Prima dell'invio, verifica sempre che sia il CN (Common Name) sia il SAN contengano tutti gli hostname che intendi effettivamente far emettere. Un SAN incompleto comporta quasi sempre la necessità di richiedere una riemissione.
Approfitta di questo momento per controllare che l'algoritmo di chiave pubblica non sia RSA sotto i 2048 bit o una curva EC ormai sconsigliata: individuare il problema qui evita un rifiuto in fase di revisione da parte della CA.
Prima di riutilizzare la stessa CSR su più server, ricontrolla che il nome dell'organizzazione e i domini in Soggetto e SAN corrispondano davvero alla richiesta che intendi presentare.
Questo strumento mostra soltanto quanto dichiarato nella CSR: quali SAN la CA emetterà realmente dipende dall'esito della sua revisione e può differire da quanto richiesto.

Quando usare questo strumento

Controllo finale prima dell'invio alla CA

Prima di acquistare un certificato SSL a pagamento, verifica che CN e SAN inseriti al momento della generazione della CSR siano corretti.

Verifica della procedura interna di generazione CSR

Controlla visivamente che una CSR generata con openssl req o strumenti simili corrisponda a quanto previsto, anche senza dimestichezza con la riga di comando.

Riesame di una CSR generata in passato

Riconsulta in modo sicuro il contenuto di una CSR conservata come file, senza dover maneggiare la chiave privata corrispondente.

Controllo di SAN mancanti su certificati multidominio

Quando più hostname vengono richiesti in un unico certificato, individua eventuali omissioni nel SAN prima di procedere con l'invio.

Glossario

CSR (Richiesta di Firma del Certificato): Abbreviazione di Certificate Signing Request. È l'insieme di dati — chiave pubblica e informazioni della richiesta come Soggetto e SAN — che viene presentato a una CA per richiedere l'emissione di un certificato.
CA (Autorità di Certificazione): Abbreviazione di Certificate Authority. È l'ente terzo che esamina il contenuto della CSR ed emette il certificato SSL/TLS effettivo.
CN (Common Name): Un campo del Soggetto che indica l'hostname o il nome del servizio principale a cui si riferisce il certificato. In passato i browser verificavano solo il CN, ma oggi la priorità è data al SAN.
SAN (Subject Alternative Name): Un'estensione che elenca hostname o indirizzi IP aggiuntivi per cui il certificato sarà valido. Nella fase di CSR viene registrata all'interno delle cosiddette "Requested Extensions" (estensioni richieste).
Requested Extensions: Le estensioni che il richiedente della CSR chiede vengano incluse al momento dell'emissione. Il SAN rientra tra queste, ma la CA non è tenuta a recepirle esattamente come indicato.
Algoritmo di chiave pubblica: Il metodo con cui è stata generata la chiave pubblica contenuta nella CSR. I più diffusi sono RSA ed EC (crittografia a curva ellittica), e la robustezza varia a seconda della lunghezza della chiave o della curva scelta.

Domande frequenti

Viene inviata al server una sola volta per essere analizzata, ma non viene salvata né registrata in modo permanente. La CSR non contiene la chiave privata, ma è comunque preferibile evitare di incollare dati della richiesta che preferiresti non rendere pubblici.

No. Questo strumento accetta esclusivamente CSR che iniziano con "-----BEGIN CERTIFICATE REQUEST-----". Non incollare mai una chiave privata in nessuno strumento online, incluso questo.

Le cause più comuni sono righe BEGIN/END mancanti, contenuto Base64 danneggiato, oppure aver incollato per errore un certificato o una chiave privata invece di una vera CSR.

Il Decodificatore di Certificati SSL analizza un certificato già emesso dalla CA, mentre questo strumento analizza la CSR, ossia la richiesta stessa nella fase precedente all'invio alla CA. Periodo di validità e impronte digitali non compaiono perché non esistono ancora a livello di CSR.

Nella maggior parte dei casi sì, ma la decisione finale spetta alla revisione della CA. Alcune CA ignorano il SAN presente nella CSR e danno invece priorità a quanto specificato nel modulo web al momento dell'ordine.

Curiosità — perché una CSR contiene già una firma

Osservando da vicino il contenuto di una CSR, si nota che dopo il Soggetto e le informazioni sulla chiave pubblica compaiono anche un algoritmo di firma e un valore di firma. A prima vista può sembrare strano: perché un documento che chiede a una CA "verificami come titolare" dovrebbe già contenere una firma propria? La risposta sta in un concetto chiamato Proof of Possession, ossia la prova del possesso della chiave privata. Firmando l'intera CSR (Soggetto, chiave pubblica e resto dei dati) con la chiave privata corrispondente alla chiave pubblica dichiarata nella richiesta, il richiedente dimostra alla CA di possedere realmente la chiave privata abbinata a quella chiave pubblica. Chi provasse a costruire una CSR inserendo la chiave pubblica di qualcun altro non riuscirebbe a produrre una firma valida senza disporre della chiave privata corrispondente, il che impedisce richieste fraudolente basate sull'identità altrui.

Il meccanismo della CSR fu definito nel 1986 come PKCS#10, uno degli standard della famiglia PKCS (Public-Key Cryptography Standards) sviluppata da RSA per la crittografia a chiave pubblica. Oggi la specifica è stata ridefinita dall'IETF come RFC 2986, ma nella pratica quotidiana il nome PKCS#10 resta ancora largamente in uso. Si tratta di un tassello poco appariscente nel mondo dei certificati TLS, eppure rappresenta il punto di partenza indispensabile dell'intero processo di emissione.

La possibilità di includere il SAN tra le Requested Extensions di una CSR è, in realtà, una standardizzazione relativamente recente. Lo standard originario della CSR (PKCS#10) prevedeva soltanto il Soggetto e poco più del CN; con la diffusione dei certificati multidominio e wildcard, ogni CA ha finito per adottare un proprio metodo per accettare il SAN. Oggi strumenti diffusi come OpenSSL supportano nativamente l'inserimento del SAN nella CSR tramite il meccanismo dell'Extension Request definito dalla RFC 2985, e anche questo strumento legge il SAN proprio da quella posizione standard, ossia dall'attributo extensionRequest all'interno degli Attributes della CSR.

Vedi tutte le curiosità