L'applicazione di una firma digitale ai file di installazione AIR mediante un certificato rilasciato da un'autorità di certificazione (CA) riconosciuta offre una garanzia significativa che l'applicazione in fase di installazione non sia stata alterata in modo casuale o intenzionalmente dannoso e identifica lo sviluppatore come firmatario (editore). Il nome dell'editore viene visualizzato durante l'installazione quando l'applicazione AIR è stata firmata con un certificato attendibile o che risulta
concatenato
a un certificato attendibile sul computer di installazione:
Finestra di conferma dell'installazione per un'applicazione firmata con un certificato attendibile
Se firmate un'applicazione utilizzando un certificato autofirmato (oppure un certificato non concatenato a un certificato attendibile), l'utente deve accettare un rischio di sicurezza maggiore installando l'applicazione. Nelle finestre di dialogo di installazione viene segnalato questo rischio aggiuntivo:
Finestra di conferma dell'installazione per un'applicazione firmata con un certificato autofirmato
Importante:
un'entità dannosa che abbia in qualche modo ottenuto il file di archivio chiavi per la firma dell'utente o che ne abbia scoperto la chiave privata può creare un file AIR con la vostra identità.
Certificati per la firma del codice
Le garanzie di sicurezza, i limiti e gli obblighi legali relativi all'utilizzo dei certificati per la firma del codice sono definiti nel CPS (Certificate Practice Statements) e negli accordi di sottoscrizione pubblicati dall'autorità di certificazione emittente. Per ulteriori informazioni sugli accordi per le autorità di certificazione che rilasciano certificati per la firma di codice AIR, vedete:
ChosenSecurity
(http://www.chosensecurity.com/products/tc_publisher_id_adobe_air.htm)
ChosenSecurity CPS
(http://www.chosensecurity.com/resource_center/repository.htm)
GlobalSign (www.globalsign.com/code-signing/index.html)
GlobalSign CPS
(http://www.globalsign.com/repository/index.htm)
Thawte CPS
(CPS Thawte) (http://www.thawte.com/cps/index.html)
VeriSign CPS
(http://www.verisign.com/repository/CPS/)
Verisign Subscriber’s Agreement
(Contratto di abbonamento a Verisign) (https://www.verisign.com/repository/subscriber/SUBAGR.html)
Informazioni sulla firma del codice AIR
Quando un file AIR viene firmato, nel file di installazione viene inclusa una firma digitale. Tale firma comprende un digest del pacchetto, usato per verificare che il file AIR non sia stato alterato dal momento della firma, e informazioni sulla firma del certificato, che consentono di verificare l'identità dell'editore.
Per stabilire se un certificato può essere ritenuto attendibile, AIR utilizza l'infrastruttura PKI (public key infrastructure, infrastruttura a chiave pubblica) supportata nell'archivio certificati del sistema operativo per stabilire l'attendibilità di un certificato. Il computer su cui l'applicazione AIR è installata deve ritenere direttamente attendibile il certificato utilizzato per la firma dell'applicazione AIR oppure deve considerare attendibile una catena di certificati che collegano il certificato stesso a un'autorità CA che verifichi le informazioni dell'editore.
Se un file AIR è firmato mediante un certificato non concatenato a uno dei certificati principali affidabili (e normalmente in questa categoria sono inclusi tutti i certificati autofirmati), le informazioni sull'editore non possono essere verificate. Anche se AIR può determinare che il pacchetto AIR non è stato alterato dal momento della firma, non c'è modo di sapere chi abbia effettivamente creato e firmato il file.
Nota:
un utente può scegliere di ritenere affidabile un certificato autofirmato e quindi in qualsiasi applicazione AIR firmata con quel certificato viene visualizzato il valore del campo del nome comune come nome dell'editore. In AIR non viene fornito alcun sistema per consentire a un utente di designare un certificato come attendibile. Il certificato (che non include la chiave privata) deve essere fornito all'utente separatamente, e quest'ultimo deve utilizzare uno dei meccanismi forniti dal sistema operativo oppure uno strumento appropriato per importare il certificato nella posizione adatta all'interno dell'archivio certificati del sistema.
Informazioni sugli ID editore AIR
Importante:
a partire da AIR 1.5.3 l'ID editore è stato dichiarato obsoleto e non viene più calcolato in base al certificato di firma del codice. Per le nuove applicazioni l'ID editore non è necessario e non deve essere specificato. Quando aggiornate un'applicazione esistente, dovete specificare l'ID editore originale nel file descrittore dell'applicazione.
Prima di AIR 1.5.3, il programma di installazione dell'applicazione AIR generava un ID editore durante l'installazione di un file AIR. Si trattava di un codice di identificazione univoco per il certificato utilizzato per firmare il file AIR. Se si riutilizzava lo stesso certificato per più applicazioni AIR, esse avevano tutte lo stesso ID editore. La firma di un aggiornamento dell'applicazione con un certificato differente e talvolta anche con un'istanza rinnovata del certificato originale modificava l'ID editore.
A partire da AIR 1.5.3, l'ID editore non viene più assegnato da AIR. Un'applicazione pubblicata con AIR 1.5.3 può specificare una stringa di ID editore nel descrittore dell'applicazione. Dovete specificare un ID editore solo quando pubblicate aggiornamenti per applicazioni originariamente pubblicate per versioni di AIR anteriori alla 1.5.3. Se non specificate l'ID originale nel descrittore dell'applicazione, il nuovo pacchetto AIR non viene considerato come aggiornamento dell'applicazione esistente.
Per determinare l'ID editore originale, individuate il file
publisherid
nella sottodirectory META-INF/AIR in cui è installata l'applicazione originale. La stringa contenuta in questo file è l'ID editore. Per specificare manualmente l'ID editore, dovete specificare il runtime AIR 1.5.3 (o successivo) nella dichiarazione namespace del file descrittore dell'applicazione.
L'ID editore, se presente, viene utilizzato per i seguenti scopi:
-
Come parte della chiave di crittografia per l'archivio locale crittografato
-
Come parte del percorso della directory di archiviazione dell'applicazione
-
Come parte della stringa di connessione per le connessioni locali
-
Come parte della stringa di identità utilizzata per chiamare un'applicazione con l'API AIR interna al browser
-
Come parte dell'identificatore OSID (utilizzato per la creazione di programmi di installazione/disinstallazione personalizzati)
Quando un ID editore viene modificato, cambia anche il comportamento delle funzioni AIR associate all'ID. Ad esempio, non è più possibile accedere ai dati presenti nell'archivio locale crittografato, ed eventuali istanze Flash o AIR che creano una connessione locale all'applicazione devono usare il nuovo ID nella stringa di connessione. L'ID editore per un'applicazione installata non può essere modificato in AIR 1.5.3 o versioni successive. Se utilizzate un ID editore diverso quando pubblicate un pacchetto AIR, il programma di installazione tratta il nuovo pacchetto come se fosse un'applicazione differente anziché un aggiornamento.
Informazioni sui formati dei certificati
Gli strumenti di firma di AIR accettano qualsiasi archivio di chiavi accessibile mediante Java Cryptography Architecture (JCA). Sono quindi inclusi gli archivi di chiavi basati su file quali i file in formato PKCS12 (che di solito hanno un'estensione pfx o p12), i file Java keystore, gli archivi di chiavi hardware PKCS11 e gli archivi di chiavi di sistema. Il formati degli archivi di chiavi a cui può accedere ADT variano in base alla versione e configurazione del runtime Java utilizzato per l'esecuzione di ADT. L'accesso ad alcuni tipi di archivi di chiavi, come ad esempio i token hardware PKCS1, potrebbe richiedere l'installazione e la configurazione di plugin JCA e di driver software aggiuntivi.
Per firmare i file AIR, potete utilizzare la maggior parte dei certificati esistenti per la firma di codice oppure ottenerne uno nuovo rilasciato appositamente per la firma di applicazioni AIR. Potete ad esempio utilizzare uno dei tipi di certificati seguenti di VeriSign, Thawte, GlobalSign o ChosenSecurity:
Nota:
il certificato deve essere creato per la firma di codice. Non potete utilizzare un certificato SSL o di altro tipo per firmare file AIR.
Indicatori di data e ora
Quando si appone la firma a un file AIR, lo strumento di creazione dei pacchetti interroga il server di un'autorità di indicazione di data e ora per ottenere una data e ora della firma verificabile a livello indipendente. L'indicatore di data e ora ottenuto viene incorporato nel file AIR. Fino a quando il certificato è valido per l'ora della firma, il file AIR può essere installato, anche se tale certificato è scaduto. D'altro canto, se non viene ottenuto alcun indicatore di data e ora, il file AIR non può più essere installato dopo la scadenza o la revoca del certificato.
Per impostazione predefinita, gli strumenti di creazione pacchetti di AIR ottengono un indicatore di data e ora. Tuttavia, per consentire la creazione di pacchetti delle applicazioni anche quando il servizio di indicazione di data e ora non è disponibile, è possibile disattivare la richiesta del servizio. Adobe raccomanda la presenza di indicatori di data e ora su tutti i file AIR distribuiti a livello pubblico.
L'autorità predefinita per ottenere gli indicatori di data e ora per gli strumenti di creazione pacchetti AIR è Geotrust.
Ottenere un certificato
Per ottenere un certificato, normalmente si visita il sito Web dell'autorità di certificazione per completare il processo di approvvigionamento della società. Gli strumenti utilizzati per produrre l'archivio di chiavi richiesto dagli strumenti AIR varia in base al certificato acquistato, alla modalità di memorizzazione del certificato sul computer dell'utente e, in alcuni casi, al browser impiegato per ottenere il certificato. Per ottenere ed esportare, ad esempio, un certificato di Adobe Developer da Thawte, è necessario utilizzare Mozilla Firefox. Il certificato può quindi essere esportato come file .p12 o .pfx direttamente dall'interfaccia di Firefox.
Nota:
le versioni Java dalla 1.5 in poi non accettano i caratteri high-ASCII nelle password utilizzate per proteggere i file di certificato PKCS12. Java viene utilizzato dagli strumenti di sviluppo di AIR per creare i pacchetti AIR firmati. Quando esportate il certificato come file .p12 o .pfx, utilizzate solo caratteri ASCII standard nella password.
Potete generare un certificato autofirmato mediante ADT (Air Development Tool), lo strumento utilizzato per creare pacchetti di file di installazione AIR. È possibile utilizzare anche alcuni strumenti di terzi.
Per istruzioni su come generare un certificato autofirmato e sulla firma di un file AIR, vedete
ADT (AIR Developer Tool)
. Potete inoltre esportare e firmare file AIR mediante Flash Builder, Dreamweaver e l'aggiornamento di AIR per Flash.
Nell'esempio seguente viene illustrato come ottenere un certificato per sviluppatori AIR dall'autorità di certificazione Thawte e prepararlo all'utilizzo in ADT.
Esempio: ottenere un certificato per sviluppatori AIR da Thawte
Nota:
nell'esempio viene illustrato solo uno dei vari sistemi per ottenere e preparare all'uso un certificato per la firma del codice. Ogni autorità di certificazione dispone di politiche e procedure distinte.
Per acquistare un certificato per sviluppatori AIR sul sito Web di Thawte, è necessario utilizzare Mozilla Firefox. La chiave privata per il certificato è memorizzata nell'archivio di chiavi del browser. Accertarsi che l'archivio di chiavi di Firefox sia protetto con una password master e che il computer stesso sia fisicamente sicuro. Una volta terminato il processo di approvvigionamento, è possibile esportare e rimuovere il certificato e la chiave privata dall'archivio di chiavi del browser.
Come parte del processo di registrazione del certificato, viene generata una coppia di chiavi pubblica/privata. La chiave privata viene memorizzata automaticamente nell'archivio di chiavi di Firefox. Per richiedere e quindi recuperare il certificato dal sito Web di Thawte, è necessario utilizzare lo stesso computer.
-
Visitate il sito Web di Thawte e andate alla
pagina del prodotto per i certificati per la firma del codice
.
-
Dall'elenco dei certificati per firma del codice, selezionate il certificato per sviluppatori AIR (Adobe AIR Developer Certificate).
-
Completate il processo di registrazione in tre fasi. Sarà necessario fornire informazioni di contatto e relative all'azienda. A questo punto, Thawte esegue il proprio processo di identificazione e potrebbe richiedere ulteriori informazioni. Al termine della verifica, poi, Thawte vi invierà un messaggio di posta elettronica con istruzioni su come recuperare il certificato.
-
Recuperate il certificato rilasciato dal sito Thawte. Esso viene salvato automaticamente nell'archivio di chiavi di Firefox.
-
Esportate un file dell'archivio di chiavi contenente la chiave privata e il certificato dall'archivio di chiavi di Firefox effettuando la seguente procedura:
Nota:
la chiave privata e il certificato in Firefox vengono esportati in un formato p12 (pfx) che anche ADT, Flex, Flash e Dreamweaver sono in grado di utilizzare.
-
Aprite la finestra di dialogo
Gestione certificati
di Firefox:
-
In Windows: aprite Strumenti -> Opzioni -> Avanzate-> Crittografia -> Mostra certificati
-
In Mac OS: aprite Firefox -> Preferenze -> Avanzate -> Crittografia -> Mostra certificati
-
In Linux: aprite Modifica -> Preferenze -> Avanzate -> Crittografia -> Mostra certificati
-
Selezionate il certificato per la firma del codice di AIR (Adobe AIR Code Signing Certificate) dall'elenco dei certificati, quindi fate clic sul pulsante
Backup
.
-
Immettete un nome file e il percorso in cui esportare il file dell'archivio di certificati, quindi fate clic su
Salva
.
-
Se utilizzate la password master di Firefox, per l'esportazione del file vi verrà richiesto di immettere la password per il dispositivo di sicurezza del software. Questa password è utilizzata solo da Firefox.
-
Nella
finestra di dialogo di scelta di una password di backup per il certificato
create una password per la protezione del file dell'archivio di chiavi.
Importante:
questa password protegge il file dell'archivio di chiavi ed è necessaria quando il file deve essere utilizzato per la firma di applicazioni AIR. Cercate di utilizzare una password sicura.
-
Fate clic su OK. Verrà visualizzato un messaggio di riuscita della creazione della password di backup. Il file dell'archivio di chiavi contente la chiave privata e il certificato viene salvato con un'estensione p12 (in formato PKCS12).
-
Potete utilizzare il file dell'archivio di chiavi esportato con ADT, Flash Builder, Flash Professional o Dreamweaver. La password creata per il file è necessaria ogniqualvolta viene apposta la firma a un'applicazione AIR.
Importante:
la chiave privata e il certificato vengono memorizzati nell'archivio di chiavi di Firefox. Ciò consente di esportare copie aggiuntive del file di certificato, ma implica anche la creazione di un ulteriore punto di accesso da proteggere per garantire la sicurezza di certificato e chiave privata.
Modifica dei certificati
In alcune circostanze dovete modificare il certificato utilizzato per firmare gli aggiornamenti dell'applicazione AIR. Ciò può avvenire, ad esempio, nei seguenti casi:
-
Rinnovo del certificato di firma originale.
-
Aggiornamento da un certificato autofirmato a un certificato rilasciato da un'autorità di certificazione
-
Passaggio da un certificato autofirmato sul punto di scadere a un altro
-
Passaggio da un certificato commerciale a un altro, ad esempio in caso di modifica della ragione sociale
Per consentire a AIR di riconoscere un file AIR come aggiornamento, dovete firmare sia i file originali che i file AIR di aggiornamento con lo stesso certificato oppure applicare una firma di migrazione certificato all'aggiornamento. Per firma di migrazione si intende una seconda firma apposta al pacchetto AIR di aggiornamento utilizzando il certificato originale. La firma di migrazione utilizza il certificato originale per stabilire che il firmatario è l'editore originale dell'applicazione.
Dopo che un file AIR con una firma di migrazione viene installato, il nuovo certificato diventa il certificato principale. Gli aggiornamenti successivi non richiedono una firma di migrazione. Tuttavia, è necessario applicare le firme di migrazione il più a lungo possibile per includere gli utenti che ignorano gli aggiornamenti.
Importante:
dovete sostituire il certificato e applicare una firma di migrazione all'aggiornamento con il certificato originale prima della sua scadenza. In caso contrario, gli utenti devono disinstallare la versione corrente dell'applicazione prima di installare una nuova versione. Con AIR 1.5.3 o versioni successive, potete applicare una firma di migrazione utilizzando un certificato scaduto entro un periodo di tolleranza di 365 giorni dalla scadenza. Non è tuttavia possibile utilizzare il certificato scaduto per applicare la firma principale dell'applicazione.
Per cambiare i certificati:
-
Create un aggiornamento dell'applicazione
-
Create un pacchetto e firmate il file di aggiornamento di AIR con il
nuovo
certificato.
-
Firmate nuovamente il file AIR con il certificato
originale
, mediante il comando
-migrate
di ADT.
Per altri aspetti, un file con firma di migrazione è un normale file di AIR. Se l'applicazione è installata su un sistema senza la versione originale, la nuova versione viene installata nella maniera consueta.
Nota:
prima di AIR 1.5.3, per firmare un'applicazione AIR con un certificato non era sempre necessario utilizzare una firma di migrazione. A partire da AIR 1.5.3, è sempre obbligatorio usare una firma di migrazione per i certificati rinnovati.
Per applicare una firma di migrazione utilizzate il
Comando ADT migrate
, come descritto in
Firma di una versione aggiornata di un'applicazione AIR
.
Nota:
il comando ADT migrate non può essere utilizzato con applicazioni desktop AIR che includono estensioni native, in quanto tali applicazioni sono inserite in un pacchetto come programmi di installazione nativi, non come file .air. Per modificare i certificati per un'applicazione desktop AIR che include un'estensione nativa, inserite in un pacchetto l'applicazione mediante il
Comando ADT package
con il flag -migrate.
Modifiche dell'identità dell'applicazione
Prima di AIR 1.5.3, l'identità di un'applicazione AIR cambiava quando veniva installato un aggiornamento firmato con una firma di migrazione. La modifica dell'identità di un'applicazione ha varie ripercussioni, tra cui:
-
La nuova versione dell'applicazione non è in grado di accedere ai dati nell'archivio locale crittografato esistente.
-
Il percorso della directory di memorizzazione dell'applicazione cambia. I dati nel vecchio percorso non vengono copiati nella nuova directory (la nuova applicazione, tuttavia, è in grado di individuare la directory originale in base al vecchio ID editore).
-
L'applicazione non è più in grado di aprire le connessioni locali mediante il vecchio ID editore.
-
La stringa di identità utilizzata per accedere a un'applicazione da una pagina Web cambia.
-
L'identificatore OSID dell'applicazione cambia. (L'OSID viene utilizzato per scrivere programmi di installazione/disinstallazione personalizzati.)
Quando si pubblica un aggiornamento con AIR 1.5.3 o versioni successive, l'identità dell'applicazione non può cambiare. Nel descrittore dell'applicazione del file AIR di aggiornamento è necessario specificare gli ID applicazione e editore originali. In caso contrario, il nuovo pacchetto non viene riconosciuto come aggiornamento.
Nota:
quando pubblicate una nuova applicazione AIR con AIR 1.5.3 o successivo, non dovete specificare un ID editore.
Terminologia
In questa sezione viene fornito un glossario della terminologia chiave, che è fondamentale conoscere per prendere decisioni in merito alla firma delle applicazioni per la pubblica distribuzione.
Termine
|
Descrizione
|
Autorità di certificazione (CA, Certification Authority)
|
Entità di una rete di infrastrutture di chiavi pubbliche che funge da terza parte attendibile e che certifica l'identità del proprietario di una chiave pubblica. Di norma, una CA rilascia certificati digitali firmati mediante la propria chiave privata per attestare l'avvenuta verifica dell'identità del possessore del certificato.
|
CPS (Certificate Practice Statement)
|
Documento che stabilisce le pratiche e le politiche dell'autorità di certificazione adottate in merito al rilascio e alla verifica dei certificati. Il CPS fa parte del contratto tra CA e le parti coinvolte. Definisce inoltre le politiche per la verifica dell'identità e il livello di garanzia offerto dai certificati forniti.
|
CRL (Certificate Revocation List)
|
Elenco di certificati rilasciati e successivamente revocati, che non possono più essere ritenuti affidabili. Nel momento in cui un'applicazione AIR viene firmata, AIR controlla l'elenco CRL. Se non è presente un indicatore di data e ora, il controllo viene ripetuto al momento dell'installazione dell'applicazione.
|
Catena di certificati
|
Per catena di certificati si intende una sequenza di certificati in cui ciascun certificato presente è stato firmato dal certificato successivo.
|
Certificato digitale
|
Documento digitale che contiene informazioni sull'identità del proprietario, la sua chiave pubblica e l'identità del certificato stesso. Un certificato rilasciato da un'autorità di certificazione è firmato a sua volta da un certificato appartenente alla CA che lo ha rilasciato.
|
Firma digitale
|
Messaggio o digest crittografato che è possibile decrittare solo mediante la chiave pubblica che costituisce metà della coppia di chiavi pubblica-privata. In un PKI, una firma digitale contiene uno o più certificati digitali di cui è possibile tenere traccia e che è possibile attribuire all'autorità di certificazione. Una firma digitale consente di convalidare la dichiarazione che un messaggio o un file non è stato alterato dal momento della firma (entro i limiti di garanzia forniti dall'algoritmo di crittografia utilizzato), nonché, presupponendo che l'autorità di certificazione sia considerata attendibile, l'identità del firmatario.
|
Archivio di chiavi
|
Database contenente certificati digitali nonché, in alcuni casi, le chiavi private correlate.
|
JCA (Java Cryptography Architecture)
|
Architettura estensibile per la gestione e l'accesso degli archivi di chiavi. Per ulteriori informazioni, vedete il documento
Java Cryptography Architecture Reference Guide
(Guida di riferimento per la Java Cryptography Architecture).
|
PKCS #11
|
Standard per l'interfaccia di token di crittografia creato da RSA Laboratories. Un archivio di chiavi basato su token hardware.
|
PKCS #12
|
Standard per la sintassi di scambio di informazioni personali creato da RSA Laboratories. Un archivio di chiavi basato su file che di solito contiene una chiave privata e il certificato digitale associato.
|
Chiave privata
|
La metà privata di una coppia di chiavi pubblica-privata a crittografia asimmetrica. La chiave privata deve essere tenuta segreta e non deve mai essere trasmessa su una rete. I messaggi con firma digitale vengono crittografati mediante chiave privata dal firmatario.
|
Chiave pubblica
|
La metà pubblica di una coppia di chiavi pubblica-privata a crittografia asimmetrica. La chiave pubblica è disponibile a tutti e viene usata per decrittare i messaggi crittografati mediante la chiave privata.
|
PKI (Public Key Infrastructure)
|
Sistema di attendibilità nel quale le autorità di certificazione attestano l'identità dei proprietari delle chiavi pubbliche. I client sulla rete si affidano ai certificati digitali rilasciati da una CA attendibile per verificare l'identità del firmatario di un messaggio digitale o file.
|
Indicatore di data e ora
|
Dato di riferimento a firma digitale contenente l'ora e il giorno in cui si è verificato un evento. ADT può includere un indicatore di data e ora proveniente da server temporale conforme alle specifiche
RFC 3161
in un pacchetto AIR. Quando è presente, AIR utilizza l'indicatore di data e ora per stabilire la validità di un certificato al momento della firma, consentendo in tal modo l'installazione di un'applicazione AIR anche dopo che il certificato di firma è scaduto.
|
Autorità di rilascio degli indicatori di data e ora
|
Autorità che rilascia indicatori di data e ora. Per essere riconosciuto da AIR, l'indicatore di data e ora deve essere conforme alle specifiche RFC 3161, mentre la firma dell'indicatore di data e ora deve concatenarsi a un certificato principale attendibile presente sul computer di installazione.
|
Certificati iOS
I certificati di firma del codice emessi da Apple vengono utilizzati per firmare le applicazioni iOS, comprese quelle sviluppate con Adobe AIR. L'applicazione di una firma mediante un certificato di sviluppo Apple è necessaria per installare un'applicazione su dispositivi di prova. L'applicazione di una firma mediante un certificato di distribuzione è invece richiesta per la distribuzione dell'applicazione finita.
Per firmare un'applicazione, ADT richiede l'accesso sia al certificato di firma del codice che alla relativa chiave privata. Il file del certificato non include la chiave privata. Dovete creare un archivio di chiavi sotto forma di file Personal Information Exchange (.p12 o .pfx) che contenga sia il certificato che la chiave privata. Vedete
Conversione di un certificato per sviluppatori in un file di archivio chiavi P12
.
Generazione di una richiesta di firma del certificato
Per ottenere un certificato per sviluppatori, dovete generare una richiesta di firma del certificato e inviarla al sito Apple iOS Provisioning Portal.
Il processo di richiesta della firma certificato genera una coppia di chiavi pubblica-privata. La chiave privata rimane sul vostro computer. Dovete inviare ad Apple, che svolge ruolo di autorità di certificazione, la richiesta di firma contenente la chiave pubblica e i vostri dati identificativi. Apple firma il vostro certificato con il proprio certificato World Wide Developer Relations.
Generare una richiesta di firma del certificato in Mac OS
In Mac OS, potete utilizzare l'applicazione Accesso Portachiavi per generare una richiesta di firma del certificato. L'applicazione Accesso Portachiavi si trova nella sottodirectory Utility della directory Applicazioni. Le istruzioni per la generazione della richiesta di firma certificato sono disponibili nel sito Apple iOS Provisioning Portal.
Generare una richiesta di firma del certificato in Windows
Per gli sviluppatori Windows, potrebbe essere più semplice ottenere il certificato per sviluppatori iPhone su un computer Mac. Tuttavia, è possibile ottenere un certificato su un computer Windows. Create, innanzitutto, un file CSR (Certificate Signing Request) utilizzando OpenSSL:
-
Installate OpenSSL sul computer Windows. (Visitate
http://www.openssl.org/related/binaries.html
.)
Potrebbe anche essere necessario installare i file ridistribuibili di Visual C++ 2008, elencati nella pagina di download di Open SSL. (
Non
è necessario che Visual C++ sia installato sul computer.)
-
Aprite una sessione di comandi Windows e passate alla directory bin OpenSSL (ad esempio, c:\OpenSSL\bin\).
-
Create la chiave privata immettendo l'istruzione seguente nella riga di comando:
openssl genrsa -out mykey.key 2048
Salvate questo file della chiave privata per utilizzarlo in seguito.
Quando utilizzate OpenSSL, non ignorate i messaggi di errore. Se OpenSSL genera un messaggio di errore, gli eventuali file creati non sono utilizzabili. In caso di errori, controllate la sintassi ed eseguite nuovamente il comando.
-
Create il file CSR immettendo l'istruzione seguente nella riga di comando:
openssl req -new -key mykey.key -out CertificateSigningRequest.certSigningRequest -subj "/emailAddress=yourAddress@example.com, CN=John Doe, C=US"
Sostituite l'indirizzo e-mail e i valori CN (nome certificato) e C (paese) con quelli personali.
-
Caricate il file CSR in Apple sul
sito per sviluppatori di iPhone
. (Vedete “Richiesta di un certificato per sviluppatori iPhone e creazione di un file di provisioning”.)
Conversione di un certificato per sviluppatori in un file di archivio chiavi P12
Per creare un archivio di chiavi P12, dovete combinare il certificato per sviluppatori Apple e la relativa chiave privata in un unico file. La procedura per la creazione del file di archivio chiavi dipende dal metodo che avete utilizzato per generare la richiesta di firma certificato originale e da dove è archiviata la chiave privata.
Convertire il certificato per sviluppatori iPhone in un file P12 in Mac OS
Dopo aver scaricato il certificato iPhone Apple da Apple, esportatelo nel formato di archivio chiavi P12. Per eseguire questa operazione in Mac® OS:
-
Aprite l'applicazione Accesso Portachiavi (nella cartella Applicazioni/Utility).
-
Se non avete già aggiunto il certificato a Portachiavi, selezionate File > Importa. Quindi passate al file di certificato (.cer) ottenuto da Apple.
-
Selezionate la categoria Chiavi nell'Accesso Portachiavi.
-
Selezionate la chiave privata associata al certificato di sviluppo iPhone.
La chiave privata è identificata dallo sviluppatore iPhone: <Nome> <Cognome> certificato pubblico con cui è associato.
-
Fate clic sul certificato di sviluppo iPhone tenendo premuto il tasto Comando e selezionate
Esporta "Sviluppatore iPhone: Nome..."
.
-
Salvate l'archivio di chiavi nel formato di file Personal Information Exchange (.p12).
-
Vi verrà richiesto di creare una password da specificare quando utilizzate l'archivio di chiavi per firmare applicazioni o trasferire la chiave e il certificato in questo archivio di chiavi o in un altro.
Convertire un certificato per sviluppatori di Apple in un file P12 in Windows
Per sviluppare applicazioni AIR for iOS, dovete usare un file di certificato P12. Questo file viene generato in base al certificato per sviluppatori iPhone Apple ricevuto da Apple.
-
Convertite il file di certificato per sviluppatori ricevuto da Apple in un file di certificato PEM. Eseguite l'istruzione della riga di comando seguente dalla directory bin di OpenSSL:
openssl x509 -in developer_identity.cer -inform DER -out developer_identity.pem -outform PEM
-
Se state utilizzando la chiave privata del portachiavi su un computer Mac, convertitela in una chiave PEM:
openssl pkcs12 -nocerts -in mykey.p12 -out mykey.pem
-
Potete ora generare un file P12 valido, basato sulla chiave e la versione PEM del certificato per sviluppatori iPhone:
openssl pkcs12 -export -inkey mykey.key -in developer_identity.pem -out iphone_dev.p12
Se state utilizzando una chiave del portachiavi Mac OS, utilizzate la versione PEM generata nel passaggio precedente. In caso contrario, utilizzate la chiave OpenSSL generata in precedenza (in Windows).
|
|
|