Come generare un CSR per un certificato di firma del codice tramite MMC

Lo snap-in Certificati nella Microsoft Management Console (MMC) può creare una richiesta di certificato PKCS #10 su una macchina Windows senza alcun software aggiuntivo. Questa guida illustra tale wizard schermata per schermata per un certificato di code signing, e inizia dalla parte che la maggior parte delle istruzioni più datate omette: le regole per le chiavi private di code signing sono cambiate il 1° giugno 2023, e sono proprio queste a determinare se una richiesta generata con MMC sia utilizzabile o meno.

Leggi questo requisito prima di aprire il wizard. Il resto della guida presuppone che tu sappia già quale percorso seguirà il tuo ordine.

Le chiavi di code signing devono essere generate su hardware

In base ai CA/Browser Forum Code Signing Baseline Requirements, in vigore dal 1° giugno 2023, la chiave privata di ogni certificato di code signing pubblicamente attendibile deve essere generata, conservata e utilizzata in un modulo crittografico hardware certificato almeno FIPS 140-2 Level 2, Common Criteria EAL 4+, o uno standard equivalente. Questo vale sia per i certificati standard (Organization Validation e Individual Validation) sia per quelli Extended Validation. I certificati EV code signing funzionavano già così; la modifica del 2023 ha esteso la stessa regola anche ai prodotti standard.

I requisiti fissano anche le caratteristiche della chiave stessa. Le chiavi RSA devono essere di almeno 3072 bit, le chiavi ECDSA devono usare le curve NIST P-256, P-384 o P-521, e SHA-1 non è consentito per i certificati di code signing.

Altrettanto importante, la Certificate Authority deve dimostrare che la chiave si trova realmente in hardware, utilizzando uno dei metodi elencati nei requisiti. Nella pratica, quelli che incontrerai sono i seguenti:

• La CA ti invia un token hardware che contiene già una coppia di chiavi generata dalla CA su quel dispositivo.
• Controfirmi la richiesta con un certificato del produttore, il che è esattamente il significato di attestazione della chiave: la prova che la chiave sia stata creata in modo non esportabile all’interno di un dispositivo conforme.
• Utilizzi una combinazione di libreria crittografica e modulo hardware prescritta dalla CA.
• Fornisci un audit IT, un report da un servizio di protezione delle chiavi in cloud, o un accordo che sottoscrivi tramite un servizio di firma conforme.

Nessuno di questi requisiti viene soddisfatto da una richiesta che MMC costruisce con il Microsoft Software Key Storage Provider. Quel provider crea la chiave nell’archivio software di Windows, quindi la richiesta risultante verrà rifiutata per un certificato di code signing pubblicamente attendibile, indipendentemente da come viene compilato il resto del wizard. Le Certificate Authority hanno inoltre smesso, nello stesso periodo, di offrire la generazione della chiave via browser e la consegna scaricabile in formato .pfx per questi prodotti.

Se il tuo obiettivo è un certificato pubblicamente attendibile, il percorso viene deciso al momento dell’ordine. O la CA genera la chiave su un token e te lo spedisce, nel qual caso non c’è alcuna CSR da creare, oppure generi la chiave su un dispositivo hardware che possiedi già e invii un’attestazione insieme alla richiesta. La guida metodi di consegna del certificato di code signing confronta le due opzioni, e i passaggi specifici per dispositivo si trovano qui:

• YubiKey 5 FIPS: generazione della CSR e attestazione
• Luna Network Attached HSM v7.x: guida a CSR e attestazione

Dove MMC resta utile

Il wizard non è obsoleto. È il provider che scegli al suo interno a decidere dove nasce la chiave, e ci sono tre situazioni in cui rimane lo strumento giusto.

Una richiesta basata su un provider hardware. L’elenco Cryptographic Service Provider nel wizard mostra ogni provider installato sulla macchina, non solo quelli software di Microsoft. Una volta installato il driver di un token o il minidriver di una smart card, anche il relativo provider comparirà in quell’elenco. La differenza sta in dove nasce la coppia di chiavi: un provider software la genera sul tuo computer, mentre un provider basato su hardware, come una smart card o un token, ordina al dispositivo di generare la coppia, e il dispositivo mantiene poi la chiave privata e ne controlla l’accesso. Selezionando un provider hardware, MMC produce una richiesta per una chiave che non è mai esistita in software.

Due avvertenze prima di fare affidamento su questo. MMC produce una richiesta PKCS #10 e nient’altro, quindi non genera il file di attestazione della chiave che la maggior parte delle Certificate Authority richiede insieme ad essa. Quello proviene dagli strumenti propri del dispositivo. E la CA decide quale metodo di verifica accetterà, e molte prescrivono la propria utility specifica per questo scopo. Chiedi alla tua CA quale percorso supporta prima di generare qualsiasi cosa, perché una chiave creata con lo strumento sbagliato non può essere spostata in seguito.

Una CA interna o aziendale. I Baseline Requirements regolano i certificati pubblicamente attendibili. Un certificato emesso dalla tua CA Active Directory Certificate Services per la firma interna esula da tale ambito, quindi è la tua policy a decidere come viene conservata la chiave, e un provider software è una scelta legittima. Ricorda però cosa ottieni: il codice firmato in questo modo è attendibile solo sulle macchine che già si fidano della tua root interna, mentre altrove Windows continuerà a considerare l’editore come sconosciuto.

Firma di test e preparazione. Una richiesta software va bene per un certificato di prova, e per definire i valori esatti del subject che riutilizzerai quando genererai la richiesta reale sul tuo hardware.

Passaggio 1: apri lo snap-in Certificati

Premi il tasto Windows + R, digita mmc e premi Invio. Puoi anche digitare mmc nella casella di ricerca della barra delle applicazioni e aprirlo da lì. Accetta la richiesta del Controllo account utente. Si apre una finestra Console1 vuota.

Fai clic su File, poi su Aggiungi/Rimuovi snap-in. Nell’elenco Snap-in disponibili seleziona Certificati e fai clic su Aggiungi.

Windows chiede a questo punto quale archivio certificati lo snap-in debba gestire: Il mio account utente, Account di servizio o Account computer. Questa scelta conta di più per un certificato di code signing rispetto a un certificato per server web, perché determina dove risiede la chiave e in quale archivio cercherà il tuo strumento di firma:

• Il mio account utente colloca la chiave nell’archivio personale dell’utente connesso. È la scelta abituale quando uno sviluppatore firma in modo interattivo, poiché il signtool di Microsoft apre per impostazione predefinita l’archivio Personale (My) dell’utente corrente.
• Account computer colloca la chiave nell’archivio della macchina, il che è adatto a un server di build dove la firma viene eseguita sotto un account di servizio. Gli strumenti di firma devono essere istruiti a cercare lì: signtool usa il parametro /sm per l’archivio della macchina.

Se scegli Il mio account utente, fai clic su Fine. Se scegli Account computer, fai clic su Avanti, lascia selezionato Computer locale (il computer su cui è in esecuzione questa console) e fai clic su Fine. In entrambi i casi, fai clic su OK per chiudere la finestra Aggiungi o rimuovi snap-in.

Due scorciatoie saltano completamente il passaggio dello snap-in quando non è necessaria una console salvata: certmgr.msc apre direttamente gli archivi certificati dell’utente corrente, e certlm.msc apre gli archivi del computer locale. Se hai creato manualmente la console e prevedi di riutilizzarla, usa File poi Salva per conservarla.

Passaggio 2: avvia una richiesta personalizzata

Nell’albero della console, espandi Certificati e fai clic con il pulsante destro sulla cartella Personale (o sulla cartella Certificati sottostante, se l’archivio contiene già dei certificati). Scegli Tutte le attività, poi Operazioni avanzate, quindi Crea richiesta personalizzata. Gli stessi comandi si trovano nel menu Azione, se preferisci.

Si apre il wizard Iscrizione certificati sulla schermata Prima di iniziare. Fai clic su Avanti.

Nella schermata Seleziona criteri di iscrizione certificati, cerca sotto l’intestazione Richiesta personalizzata e seleziona Procedi senza criteri di iscrizione, poi fai clic su Avanti. Ciò indica a Windows di costruire una richiesta autonoma per una CA esterna anziché iscriversi in base a un modello Active Directory.

La pagina Richiesta personalizzata presenta tre impostazioni:

• Modello. Scegli (Nessun modello) Chiave CNG. Questa opzione utilizza un Key Storage Provider, che è ciò con cui si registrano i provider hardware moderni. (Nessun modello) Chiave legacy utilizza i provider CryptoAPI più datati ed è necessaria solo quando un dispositivo o un’applicazione specifici la richiedono.
• Elimina estensioni predefinite. Lascia deselezionato a meno che tu non intenda inviare solo le estensioni impostate manualmente.
• Formato richiesta. Seleziona PKCS #10. Ogni CA lo accetta. CMC è destinato a richieste rivolte a sistemi che lo richiedono espressamente.

Fai clic su Avanti. Nella pagina Informazioni certificato vedrai una singola riga denominata Richiesta personalizzata con lo stato Disponibile. Fai clic sulla freccia Dettagli a destra di quella riga per espanderla, quindi fai clic sul pulsante Proprietà che appare. Si apre la finestra di dialogo Proprietà certificato con quattro schede: Generale, Soggetto, Estensioni e Chiave privata.

Passaggio 3: inserisci i dettagli del soggetto

Nella scheda Generale, digita un Nome descrittivo e, se vuoi, una Descrizione. Sono entrambe etichette locali che ti aiutano a ritrovare il certificato nell’archivio in seguito. Nessuna delle due fa parte della richiesta, e nessuna viene convalidata.

Passa alla scheda Soggetto. È qui che viene assemblata l’identità che comparirà come editore del software. Sotto Nome soggetto, scegli una voce dal menu a discesa Tipo, digita il testo corrispondente nella casella Valore, e fai clic su Aggiungi >. Ogni voce si sposta nell’elenco a destra, dove Windows la mostra in forma abbreviata (CN=, O=, OU=, L=, S=, C=). Ripeti per ciascuno dei seguenti elementi:

• Nome comune (CN): il nome registrato della tua organizzazione, o il nome legale completo dell’individuo per un certificato individuale. Questa è l’identità che gli utenti vedono quando Windows indica l’editore.
• Organizzazione (O): il nome registrato dell’organizzazione a cui appartiene il certificato. Se il nome contiene un simbolo come una “e commerciale” (&), scrivilo per esteso oppure ometti il simbolo, poiché questi caratteri non sono accettati nel campo. “AB & C Corporation” diventa “AB and C Corporation” o “ABC Corporation”.
• Unità organizzativa (OU): il reparto che gestisce l’iscrizione, ad esempio IT. Facoltativo.
• Località (L): la città in cui è registrata l’organizzazione.
• Stato (S): lo stato o la provincia, scritto per esteso. Usa Florida, non FL.
• Paese (C): il codice paese ISO a due lettere del luogo in cui è registrata l’organizzazione, ad esempio US.

Inserisci i dati esattamente come compaiono nei tuoi documenti legali, perché la CA li verifica rispetto a fonti pubbliche e ufficiali prima di emettere qualsiasi cosa. Una discrepanza è il motivo più comune per cui un ordine di code signing si blocca.

Lascia vuota la casella Nome alternativo. I Subject Alternative Name identificano i server tramite il nome host, mentre un certificato di code signing identifica un editore anziché una macchina, quindi non contiene alcuna voce DNS.

Passaggio 4: scegli il provider, la dimensione della chiave e l’hash

Apri la scheda Chiave privata. Contiene diversi gruppi comprimibili: Provider di servizi crittografici, Opzioni chiave, Seleziona algoritmo hash, Seleziona formato firma e Autorizzazioni chiave. Fai clic su un’intestazione per espanderla.

Espandi prima Provider di servizi crittografici, perché questa è l’impostazione che i Baseline Requirements attivano. L’elenco mostra ogni provider installato sulla macchina, ciascuno con una casella di controllo. Assicurati che l’unico selezionato sia il provider che desideri effettivamente utilizzare:

• Per un certificato di code signing pubblicamente attendibile, seleziona il provider appartenente al tuo token o HSM. Compare in questo elenco solo dopo che è stato installato il driver o il minidriver del dispositivo, quindi collega prima il dispositivo e installane il software.
• RSA, Microsoft Software Key Storage Provider è l’opzione software. Usala solo per una CA interna o un certificato di prova.
• L’elenco include anche voci ECDSA come ECDSA_P256, Microsoft Software Key Storage Provider. Conferma che la tua CA supporti ECDSA per il code signing prima di sceglierne una, poiché non tutti i prodotti lo fanno.

Espandi Opzioni chiave. Imposta Dimensioni chiave su 3072 o 4096. RSA 3072 è la soglia minima per il code signing, e una richiesta creata con 2048 verrà rifiutata. Se il menu a discesa non offre 3072 per il provider che hai scelto, usa 4096.

Nello stesso gruppo, lascia deselezionata l’opzione Chiave privata esportabile. Questa è la correzione più importante rispetto alle istruzioni MMC più datate. Una chiave esportabile può essere copiata dalla macchina come file .pfx, ovvero esattamente ciò che il requisito hardware esiste per impedire, e il percorso di attestazione certifica esplicitamente che la chiave è stata creata in modo non esportabile. L’unico caso in cui ha senso selezionarla è una configurazione di firma interna in cui è necessario spostare il certificato e la chiave su un’altra macchina, e anche in tal caso questo indebolisce la chiave. Lascia deselezionata anche Consenti archiviazione chiave privata. Protezione avanzata chiave privata è facoltativa e fa sì che Windows chieda conferma ogni volta che la chiave viene utilizzata, il che è ragionevole per una chiave di firma su una workstation condivisa.

Espandi Seleziona algoritmo hash e imposta Algoritmo hash su sha256. SHA-1 non è consentito per i certificati di code signing.

La scheda Estensioni merita un’occhiata se ti stai iscrivendo presso una CA interna. Espandi Utilizzo chiavi e aggiungi Firma digitale, quindi espandi Utilizzo chiavi avanzato (criteri applicazione) e aggiungi Firma del codice. Una CA pubblica costruisce il certificato in base al prodotto che hai ordinato piuttosto che alle estensioni presenti nella tua richiesta, quindi per un ordine pubblico questa scheda non cambia nulla. Una CA interna potrebbe invece rispettarla.

Fai clic su OK per chiudere Proprietà certificato, poi su Avanti.

Passaggio 5: salva la richiesta

Il wizard chiede Dove desideri salvare la richiesta offline? Fai clic su Sfoglia, scegli una cartella che controlli, assegna al file un nome come codesigning.req e conferma. Naviga sempre fino a una cartella anziché digitare un semplice nome file: senza un percorso, la richiesta finirà nella cartella da cui la console è in esecuzione, che raramente è dove desideri e che è difficile ritrovare in seguito.

Sotto Formato file, lascia selezionato Base 64. Questa è la forma testuale che le CA incollano in una casella di iscrizione. Binario scrive DER grezzo, che la maggior parte dei moduli d’ordine rifiuta. Fai clic su Fine.

Apri il file con un qualsiasi editor di testo semplice, come il Blocco note, e copia l’intero blocco comprese la prima e l’ultima riga:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEbDCCA1QCAQAwZDELMAkGA1UEBhMCVVMx...
...base64 encoded request...
-----END NEW CERTIFICATE REQUEST-----

Gli strumenti di iscrizione di Windows scrivono normalmente la dicitura più lunga mostrata sopra, con la parola NEW nelle righe delimitatrici, mentre OpenSSL scrive BEGIN CERTIFICATE REQUEST e END CERTIFICATE REQUEST. Se il tuo file utilizza la forma più breve, non c’è nulla di sbagliato: il contenuto è la stessa richiesta PKCS #10 e le Certificate Authority accettano entrambe le forme. Copia esattamente ciò che vedi e non riscrivere le righe delimitatrici.

Una cosa che il wizard non produce è un file di chiave privata da salvare o copiare, e le guide più datate che ti dicono di conservare al sicuro i file di chiave pubblica e privata descrivono uno strumento diverso. MMC mantiene la nuova chiave privata all’interno dell’archivio chiavi di Windows, sotto l’account che hai selezionato al passaggio 1, solo su quel computer. La richiesta in sospeso compare normalmente nello snap-in sotto Richieste di iscrizione certificati. Ne conseguono tre cose:

• Non eliminare la richiesta in sospeso mentre attendi l’emissione. Eliminandola, la chiave viene scartata, e il certificato emesso risulterà quindi inutilizzabile.
• Completa l’ordine sullo stesso computer, nello stesso contesto di account. Una richiesta generata nell’archivio utente non può essere completata nell’archivio macchina, né viceversa.
• Non ricostruire né reimmagini la macchina tra la generazione della richiesta e l’installazione del certificato.

Passaggio 6: controlla la richiesta prima di inviarla

Una richiesta non può essere modificata dopo la creazione, quindi controllala ora piuttosto che scoprire un errore di battitura dopo l’inizio della convalida. Windows può rileggerla senza alcun software aggiuntivo. Apri un Prompt dei comandi nella cartella che contiene il file ed esegui:

certutil -dump codesigning.req

Se OpenSSL è installato, questo comando legge lo stesso file e verifica anche la firma della richiesta:

openssl req -noout -text -verify -in codesigning.req

Conferma quattro cose nell’output: il soggetto elenca paese, stato, località, organizzazione e nome comune esattamente come previsto; la chiave pubblica è di 3072 bit o più, oppure su una curva ECDSA approvata; l’algoritmo di firma è SHA-256; e, con il comando OpenSSL, che compaia una riga verify OK, che conferma che la richiesta è stata firmata dalla chiave privata corrispondente. Puoi anche incollare il blocco nel decodificatore CSR per leggerlo direttamente nel browser.

Se qualcosa non va, genera una nuova richiesta a partire dal passaggio 2. Per vedere quali provider sono disponibili sulla macchina, inclusi quelli hardware che hai installato, esegui:

certutil -csplist

Passaggio 7: installa il certificato emesso sulla stessa macchina

Invia il blocco Base 64 durante l’ordine del certificato, completa la convalida richiesta dalla CA, e scarica il certificato emesso quando arriva. Poiché la chiave privata è rimasta nell’archivio chiavi di Windows, il certificato deve tornare nello stesso archivio per essere utilizzabile.

Nello stesso snap-in, fai clic con il pulsante destro su Personale, scegli Tutte le attività, poi Importa, e indica al wizard il file in questione. Windows abbina il certificato alla chiave conservata dalla richiesta, e la voce in sospeso sotto Richieste di iscrizione certificati scompare. Apri quindi il certificato e verifica che la scheda Generale indichi che possiedi una chiave privata corrispondente a questo certificato. Se questa riga manca, l’abbinamento non è avvenuto, e puoi ricollegarlo con il numero di serie del certificato:

certutil -repairstore My <serial-number>

Aggiungi il parametro -user se il certificato appartiene all’utente corrente anziché alla macchina:

certutil -user -repairstore My <serial-number>

Da questo punto, il tuo strumento di firma preleva il certificato dall’archivio. Ricorda l’archivio scelto al passaggio 1: signtool legge l’archivio Personale (My) dell’utente corrente a meno che tu non passi /sm per l’archivio della macchina.

Altri modi per creare la stessa richiesta sono trattati nelle guide CertReq, OpenSSL, Java Keystore e macOS Keychain Access. Potresti anche trovare utili i più ampi tutorial sul code signing o altri modi per generare una CSR.

Domande frequenti