Come generare un CSR per un certificato di Code Signing

Un certificato di code signing dimostra chi ha pubblicato un determinato software e attesta che il codice non è stato modificato dopo la firma. Per ordinarne uno, è necessario creare una CSR (Certificate Signing Request), il blocco di testo codificato che l’Autorità di Certificazione (CA) utilizza per identificarti ed emettere il certificato. Le CSR per il code signing seguono regole diverse rispetto a quelle create per un sito web, e tali regole sono cambiate nel 2023. Questa guida spiega la procedura attuale e i metodi che restano validi.

La chiave privata deve risiedere su hardware

Dal 1 giugno 2023, i Baseline Requirements per il Code Signing del CA/Browser Forum richiedono che la chiave privata di ogni certificato di code signing pubblicamente attendibile venga generata e memorizzata su hardware conforme allo standard FIPS 140-2 Level 2, Common Criteria EAL4+ o equivalente. Questo vale sia per i certificati standard (Organization Validation e Individual Validation) sia per i certificati Extended Validation (EV). Il code signing EV richiedeva già l’hardware prima di questa data; la modifica del 2023 ha estenso la stessa regola ai certificati standard.

La conseguenza pratica è importante: una chiave privata e una CSR generate esclusivamente tramite software, in un browser o in un semplice file su un laptop o server, non sono più accettate per un certificato di code signing pubblicamente attendibile. Le CA hanno interrotto il supporto alla generazione delle chiavi via browser e alla consegna scaricabile in formato .pfx per questi prodotti. La chiave deve avere origine, e rimanere, su un dispositivo conforme. Ciò lascia due percorsi validi:

• Un token hardware preconfigurato fornito dalla CA. La CA genera la coppia di chiavi e la CSR direttamente su un token USB certificato, installa su di esso il certificato emesso e ti spedisce il token. Firmi con il token collegato. Con questo metodo non generi tu stesso la CSR.
• Il tuo HSM o HSM cloud, con attestazione della chiave. Se disponi già di un Hardware Security Module conforme (o di un HSM cloud come AWS CloudHSM, Azure Dedicated HSM o Google Cloud HSM), generi la chiave e la CSR su tale dispositivo e fornisci un file di attestazione che dimostri alla CA che la chiave è stata creata su hardware conforme e non può essere esportata da esso.

La scelta del percorso viene effettuata al momento dell’ordine. Per un confronto diretto, consulta i metodi di consegna del certificato di code signing.

Opzione 1: token con spedizione (la CA crea la CSR)

Questo è il percorso scelto dalla maggior parte dei singoli utenti e dei piccoli team, poiché non richiede hardware proprio. Selezionando l’opzione token con spedizione al momento dell’acquisto, la CA si occupa della generazione della chiave e della creazione della CSR su un token certificato dal suo lato, quindi ti spedisce il token con il certificato già caricato. Non c’è alcuna CSR da inserire in un modulo d’ordine.

Ciò che devi fare invece:

• Completare le fasi di validazione richieste dalla CA (verifica dell’organizzazione o dell’identità).
• Attendere l’arrivo del token fisico.
• Installare i driver del token (in genere SafeNet Authentication Client) e firmare il software con il token collegato.

Opzione 2: genera la CSR sul tuo HSM o token

Se disponi già di hardware conforme, generi la coppia di chiavi e la CSR su quel dispositivo e fornisci un’attestazione corrispondente. I passaggi esatti dipendono dall’hardware, quindi segui la guida relativa al tuo dispositivo o la documentazione del tuo fornitore:

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

Per gli HSM cloud (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM), genera la chiave all’interno dell’HSM, esporta la CSR e il file di attestazione prodotto dalla piattaforma, e invia entrambi alla tua CA durante l’ordine.

Alcuni dettagli si applicano a tutte le CSR basate su hardware:

• Utilizza una chiave RSA di almeno 3072 bit, o una chiave ECDSA equivalente, come specificato dai Baseline Requirements.
• Contrassegna la chiave come non esportabile, in modo che non possa lasciare il dispositivo.
• Genera l’attestazione contemporaneamente alla chiave. Una CSR senza attestazione valida verrà rifiutata.

Dove si inseriscono ora i metodi OpenSSL, Java Keytool, MMC, CertReq e Keychain

Potresti aver visto istruzioni più datate che creano una CSR per il code signing con OpenSSL, l’utilità Java keytool, Microsoft Management Console (MMC), il comando Windows certreq, o Keychain Access su macOS. Utilizzati da soli, questi strumenti generano una chiave via software, quindi una CSR prodotta in questo modo non è valida oggi per un certificato di code signing pubblicamente attendibile.

Hanno ancora un ruolo quando vengono indirizzati verso hardware conforme piuttosto che verso un keystore software. Ad esempio, OpenSSL può creare una CSR su un HSM tramite un modulo PKCS#11, e CertReq o MMC possono costruire una richiesta che utilizza un provider di archiviazione chiavi hardware. Utilizza questi riferimenti solo in questo contesto, e associa sempre la richiesta all’attestazione del dispositivo:

• Genera una CSR per il code signing con OpenSSL
• Genera una CSR per il code signing con Java Keystore
• Genera una CSR per il code signing con CertReq
• Genera una CSR per il code signing con Microsoft Management Console
• Genera una CSR per il code signing con macOS Keychain Access

Verifica il contenuto della tua CSR

Prima di inviare una CSR, verifica che i dati del soggetto siano corretti. Se disponi di OpenSSL, decodifica la richiesta localmente e leggila in formato testo semplice:

openssl req -noout -text -in codesigning.csr

Controlla nell’output l’organizzazione o il nome comune e la dimensione della chiave. Un normale strumento di verifica della CSR per siti web non è adatto in questo caso, poiché una CSR per il code signing è legata all’hardware e viene validata tramite attestazione piuttosto che tramite una scansione HTTPS pubblica.

Domande frequenti