Come generare un CSR su Android

Questo tutorial mostra come generare una CSR (Certificate Signing Request) per Android con l’utility Java keytool.

Android non genera CSR TLS per CA pubbliche direttamente sul telefono: un certificato di CA pubblica viene emesso per un server (o un dispositivo controllato dall’utente), e le app e i browser Android lo consumano. Il flusso keytool descritto di seguito produce una richiesta PKCS #10 a partire da un keystore Java, che è il percorso corretto quando è necessario un certificato TLS che un’app Android o un sito web destinato al mobile dovrà considerare attendibile.

Scegli la procedura corretta per il tuo caso

“CSR per Android” può significare tre cose diverse. Assicurati di essere nella pagina giusta prima di eseguire qualsiasi comando:

• Un certificato TLS per un server con cui i client Android comunicheranno. Questo è il caso più comune, ed è quello trattato nel resto di questa pagina. Usa keytool (sotto) oppure genera la CSR fuori dal server con il nostro Generatore CSR, quindi installa il certificato emesso sul server web, sull’API gateway o sul broker MQTT raggiunto dalla tua app.
• Una chiave di firma per un APK o AAB. La firma delle app Android utilizza una chiave RSA o EC autofirmata in un keystore Java: non è coinvolta alcuna CA pubblica e non c’è alcuna CSR da inviare. Genera la chiave con keytool tramite la procedura guidata di Android Studio Build > Generate Signed Bundle / APK (oppure esegui keytool manualmente), quindi registra la chiave con Google Play App Signing. Non ordinare un certificato pubblico per questo scopo.
• Un certificato di dispositivo fornito da un MDM o EMM. Android Enterprise emette certificati client per i dispositivi gestiti tramite SCEP, EST o l’API Managed Configurations. La CSR viene generata e il certificato installato automaticamente dall’MDM. Non è richiesto alcun passaggio manuale con keytool.

Se il tuo caso è il primo, continua a leggere. Il flusso ha due parti: creare un keystore PKCS12 che contenga la chiave privata, quindi esportare la CSR da quel keystore.

Cosa ti serve

• Un’installazione Java (JDK o JRE) in modo che il comando keytool sia disponibile nel tuo PATH. Verifica con keytool -help. Su Windows, la cartella bin di Java deve essere nel PATH, oppure puoi eseguire keytool direttamente dalla directory bin del JDK.
• Il nome di dominio completo (FQDN) esatto che vuoi proteggere (per esempio www.iltuosito.com), oltre a qualsiasi altro nome host che vuoi includere nello stesso certificato (per l’elenco Subject Alternative Name).
• I dati legali della tua organizzazione (paese, stato, città, nome dell’organizzazione) per il Distinguished Name. Usa i valori esattamente come compaiono nei registri pubblici dell’azienda: la CA rifiuterà eventuali discrepanze.

Passaggio 1: Crea il keystore e la chiave privata

Se hai già generato la tua CSR, passa direttamente a inviare la CSR e poi alle istruzioni per l’installazione SSL su Android.

Apri un terminale (o il Prompt dei comandi su Windows) ed esegui il comando keytool riportato sotto. Crea un nuovo keystore in formato PKCS12, genera al suo interno una coppia di chiavi RSA a 2048 bit e memorizza la chiave sotto l’alias che scegli. PKCS12 è il formato di keystore predefinito a partire da JDK 9; il vecchio formato JKS è deprecato e dovrebbe essere evitato per le nuove chiavi.

keytool -genkeypair 
  -alias myalias 
  -keyalg RSA -keysize 2048 
  -storetype PKCS12 
  -keystore yoursite.p12 
  -validity 825

Su Windows, lo stesso comando su una sola riga è il seguente (nota il percorso assoluto, così potrai ritrovare facilmente il file):

keytool -genkeypair -alias myalias -keyalg RSA -keysize 2048 -storetype PKCS12 -keystore C:certsyoursite.p12 -validity 825

Cosa fanno i flag:

• -alias myalias: il nome della voce all’interno del keystore. Scegli un’etichetta che potrai riconoscere e annotala. Dovrai riutilizzare esattamente questo alias quando esporti la CSR e di nuovo quando importi il certificato firmato.
• -keyalg RSA -keysize 2048: una chiave RSA a 2048 bit è l’attuale minimo pubblico accettato da tutte le CA. Usa 3072 bit per una chiave con durata più lunga, oppure genera una chiave ECDSA con -keyalg EC -groupname secp256r1 per una chiave più piccola e più rapida (ogni CA moderna emette certificati su ECDSA P-256 e P-384).
• -storetype PKCS12: forza l’uso del moderno keystore PKCS12. L’estensione corrispondente è .p12 (o .pfx).
• -keystore yoursite.p12: il file keystore da creare. Sostituisci il nome con qualcosa che ricorderai facilmente, e conserva il file al sicuro: contiene la tua chiave privata.
• -validity 825: per quanto tempo è valido il certificato segnaposto autofirmato contenuto nel keystore. Il certificato firmato dalla CA lo sostituirà in seguito, quindi questo valore non influisce sulla durata in produzione.

keytool richiederà quindi una password del keystore. Scegli una password robusta e conservala nel tuo gestore di segreti. Ne avrai bisogno per ogni successivo comando keytool e per qualsiasi server che utilizza il keystore. Con i keystore PKCS12, la password della chiave coincide con quella del keystore, quindi c’è solo una password da ricordare.

Passaggio 2: Inserisci i dati della tua organizzazione (DN)

keytool chiederà ora il Distinguished Name (DN): i campi identificativi che compariranno nella CSR. Rispondi a ogni richiesta con il valore legale esatto della tua organizzazione. Usa solo caratteri ASCII standard: le lettere non latine invalidano la richiesta. Anche la punteggiatura conta, poiché la CA confronta i tuoi valori con i registri pubblici dell’azienda.

• What is your first and last name? È la formulazione usata da keytool per il Common Name (CN). Inserisci l’esatto FQDN che vuoi proteggere (per esempio www.iltuosito.com), oppure un wildcard come *.iltuosito.com. Non inserire il nome di una persona.
• What is the name of your organizational unit? Il CA/Browser Forum ha ritirato l’attributo organizationalUnitName il 01/09/2022, e le CA pubbliche lo rimuovono dai certificati emessi. Nota che premere Invio non lascia il campo vuoto: keytool sostituisce con un proprio valore predefinito, quindi il DN finisce per contenere OU=Unknown e questo valore finisce nella CSR. Per omettere davvero l’attributo, salta le richieste e passa il DN in linea con -dname, escludendo OU dalla stringa.
• What is the name of your organization? Inserisci il nome legale completo della tua azienda, esattamente come registrato (per esempio Your Company LLC). Richiesto per i certificati OV ed EV; per i certificati Domain Validation (DV) il valore viene ignorato, quindi qualsiasi segnaposto breve funziona.
• What is the name of your city or locality? Scrivi il nome completo della città in cui la tua azienda è registrata (per esempio Seattle, non SEA).
• What is the name of your state or province? Inserisci il nome completo dello stato o della provincia (per esempio California, non CA).
• What is the two-letter country code for this unit? Inserisci il codice ISO 3166-1 alpha-2 a due lettere (per esempio US, GB, DE). Consulta l’elenco ufficiale ISO se non sei sicuro.

keytool stamperà il DN assemblato e chiederà Is CN=…, OU=…, O=…, L=…, ST=…, C=… correct? Digita yes e premi Invio per confermare. Se noti un errore, digita no e keytool riavvierà le richieste.

Passaggio 3: Esporta la CSR con un Subject Alternative Name

Ora esporta la CSR con keytool -certreq. Ogni CA pubblica valida il nome host confrontandolo con l’estensione Subject Alternative Name (SAN), non con il Common Name (i browser e le librerie TLS moderne hanno smesso di controllare il CN da anni), quindi includi sempre un SAN, anche per un singolo nome host. Usa lo stesso alias impostato nel Passaggio 1:

keytool -certreq 
  -alias myalias 
  -file certreq.csr 
  -keystore yoursite.p12 
  -ext SAN=DNS:www.yoursite.com,DNS:yoursite.com

Su Windows, lo stesso comando su una sola riga:

keytool -certreq -alias myalias -file certreq.csr -keystore C:certsyoursite.p12 -ext SAN=DNS:www.yoursite.com,DNS:yoursite.com

Aggiungi una voce DNS: per ogni nome host se stai creando un certificato multi-dominio (separale con virgole, senza spazi). Per un wildcard, usa DNS:*.iltuosito.com. keytool richiederà la password del keystore, quindi scriverà la CSR nel file certreq.csr nella directory corrente.

Passaggio 4: Apri la CSR e inviala alla CA

Apri certreq.csr con un qualsiasi editor di testo (Blocco note, TextEdit, nano, vim). Puoi anche visualizzarlo direttamente nel terminale:

cat certreq.csr

Sul Prompt dei comandi di Windows:

type certreq.csr

Vedrai un blocco simile a questo:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIDXjCCAkYCAQAwgZQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
... (many lines of base64) ...
-----END NEW CERTIFICATE REQUEST-----

Seleziona l’intero blocco, incluse le righe BEGIN NEW CERTIFICATE REQUEST e END NEW CERTIFICATE REQUEST (alcune CA le etichettano BEGIN CERTIFICATE REQUEST / END CERTIFICATE REQUEST: entrambe le etichette sono accettate). Copialo e incollalo nel campo CSR del tuo modulo d’ordine.

Verifica la CSR prima di inviarla (opzionale)

Vale la pena confermare il Common Name, le voci SAN e la dimensione della chiave prima di inviare la richiesta alla CA. keytool stampa le stesse informazioni relative alla voce del keystore:

keytool -printcertreq -file certreq.csr

Preferisci uno strumento online? Incolla il contenuto della richiesta nel Decoder CSR di SSL Dragon per leggere il soggetto, l’elenco SAN e i parametri della chiave pubblica. Verifica che il Common Name corrisponda al nome host che i client utilizzeranno e che ogni nome richiesto compaia nell’elenco Subject Alternative Name.

Android considererà attendibile il certificato emesso?

Sì, per qualsiasi certificato firmato da una CA pubblicamente attendibile. Android include un archivio di sistema di certificati radice che rispecchia gli elenchi di attendibilità dei principali browser, quindi un certificato emesso sotto una di quelle radici è considerato attendibile da Chrome, WebView e qualsiasi app che utilizza l’archivio di attendibilità di sistema, senza alcuna configurazione aggiuntiva.

Due avvertenze utili da conoscere se stai anche installando il certificato (o una radice di CA privata) sul dispositivo stesso:

• Le CA installate dall’utente sono ignorate dalle app su Android 7 e versioni successive. A partire da Android 7 (Nougat), per impostazione predefinita solo l’archivio di sistema è considerato attendibile dal traffico delle app, e anche Google Chrome ignora le CA installate dall’utente. Se la tua app deve considerare attendibile una CA privata, lo sviluppatore deve abilitarlo esplicitamente tramite una configurazione della sicurezza di rete che includa <certificates src="user" />. I certificati di CA pubbliche non richiedono questo passaggio: sono già presenti nell’archivio di sistema.
• Aggancia il pinning a un identificatore stabile, non a un singolo certificato. Se implementi il certificate pinning nella tua app, aggancialo all’hash SPKI della chiave pubblica o alla CA emittente, non a un certificato leaf specifico. Altrimenti il rinnovo successivo bloccherà l’accesso agli utenti.

Prossimi passi

Dopo che la CA ha validato la CSR e ha emesso il tuo certificato, importa il certificato emesso di nuovo nello stesso keystore (sotto lo stesso alias), quindi distribuisci il keystore sul server che i client Android raggiungeranno. Consulta la nostra guida all’installazione SSL su Android per i passaggi di installazione sul dispositivo, oppure le guide di installazione specifiche per piattaforma disponibili in come installare un certificato SSL se il tuo back-end funziona su Tomcat, JBoss, Nginx o un altro server.