Analizzatore di CSR

Perché analizzare un CSR prima di inviarlo?

Un decodificatore di CSR mostra dei campi. Risponde a «cosa c'è in questo file», mai alla domanda che si pone prima di pagare un certificato: la mia autorità di certificazione lo accetterà e, se no, perché.

Lo scarto è misurabile. Un Common Name assente dai SAN, un wildcard posto su *.co.uk, un underscore in un nome DNS, un nome in .local, un indirizzo IP privato nei SAN, oppure nessun SAN del tutto: altrettante richieste che un'autorità pubblica rifiuta e che i decodificatori sul mercato mostrano senza dire una parola.

Questo analizzatore decodifica il CSR integralmente, poi confronta ogni dato misurato con i CA/Browser Forum Baseline Requirements e con le RFC applicabili. Rende un verdetto a tre stati, conforme, avviso o non conforme, con i rilievi e la loro fonte. Il catalogo conta 59 codici; il numero di controlli eseguiti dipende dal CSR analizzato.

Tre usi che tornano di continuo:

• Prima dell'invio: correggere i punti bloccanti e inviare una sola volta il CSR giusto.
• Alla ricezione del certificato: verificare che provenga davvero da quel CSR, impronta di chiave pubblica alla mano.
• Riprendendo in mano una PKI ereditata: individuare nomi interni, chiavi corte e campi vietati.

Cosa contiene un CSR

Una Certificate Signing Request è un oggetto ASN.1 definito dall'RFC 2986, codificato in DER e poi trasportato in base64 dentro una busta PEM. Porta tre cose:

• una chiave pubblica, RSA o su curva ellittica, e solo quella;
• degli identificatori richiesti: il soggetto (CN, O, L, ST, C) e, dentro un attributo PKCS#9 chiamato extensionRequest, le estensioni desiderate tra cui i SAN;
• una firma prodotta con la chiave privata corrispondente.

I SAN non sono dunque un campo di primo livello: viaggiano dentro un attributo. È questo che spiega perché una configurazione openssl incompleta produca un CSR senza il minimo SAN senza che nulla protesti.

Cosa fa davvero la tua autorità di certificazione con il CSR

Ecco il punto che quasi tutti i decodificatori mancano: l'autorità ricostruisce il certificato, non ricopia il CSR. Genera lei stessa l'authorityInformationAccess, l'authorityKeyIdentifier, le certificatePolicies, l'extKeyUsage e persino il subjectAltName del certificato emesso. Un solo campo viene ripreso byte per byte: il SubjectPublicKeyInfo, la tua chiave pubblica e il suo identificatore di algoritmo.

È questo a dettare la gravità di ogni rilievo, ed è la taratura centrale dello strumento. Un contenuto diventa bloccante solo se rende impossibile un certificato conforme: chiave fuori profilo, chiave compromessa, identificatore illecito, oppure violazione dell'RFC 2986 da parte del CSR stesso. Tutto ciò che l'autorità sovrascrive o ignora, un'unità organizzativa o un'estensione esotica, si ferma al livello di avviso.

Cosa dimostra la firma e cosa non dimostra

La firma di un CSR stabilisce una cosa sola: al momento della creazione, l'autore deteneva la chiave privata associata alla chiave pubblica, e la terna soggetto, chiave e attributi non si è mossa da allora. Non dimostra alcun controllo del dominio, nessuna autorità del richiedente, nessuna garanzia di attualità (PKCS#10 non porta una marca temporale) e nessuna esclusività: la chiave può girare in un repository pubblico.

Una firma non valida non interrompe quindi l'analisi, è un rilievo tra gli altri, e la causa è spesso banale: troncamento nel copia e incolla, CSR ricodificato dal pannello di un provider di hosting. Lo strumento distingue tre stati e non due, valida, non valida e non verificabile; non accusa mai di alterazione un CSR che non è riuscito a verificare.

I rifiuti che una semplice decodifica non vede

Il CN deve figurare nei SAN

Il Common Name è facoltativo e sconsigliato nei profili attuali. Ma se è presente, deve riprendere esattamente uno dei valori del subjectAltName: un CN che non compare da nessuna parte nei SAN rende il certificato non conforme.

Il caso analogo è ancora più comune, il CSR senza alcun SAN. Con un CN, dipende da una ricostruzione benevola da parte dell'autorità, da evitare. Senza CN né SAN, l'autorità non ha nulla da validare e il rifiuto è certo.

I due livelli di regole sui wildcard

Il livello sintattico viene dall'RFC 9525: un solo wildcard, unico contenuto dell'etichetta più a sinistra. *.captaindns.com è valido; *.*.captaindns.com e www*.captaindns.com non lo sono, e un client conforme deve ignorare il nome. Il certificato verrebbe emesso, e poi risulterebbe inutilizzabile.

Il livello politico viene dai Baseline Requirements: un'autorità deve rifiutare un wildcard posto su un suffisso pubblico della sezione ICANN, *.co.uk per esempio. Sulla sezione privata della stessa lista, il rifiuto è solo una raccomandazione, da cui un semplice avviso.

Promemoria spesso dimenticato: un wildcard scende di un solo livello. *.captaindns.com non copre né captaindns.com né a.b.captaindns.com.

I nomi interni non sono più emettibili dal 2015

server.local, intranet.corp, nas.lan, localhost, un'etichetta unica senza punto, oppure un TLD assente dalla zona radice: sono nomi interni. La loro emissione è vietata dal 1° novembre 2015 e i certificati esistenti sono stati revocati d'ufficio il 1° ottobre 2016. Eppure si ritrovano ancora in CSR provenienti da vecchie PKI interne, riciclati verso un'autorità pubblica.

Stessa logica per gli indirizzi IP riservati nei SAN, che rientrino nell'RFC 1918, nel loopback, nel link local, nel CGNAT o negli ULA: un'autorità non valida ciò che non può raggiungere. Novità: dal 15 marzo 2026, anche un nome che termina con .in-addr.arpa o .ip6.arpa è vietato.

L'unità organizzativa è sparita dai certificati

Il campo organizationalUnit è vietato dal 1° settembre 2022, in applicazione del ballot SC047v2 adottato il 29 giugno 2021; il riferimento corrente al «ballot SC62» è inesatto. L'autorità non rifiuta per questo il CSR, rimuove il campo, da cui un avviso.

Un indirizzo di posta nel soggetto è deprecato dall'RFC 5280 e non ha alcuna destinazione legittima in un certificato TLS server. E un punto controintuitivo: un soggetto vuoto è conforme, e persino moderno. Il profilo a validazione di dominio accetta solo il paese, facoltativo, e il Common Name, sconsigliato.

Dimensioni delle chiavi, algoritmi e chiavi già compromesse

RSA 2048 resta conforme: 3072 bit è una raccomandazione con orizzonte 2030, segnalata a titolo informativo. Una firma in SHA-1 non è bloccante ai sensi dei Baseline Requirements, la cui clausola anti-SHA-1 riguarda gli oggetti firmati da un'autorità e non dal sottoscrittore; è classificata come avviso, con la sfumatura che in pratica le autorità la rifiutano dal 2016.

Due controlli vanno oltre. Sono i soli punti dei Baseline Requirements in cui è scritto che l'autorità deve respingere la richiesta:

• ROCA (CVE-2017-15361): le chiavi RSA prodotte da una libreria diffusa nelle smart card e nei TPM hanno una struttura riconoscibile che ne azzera l'entropia. Il rilevamento non fattorizza nulla, è un test di impronta sul modulus.
• Chiavi deboli Debian (CVE-2008-0166): tra settembre 2006 e maggio 2008, un generatore di casualità difettoso ha ridotto lo spazio delle chiavi a qualche decina di migliaia di valori per dimensione. La lista è integrata nel servizio e consultata offline.

In entrambi i casi, va rigenerata l'intera coppia di chiavi: riprendere la stessa chiave in un nuovo CSR riproporrebbe la debolezza.

L'impronta SPKI, quella che abbina tutto il resto

Tutti i decodificatori mostrano un'«impronta» del CSR. È l'hash dell'intero file: cambia se rigeneri il CSR con la stessa chiave, e non ha alcun rapporto con il certificato che riceverai.

L'impronta che serve è quella del SubjectPublicKeyInfo, definita dall'RFC 7469: l'hash SHA-256 della struttura di chiave pubblica codificata in DER. Essendo l'unico campo ricopiato byte per byte, lo stesso valore si ritrova nel CSR, nel certificato emesso e nella chiave privata corrispondente, e sopravvive a una riemissione.

Tre usi immediati: abbinare un certificato ricevuto al suo CSR, senza confrontare soggetti che l'autorità ha comunque riscritto; verificare in locale che la tua chiave privata sia quella giusta, con il comando riportato più avanti; comporre un record DANE 3 1 1, il cui selettore 1 è esattamente questa impronta, che il verificatore DANE/TLSA controlla poi nel DNS. L'impronta è pubblicata in esadecimale e in base64.

Confrontare il CSR con il certificato installato

Opzione facoltativa, deselezionata per impostazione predefinita: indica un host e l'analizzatore recupera il certificato che serve davvero, poi confronta le due impronte SPKI. Tre casi, stessa chiave, chiave diversa, oppure host irraggiungibile, quest'ultimo il più frequente visto che un CSR si analizza prima dell'emissione.

È l'unico percorso di rete dello strumento: casella deselezionata, nessuna connessione in uscita. Il risultato non entra mai nel verdetto di conformità, perché ciò che è installato altrove non dice nulla sulla validità di una richiesta, e nulla del CSR viene trasmesso all'host.

Per giudicare il certificato installato in sé, catena di fiducia e scadenza comprese, lo strumento dedicato è lo SSL Certificate Checker. Poi viene la gestione del ciclo di vita dei certificati, tanto più che la durata di validità scende a 47 giorni entro il 2029.

Comandi openssl utili

File san.cnf, senza il quale openssl produce un CSR privo di SAN:

[ req ]
prompt = no
distinguished_name = dn
req_extensions = v3_req
[ dn ]
CN = www.captaindns.com
[ v3_req ]
subjectAltName = @alt
[ alt ]
DNS.1 = www.captaindns.com
DNS.2 = captaindns.com

# RSA 3072
openssl req -new -newkey rsa:3072 -nodes -keyout captaindns.key -out captaindns.csr -config san.cnf

# ECDSA P-256
openssl ecparam -name prime256v1 -genkey -noout -out captaindns.key
openssl req -new -key captaindns.key -out captaindns.csr -config san.cnf

Calcolare l'impronta SPKI del CSR, del certificato ricevuto e della chiave privata, poi verificare che le tre coincidano, senza inviare nulla da nessuna parte:

openssl req  -in captaindns.csr -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
openssl x509 -in captaindns.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
openssl pkey -in captaindns.key -pubout       | openssl pkey -pubin -outform DER | openssl dgst -sha256

Per un dominio internazionalizzato, inserisci nei SAN la forma punycode (prefisso xn--): l'analizzatore mostra la forma Unicode a fianco e non invalida mai un'etichetta xn-- corretta.

Riservatezza

Non incollare mai la tua chiave privata, qui o altrove: un CSR porta solo la chiave pubblica. Un'intestazione PEM di chiave privata viene rilevata prima di qualsiasi invio e l'analisi è rifiutata sul posto. Se la chiave è già stata incollata in un modulo web, considerala compromessa e rigenera la coppia.

Il CSR, invece, non è un segreto: porta identificatori destinati a comparire in un certificato, pubblicato poi nei log di Certificate Transparency. Viene elaborato in memoria per essere analizzato e visualizzato. Unica eccezione, il valore dell'attributo challengePassword non viene mai restituito, né visualizzato, né registrato: viene segnalata solo la sua presenza.

FAQ - Domande frequenti

D: Che cos'è un CSR (Certificate Signing Request)?

R: Un file PKCS#10, trasportato in PEM, che porta la tua chiave pubblica, gli identificatori richiesti (soggetto e SAN) e una firma prodotta con la chiave privata corrispondente. Non contiene mai la chiave privata. Lo trasmetti a un'autorità di certificazione, che verifica il tuo controllo sui domini e poi emette il certificato.

D: Perché un'autorità di certificazione rifiuta un CSR?

R: Il più delle volte un Common Name assente dai SAN, un wildcard malformato o posto su un suffisso pubblico, un carattere illegale in un nome DNS (l'underscore in testa alla lista), un nome interno in .local o .corp, un indirizzo IP privato nei SAN, una chiave sotto i 2048 bit, oppure l'assenza totale di SAN.

D: Il Common Name deve figurare nei SAN?

R: Sì, non appena è presente: i Baseline Requirements impongono che riprenda esattamente uno dei valori del subjectAltName. La cosa più semplice resta non compilarlo, dato che i browser leggono solo i SAN ormai da anni.

D: Il mio CSR è firmato in SHA-1, è bloccante?

R: Non ai sensi dei Baseline Requirements: la clausola che vieta SHA-1 riguarda gli oggetti firmati con la chiave privata di un'autorità, mentre un CSR è firmato dal sottoscrittore. Lo strumento lo classifica come avviso. In pratica, le autorità pubbliche rifiutano i CSR in SHA-1 dal 2016, quindi rigeneralo in SHA-256. MD5 e MD2 sono bloccanti.

D: Bisogna compilare i campi O, OU, L e ST del soggetto?

R: No per un certificato a validazione di dominio: il profilo accetta solo il paese, facoltativo, e il Common Name, sconsigliato. Un soggetto vuoto è perfettamente conforme. L'unità organizzativa è addirittura vietata dal 1° settembre 2022.

D: A cosa serve l'impronta SPKI?

R: È l'hash SHA-256 della struttura di chiave pubblica, l'unico campo che un'autorità ricopia byte per byte dal CSR al certificato. Dimostra che un CSR, un certificato ricevuto e una chiave privata portano la stessa chiave, e serve da selettore 1 in un record DANE TLSA. L'impronta pubblicata dagli altri decodificatori riguarda l'intero file e non permette nessuno di questi confronti.

D: Il certificato già online corrisponde al mio CSR?

R: Seleziona l'opzione di confronto e indica l'host. L'analizzatore recupera il certificato servito e confronta la sua impronta SPKI con quella del CSR: stessa chiave, chiave diversa, oppure host irraggiungibile. Questo confronto non influisce mai sul verdetto di conformità e non trasmette nulla del CSR all'host interrogato.

D: Come generare un CSR con i SAN usando openssl?

R: Crea un file di configurazione che elenca DNS.1, DNS.2, ecc., poi lancia openssl req -new -newkey rsa:3072 -nodes -keyout captaindns.key -out captaindns.csr -config san.cnf. Per una chiave ellittica, genera prima la chiave con openssl ecparam -name prime256v1 -genkey -noout, poi richiama openssl req -new -key. Senza questo file, openssl produce un CSR privo di SAN.

Strumenti complementari

Risorse utili

• RFC 2986 - sintassi di richiesta di certificazione (struttura PKCS#10 del CSR)
• RFC 9525 - verifica dell'identità di servizio (regole sui wildcard, sostituisce l'RFC 6125)
• RFC 7469 - pinning di chiave pubblica (definizione normativa dell'impronta SPKI)
• CA/Browser Forum - Baseline Requirements (regole di emissione dei certificati TLS)