Signature numérique d’un fichier AIR

Le fait de signer numériquement vos fichiers d’installation AIR à l’aide d’un certificat délivré par une autorité de certification reconnue rassure pleinement vos utilisateurs sur l’état de l’application qu’ils installent : cette signature garantit que l’application n’a pas été modifiée accidentellement, ou intentionnellement dans le but de nuire, et vous identifie en tant signataire (éditeur). AIR affiche le nom de l’éditeur pendant l’installation lorsque l’application AIR est signée à l’aide d’un certificat approuvé ou lié par une chaîne de certificats à un certificat approuvé sur l’ordinateur utilisé pour l’installation :

Boîte de dialogue de confirmation de l’installation d’une application signée par un certificat approuvé

Si vous signez une application à l’aide d’un certificat auto-signé (ou d’un certificat qui n’est pas lié par une chaîne à un certificat approuvé), l’utilisateur doit accepter que les risques sécuritaires découlant de l’installation de l’application sont plus importants. La boîte de dialogue d’installation fait état de ces risques supplémentaires :

Boîte de dialogue de confirmation de l’installation d’une application signée par un certificat auto-signé
Important : des personnes mal intentionnées peuvent falsifier un fichier AIR en usurpant votre identité si elles obtiennent le fichier magasin de signatures ou découvrent votre clé privé.

Certificats développeur

Les obligations légales, restrictions et garanties de sécurité impliquant l’utilisation de certificats de signature de code sont brièvement exposées dans les déclarations des pratiques de certification – ou déclarations CPS (Certificate Practice Statements) – et les contrats d’abonnés publiés par l’autorité de certification émettrice. Pour plus d’informations sur les contrats des autorités de certification publiant actuellement des certificats développeurs AIR, voir les documents suivants :

ChosenSecurity (http://www.chosensecurity.com/products/tc_publisher_id_adobe_air.htm)

ChosenSecurity CPS (http://www.chosensecurity.com/resource_center/repository.htm)

GlobalSign (http://www.globalsign.com/code-signing/index.html)

GlobalSign CPS (http://www.globalsign.com/repository/index.htm)

Déclaration CPS de Thawte (http://www.thawte.com/cps/index.html) en anglais

Enoncé des pratiques de certification de VeriSign (EPC)4 (http://www.verisign.com/repository/CPS/)

Contrat d’abonnement de VeriSign (https://www.verisign.fr/repository/index.html)

A propos de la signature de code AIR

Lorsqu’un fichier AIR est signé, une signature numérique est ajoutée dans le fichier d’installation. La signature comprend un résumé du package, utilisé pour vérifier que le fichier AIR n’a pas été modifié depuis qu’il a été signé, et englobe des informations sur le certificat de signature qui permettent de vérifier l’identité de l’éditeur.

L’environnement AIR utilise l’infrastructure de clé publique (PKI) qui est prise en charge par le biais du magasin de certificats du système d’exploitation afin de déterminer la fiabilité d’un certificat. Pour que les informations de l’éditeur soient contrôlées, l’ordinateur sur lequel une application AIR est installée doit faire confiance directement au certificat utilisé pour signer l’application AIR, ou faire confiance à une chaîne de certificats liant ce certificat à une autorité de certification approuvée.

Si un fichier AIR est signé à l’aide d’un certificat n’appartenant pas à une chaîne le rattachant à l’un des certificats racines approuvés (et en règle générale ceci englobe tous les certificats auto-signés), les informations de l’éditeur ne peuvent pas être vérifiées. Si l’environnement AIR peut déterminer que le package AIR n’a pas été modifié depuis qu’il a été signé, il n’y a par contre aucun moyen de savoir qui est l’auteur et le signataire de ce fichier.

Remarque : un utilisateur peut choisir de faire confiance à un certificat auto-signé, dans ce cas toute application AIR signée à l’aide de ce certificat affiche le nom de l’éditeur en guise de valeur du champ de nom commun dans le certificat. L’environnement AIR ne fournit aucune possibilité à l’utilisateur de désigner un certificat comme étant approuvé. Le certificat (sans la clé privée) doit être fourni séparément à l’utilisateur et celui-ci doit utiliser l’un des moyens proposés par le système d’exploitation, ou tout autre outil approprié, pour importer le certificat à l’emplacement approprié dans le magasin de certificats du système.

A propos des identifiants d’éditeur AIR

Important : depuis la version 1.5.3 d’AIR, l’utilisation de l’identifiant d’éditeur est déconseillée et ce dernier n’est plus calculé à partir du certificat développeur. Les nouvelles applications ne requièrent plus d’identifiant d’éditeur et ne devraient pas l’utiliser. Lors de la mise à jour d’applications existantes, vous devez stipuler l’identifiant d’éditeur original dans le fichier descripteur d’application.

Avant la version 1.5.3 d’AIR, le programme d’installation d’une application AIR générait un identifiant d’éditeur lors de l’installation d’un fichier AIR. Cet identifiant était propre au certificat de signature du fichier AIR. Si vous réutilisiez le même certificat pour plusieurs applications AIR, le même identifiant d’éditeur leur était appliqué. La signature d’une mise à jour d’application par le biais d’un autre certificat, voire d’une occurrence renouvelée du certificat original entraînait la modification de l’identifiant d’éditeur.

Depuis la version 1.5.3 d’AIR, aucun identifiant d’éditeur n’est affecté par AIR. Le fichier descripteur d’une application publiée avec AIR 1.5.3 peut stipuler une chaîne d’identifiant d’éditeur. Ne stipulez d’identifiant d’éditeur que lors de la publication de mises à jour d’applications originellement associées aux versions d’AIR antérieures à 1.5.3. Si vous ne stipulez pas d’identifiant original dans le fichier descripteur d’application, le nouveau package AIR n’est pas traité comme une mise à jour de l’application existante.

Pour déterminer l’identifiant d’éditeur original, recherchez le fichier publisherid dans le sous-répertoire META-INF/AIR du répertoire d’installation de l’application originale. La chaîne que contient ce fichier correspond à l’identifiant d’éditeur. Le fichier descripteur de l’application doit stipuler le moteur d’exécution d’AIR 1.5.3 (ou version ultérieure) dans la déclaration d’espace de noms pour que vous puissiez stipuler manuellement l’identifiant d’éditeur.

S’il existe, l’identifiant d’éditeur est utilisé comme suit :

  • Dans la clé de chiffrement destinée au magasin local chiffré

  • Dans le chemin du répertoire de stockage d’application

  • Dans la chaîne de connexion associée aux connexions locales

  • Dans la chaîne d’identité destinée à appeler une application par le biais de l’API intégrée au navigateur d’AIR

  • Dans l’OSID (définition d’interface de service ouverte) utilisée lors de la création de programmes d’installation/de désinstallation personnalisés

Toute modification de l’identifiant d’éditeur entraîne un changement de comportement de toute fonctionnalité AIR basée sur celui-ci. Il devient, par exemple, impossible d’accéder aux données stockées dans le magasin local chiffré et la chaîne de connexion associée à toute occurrence de Flash ou d’AIR qui crée une connexion locale à l’application doit contenir le nouvel identifiant. L’identifiant d’éditeur d’une application installée ne doit pas être modifiée dans AIR 1.5.3 ou ultérieur. Si vous utilisez un autre identifiant d’éditeur lorsque vous publiez un package AIR, le programme d’installation traite le nouveau package comme une autre application plutôt qu’une mise à jour.

A propos des formats de certificats

Les outils de signature AIR acceptent tous les magasins de clés accessibles par l’intermédiaire de l’architecture de chiffrement Java, ou architecture JCA (Java Cryptography Architecture). Ceci englobe les fichiers de magasins de clés, comme les fichiers au format PKCS12 (utilisant généralement une extension de fichier .pfx ou p12), les fichiers .keystore de Java, les magasins de clés matériels PKCS11 et les magasins de clés système. Les formats de magasins de clés auxquels l’outil ADT peut accéder dépendent de la version et de la configuration du moteur d’exécution Java qui est utilisé pour exécuter cet outil. L’accès à certains types de magasins de clés, comme les jetons (périphériques de sécurité) matériels PKCS11, peut nécessiter l’installation et la configuration de pilotes logiciels et de modules d’extension JCA supplémentaires.

Pour signer des fichiers AIR, vous pouvez utiliser la plupart des certificats développeurs existants ou en obtenir un nouveau publié expressément pour la signature des applications AIR. Vous pouvez par exemple utiliser l’un des types de certificats suivants publiés par VeriSign, Thawte, GlobalSign ou ChosenSecurity :

  • ChosenSecurity

    • ID d’éditeur TC pour Adobe AIR

  • GlobalSign

    • Certificat développeur ObjectSign

  • Thawte :

    • Certificat de développeur AIR

    • Certificat de développeur Apple

    • Certificat de développeur JavaSoft

    • Certificat Microsoft Authenticode

  • VeriSign :

    • ID numérique Adobe AIR

    • ID numérique Microsoft Authenticode

    • ID numérique Sun Java Signing

Remarque : le certificat doit être créé pour la signature de code. Vous ne pouvez pas utiliser de certificat SSL ou d’autres types de certificats pour signer des fichiers AIR.

Horodatages

Lorsque vous signez un fichier AIR, l’outil de création de packages fait une demande auprès du serveur d’une autorité d’horodatage en vue d’obtenir une date et une heure de signature pouvant être vérifiées indépendamment. L’horodatage obtenu est incorporé au fichier AIR. Tant que le certificat utilisé pour la signature est valable au moment de cette signature, il est toujours possible d’installer le fichier AIR, même après l’expiration du certificat. Par contre, si aucun horodatage n’est obtenu, le fichier AIR perd toute possibilité d’installation lorsque le certificat expire ou est révoqué.

Par défaut, les outils de création de packages AIR obtiennent un horodatage. Cependant, afin de permettre la mise en package des applications malgré une indisponibilité du service d’horodatage, vous pouvez désactiver l’option d’horodatage. Adobe recommande la présence d’un horodatage dans tout fichier AIR distribué publiquement.

L’autorité d’horodatage par défaut qui est utilisée par les outils de création de package AIR est GeoTrust.

Obtention d’un certificat

Pour obtenir un certificat, il suffit généralement de se rendre sur le site Web de l’autorité de certification et de suivre la procédure d’acquisition indiquée par la société. Les outils utilisés pour élaborer le fichier de magasin de clés nécessaire aux outils AIR dépendent du type de certificat acheté, de la façon dont le certificat est stocké sur l’ordinateur receveur et, dans certains cas, du navigateur utilisé pour obtenir ce certificat. Par exemple, pour obtenir et exporter un certificat Adobe Developer publié par Thawte, vous devez utiliser Mozilla Firefox. Le certificat peut ensuite être exporté directement sous forme de fichier .p12 ou .pfx à partir de l’interface utilisateur de Firefox.

Remarque : la version 1.5 et les versions ultérieures de Java ne prennent pas en charge les caractères ASCII étendus dans les mots de passe de protection des fichiers de certificats PKCS12. Les outils de développement AIR font appel à Java pour créer les packages AIR signés. Si vous exportez le certificat au format .p12 ou .pfx, le mot de passe ne doit contenir que des caractères ASCII standard.

Vous pouvez générer un certificat auto-signé par le biais de l’outil ADT utilisé pour la mise en package des fichiers d’installation AIR. Il est également possible d’utiliser d’autres outils tiers.

Pour consulter la procédure de création d’un certificat auto-signé, ainsi que les instructions de signature d’un fichier AIR, voir Outil AIR Developer (ADT) . Vous pouvez également exporter et signer des fichiers AIR par l’intermédiaire de Flash Builder, Dreamweaver et de la mise à jour AIR pour Flash.

L’exemple suivant décrit la procédure d’obtention d’un certificat de développeur AIR auprès de l’autorité de certification Thawte, et sa préparation pour l’utiliser avec l’outil ADT.

Exemple : obtention d’un certificat de développeur AIR auprès de l’autorité Thawte

Remarque : cet exemple n’est qu’une illustration parmi les nombreuses possibilités disponibles pour acquérir et préparer un certificat de signature de code. Chaque autorité de certification possède ses propres stratégies et procédures.

Pour acquérir un certificat de développeur AIR, le site Web de Thawte nécessite l’utilisation du navigateur Firefox de Mozilla. La clé privée pour le certificat est stockée dans le magasin de clés du navigateur. Assurez-vous que le magasin de clés de Firefox est sécurisé à l’aide d’un mot de passe principal et que l’ordinateur lui-même est installé dans un endroit sûr et protégé. (Vous pouvez exporter et supprimer le certificat et la clé privée depuis le magasin de clés du navigateur une fois la procédure d’acquisition achevée.)

Au cours de la procédure d’inscription du certificat, une paire de clé privée/publique est générée. La clé privée est automatiquement stockée dans le magasin de clés Firefox. Vous devez utiliser le même navigateur sur le même ordinateur pour faire la demande d’un certificat sur le site Web de Thawte et procéder à sa récupération.

  1. Visitez le site Web de Thawte et affichez la Page Produits – Certificats développeur (signature de code) .

  2. A partir de la liste des certificats proposés, sélectionnez le certificat du développeur Adobe® Air™.

  3. Suivez les trois étapes de la procédure d’inscription. Vous devez fournir des informations sur votre organisation et les coordonnées de la personne à contacter. Thawte procède ensuite à l’opération du contrôle d’identité, ce qui peut faire l’objet d’une demande de renseignements complémentaires. Cette vérification achevée, un courrier électronique vous est adressé, il contient des instructions sur la procédure de récupération du certificat.

    Remarque : vous trouverez des informations supplémentaires sur la nature des documents à fournir en suivant ce lien : https://www.thawte.com/ssl-digital-certificates/free-guides-whitepapers/pdf/enroll_codesign_eng.pdf .

  4. Récupérez le certificat émis depuis le site Thawte. Le certificat est automatiquement enregistré dans le magasin de clés Firefox.

  5. Exportez un fichier de magasin de clés contenant la clé privée et le certificat à partir du magasin de clés Firefox en procédant comme suit :

    Remarque : lorsqu’ils sont exportés à partir de Firefox, la clé privée et le certificat sont transmis dans un format p12 (pfx) exploitable par l’outil ADT, Flex, Flash et Dreamweaver.

    1. Ouvrez la boîte de dialogue Gestionnaire de certificats :

    2. Sous Windows : ouvrez Outils > Options > Avancé > Chiffrement > Afficher les certificats.

    3. Sous Mac OS : ouvrez Firefox > Préférences > Avancé > Chiffrement > Afficher les certificats.

    4. Sous Linux : ouvrez Edition > Préférences > Avancé > Chiffrement > Afficher les certificats.

    5. Sélectionnez le certificat développeur Adobe AIR à partir de la liste des certificats et cliquez sur le bouton Sauvegarder .

    6. Entrez un nom de fichier et indiquez l’emplacement vers lequel exporter le fichier de magasin de clés, puis cliquez sur Enregistrer .

    7. Si vous utilisez la fonction de mot de passe principal de Firefox et que vous voulez exporter le fichier, vous êtes invité à préciser votre mot de passe pour le dispositif logiciel de sécurité. (Ce mot de passe n’est utilisé que par Firefox.)

    8. Dans la boîte de dialogue Choisir un mot de passe de sauvegarde du certificat , créez un mot de passe pour le fichier de magasin de clés.

      Important : ce mot de passe protège le fichier de magasin de clés et il est requis lorsque le fichier est utilisé pour signer des applications AIR. Votre choix devrait se porter de préférence sur un mot de passe sécurisé.

    9. Cliquez sur OK. Vous devriez recevoir un message de sauvegarde du mot de passe vous informant que l’opération a réussi. Le fichier de magasin de clés, qui contient la clé privée et le certificat, est sauvegardé au moyen d’une extension de fichier .p12 (au format PKCS12).

  6. Utilisez le fichier de magasin de clés exporté avec l’outil AIR Developer (ADT), Flash Builder, Flash Professional ou Dreamweaver. Le mot de passe créé pour le fichier est demandé chaque fois qu’une application AIR est signée.

Important : la clé privée et le certificat demeurent stockés dans le magasin de clés Firefox. Si cette procédure vous permet d’exporter un exemplaire supplémentaire du fichier de certificat, vous obtenez également un autre point d’accès qu’il faut absolument protéger pour préserver la sécurité de votre certificat et de votre clé privée.

Changement de certificats

Il s’avère parfois nécessaire de changer de certificat pour signer les mises à jour de l’application AIR. Cette opération est ainsi requise dans les circonstances suivantes :

  • Renouvellement du certificat développeur original

  • Mise à niveau à partir d’un certificat auto-signé vers un certificat émis par une autorité de certification

  • Changement d’un certificat auto-signé sur le point d’expirer

  • Changement d’un certificat commercial, par exemple lorsque les informations relatives à l’identité de votre société sont modifiées

Pour qu’AIR traite un fichier AIR comme une mise à jour, vous devez signer à la fois les fichiers AIR originaux et les fichiers AIR de mise à jour à l’aide du même certificat ou appliquer une signature de migration de certificat à la mise à jour. Une signature de migration est une seconde signature appliquée au package AIR de mise à jour à l’aide du certificat original. La signature de migration se base sur le certificat original pour attester que le signataire est bien l’éditeur original de l’application.

Lorsqu’un fichier AIR doté d’une signature de migration est installé, le nouveau certificat devient le certificat principal. Les mises à jour suivantes ne nécessitent pas de signature de migration. Dans la mesure du possible, vous devez toutefois continuer à appliquer des signatures de migration pour prendre en compte les utilisateurs qui n’effectuent pas toutes les mises à jour.

Important : vous devez changer de certificat et appliquer une signature de migration à la mise à jour avec le certificat original avant son expiration. Si vous n’effectuez pas cette procédure, les utilisateurs doivent désinstaller la version existante de l’application avant d’en installer une nouvelle version. Pour AIR 1.5.3 ou ultérieur, vous pouvez appliquer une signature de migration à l’aide d’un certificat arrivé à expiration dans les 365 jours qui suivent la date d’expiration. Il est toutefois impossible d’appliquer la signature d’application principale à l’aide du certificat arrivé à expiration.

Pour changer de certificats :

  1. Créez une mise à jour de votre application.

  2. Créez le package et signez le fichier AIR de mise à jour à l’aide du nouveau certificat.

  3. Signez le fichier AIR de nouveau au moyen du certificat original (grâce à la commande -migrate de l’outil ADT).

Un fichier AIR doté d’une signature de migration est, à d’autres égards, un fichier AIR tout à fait normal. Si l’application est installée sur un système vierge de toute version originale, l’environnement AIR installe la nouvelle version de la façon habituelle.

Remarque : avant la version 1.5.3 d’AIR, signer une application AIR à l’aide d’un certificat renouvelé ne nécessitait pas toujours une signature de migration. Depuis la version 1.5.3 d’AIR, les certificats renouvelés requièrent impérativement une signature de migration.

Pour appliquer une signature de migration, utilisez la Commande ADT migrate , comme le décrit la section Signature d’une version mise à jour d’une application AIR .

Remarque : La commande ADT migrate ne peut pas être utilisée avec les applications de bureau AIR incluant des extensions natives, car ces applications ont été mises en package comme des programmes d’installation natifs, pas comme des fichiers .air. Pour modifier les certificats pour une application AIR qui inclut une extension native, mettez l’application en package en utilisant la Commande ADT package avec l’indicateur -migrate.

Changement d’identité dans une application

Dans les versions d’AIR antérieures à 1.5.3, l’identité d’une application AIR changeait lors de l’installation d’une mise à jour à laquelle était appliquée une signature de migration. Modifier l’identité d’une application a diverses conséquences, à savoir :

  • La nouvelle version de l’application ne peut pas accéder aux données contenues dans le magasin local chiffré existant.

  • L’emplacement du répertoire de stockage de l’application change. Les données situées à l’ancien emplacement ne sont pas copiées dans le nouveau répertoire. (Par contre, la nouvelle application peut localiser le répertoire d’origine en fonction de l’ancien ID d’éditeur).

  • L’application ne peut plus ouvrir une seule connexion locale au moyen de l’ancien ID d’éditeur.

  • La chaîne d’identité permettant d’accéder à une application à partir d’une page Web change.

  • L’OSID (définition d’interface de service ouverte) de l’application change. (L’OSID est utilisée lors de la création de programmes d’installation/de désinstallation personnalisés.)

L’identité de l’application ne doit pas changer lors de la publication d’une mise à jour avec AIR 1.5.3 ou ultérieur. Le descripteur d’application du fichier AIR de mise à jour doit comporter les identifiants d’application et d’éditeur originaux. Le nouveau package n’est sinon pas traité comme une mise à jour.

Remarque : lorsque vous publiez une nouvelle application avec AIR 1.5.3 ou une version ultérieure, ne stipulez pas d’identifiant d’éditeur.

Terminologie

Cette section propose un glossaire des termes essentiels à votre compréhension lorsque vous décidez de signer une application pour la distribuer publiquement.

Terme

Description

Autorité de certification

Entité dans un réseau à infrastructure de clé publique qui sert de tiers de confiance et qui, en définitive, atteste de l’identité du propriétaire d’une clé publique. Normalement, une autorité de certification émet des certificats numériques, signés par sa propre clé privée, pour attester qu’elle a effectivement contrôlé l’identité du détenteur du certificat.

Déclaration des pratiques de certification (Déclaration CPS)

Présente les différentes pratiques et stratégies de l’autorité de certification dans l’émission et la vérification des certificats. La déclaration des pratiques de certification, ou déclaration CPS (Certification Practice Statement), fait partie intégrante du contrat qui lie l’autorité de certification avec ses abonnés et parties de confiance. Elle décrit également dans les grandes lignes les stratégies élaborées pour la vérification d’identité et le niveau des garanties offertes par les certificats fournis.

Liste de révocation de certificats

Liste des certificats émis qui ont été révoqués et qui ne devraient plus être considérés comme dignes de confiance. L’environnement d’exécution AIR vérifie la liste de révocation des certificats à la signature d’une application AIR et, si aucun horodatage n’est présent, renouvelle l’opération lorsque l’application est installée.

Chaîne de certificats

Une chaîne de certificats est une séquence de certificats dans laquelle chaque certificat présent a été signé par le certificat qui lui succède.

Certificat numérique

Document numérique contenant des informations sur l’identité du propriétaire, la clé publique du propriétaire et l’identité du certificat lui-même. Un certificat émis par une autorité de certification est lui-même signé par un certificat appartenant à l’autorité de certification émettrice.

Signature numérique

Résumé ou message chiffré ne pouvant être déchiffré qu’à l’aide de la paire clé publique et moitié de la clé publique-privée. Dans une infrastructure de clé publique (PKI), une signature numérique contient un ou plusieurs certificats numériques qui, en bout de chaîne, remontent jusqu’à l’autorité de certification. Une signature numérique peut servir à garantir qu’un message (ou un fichier informatique) n’a subi aucune modification depuis sa signature (dans les limites de la garantie fournie par l’algorithme de chiffrement utilisé) et, en admettant que l’autorité de certification émettrice soit jugée digne de confiance, à attester de l’identité du signataire.

Magasin de clés

Base de données contenant des certificats numériques et, dans certains cas, les clés privées associées.

architecture de chiffrement Java (architecture JCA)

Architecture extensible propre à la gestion et à l’accès des magasins de clés. Pour plus d’informations, voir le Guide de référence de l’architecture JCA .

PKCS #11

Norme de chiffrement d’interface pour jeton élaborée par RSA Laboratories. Un magasin de clés sur jeton (périphérique de sécurité) matériel.

PKCS #12

Norme décrivant la syntaxe des échanges d’informations personnelles élaborée par RSA Laboratories. Fichier de magasin de clés ; il contient habituellement une clé privée et son certificat numérique associé.

Clé privée

Système de chiffrement asymétrique de la moitié privée de la clé à deux composants public-privé. La clé privée doit être conservée dans un endroit secret et ne devrait jamais être transmise via un réseau. Les messages signés numériquement sont chiffrés par le signataire au moyen de la clé privée.

Clé publique

Système de chiffrement asymétrique de la moitié publique de la clé à deux composants public-privé. La clé publique est disponible sans réserve : elle sert à déchiffrer des messages chiffrés à l’aide de la clé privée.

Infrastructure de clé publique (PKI)

Système basé sur l’approbation dans lequel les autorités de certification garantissent l’identité des propriétaires de clés publiques. Les clients du réseau font confiance aux certificats numériques émis par une autorité de certification approuvée pour vérifier l’identité du signataire d’un message numérique (ou d’un fichier).

Horodatage

Donnée signée numériquement qui contient la date et l’heure auxquelles un événement est survenu. L’outil ADT peut englober un horodatage à partir d’un serveur de temps RFC 3161 (en anglais) dans un package AIR. Lorsqu’il est présent, l’environnement AIR utilise l’horodatage pour établir la validité d’un certificat au moment de la signature. Ceci permet l’installation d’une application AIR après l’expiration du certificat de signature.

Autorité d’horodatage

Organisation ayant autorité pour émettre des horodatages. Pour être reconnu par l’environnement AIR, l’horodatage doit être conforme au protocole RFC 3161 et la signature de cet horodatage doit être liée par une chaîne de certificats à un certificat racine de confiance sur l’ordinateur d’installation.

Certificats iOS

Les certificats développeurs délivrés par Apple permettent de signer les applications iOS, notamment celles qui sont développées dans Adobe AIR. Il est obligatoire d’appliquer une signature à l’aide d’un certificat de développement Apple pour installer une application sur un périphérique de test. L’application d’une signature par le biais d’un certificat de distribution est obligatoire pour distribuer l’application finalisée.

Pour signer une application, l’outil ADT doit pouvoir accéder au certificat développeur et à la clé privée associée. Le fichier de certificat en tant que tel ne comprend pas de clé privée. Vous devez créer un keystore sous forme de fichier d’échange d’informations personnelles (.p12 or .pfx) qui contient à la fois le certificat et la clé privée. Voir Conversion d’un certificat de développement en fichier de keystore P12 .

Génération d’une demande de signature de certificat

Pour obtenir un certificat de développement, vous générez une demande de signature de certificat, que vous envoyez au portail iOS Provisioning Portal d’Apple.

Le processus de demande de signature de certificat génère une paire clé publique-clé privée. La clé privée demeure sur l’ordinateur. Vous envoyez la demande de signature de certificat contenant la clé publique et les informations d’identification à Apple, qui fait office d’autorité de certification. Apple signe le certificat par le biais de son propre certificat WWDR (World Wide Developer Relations).

Génération d’une demande de signature de certificat sous Mac OS

Sous Mac OS, vous disposez de l’application Trousseau d’accès pour générer une demande de signature de code. L’application Trousseau d’accès réside dans le sous-répertoire Utilitaires du répertoire Applications. Vous trouverez des instructions de génération de la demande de signature de certificat sur le portail iOS Provisioning Portal d’Apple.

Génération d’une demande de signature de certificat sous Windows

Il est recommandé aux développeurs Windows d’obtenir le certificat de développement iPhone sur un ordinateur Mac. Il leur est toutefois possible d’obtenir ce certificat sous Windows. Commencez par créer une demande de signature de certificat (fichier CSR) par le biais d’OpenSSL en procédant comme suit :

  1. Installez OpenSSL sur l’ordinateur Windows. (Accédez à http://www.openssl.org/related/binaries.html .)

    Il sera peut-être nécessaire d’installer également les fichiers redistribuables Visual C++ 2008, recensés sur la page de téléchargement OpenSSL. (Il est toutefois inutile d’installer Visual C++ sur l’ordinateur.)

  2. Ouvrez une session de commande Windows et accédez au répertoire bin d’OpenSSL (c:\OpenSSL\bin\, par exemple).

  3. Créez la clé privée en entrant le texte ci-dessous sur la ligne de commande : 

    openssl genrsa -out mykey.key 2048

    Enregistrez cette clé privée. Vous en aurez besoin ultérieurement.

    Lorsque vous utilisez OpenSSL, tenez compte de tous les messages d’erreur. Même si OpenSSL génère un message d’erreur, il est possible que la sortie de fichiers continue. Ces fichiers risquent toutefois d’être inutilisables. Si des messages d’erreur sont générés, vérifiez la syntaxe et exécutez à nouveau la commande.

  4. Créez le fichier CSR en entrant le texte ci-dessous sur la ligne de commande : 

    openssl req -new -key mykey.key -out CertificateSigningRequest.certSigningRequest  -subj "/emailAddress=yourAddress@example.com, CN=John Doe, C=US"

    Remplacez l’adresse électronique, la valeur CN (nom du certificat) et la valeur C (pays) par vos coordonnées.

  5. Téléchargez le fichier CSR sur le site du centre des développeurs iPhone d’Apple . (Voir « Demande de certificat de développement iPhone et création d’un profil de configuration ».)

Conversion d’un certificat de développement en fichier de keystore P12

Pour créer un keystore P12, vous devez combiner le certificat de développement Apple à la clé privée associée dans un fichier unique. Le processus de création du fichier de keystore varie selon la méthode utilisée pour générer la demande de signature du certificat original et l’emplacement de stockage de la clé privée.

Conversion du certificat de développement iPhone en fichier P12 sous Mac OS

Une fois le certificat iPhone téléchargé d’Apple, exportez-le au format keystore P12. Procédez comme suit sous Mac® OS :

  1. Ouvrez l’application Trousseau d’accès (qui réside dans le dossier Applications/Utilitaires).

  2. Si vous n’avez pas encore ajouté le certificat au trousseau, sélectionnez Fichier > Importer. Accédez ensuite au fichier de certificat (fichier .cer) que vous avez obtenu d’Apple.

  3. Sélectionnez la catégorie Clés dans Trousseau d’accès.

  4. Sélectionnez la clé privée associée au certificat de développement iPhone.

    La clé privée est identifiée par le certificat public du développeur iPhone : <Prénom> <Nom> auquel elle est associée.

  5. Cliquez sur le certificat de développement iPhone en appuyant sur Commande et sélectionnez Export “iPhone Developer: Name...” .

  6. Enregistrez le keystore au format de fichier Échange d’informations personnelles (.p12).

  7. Vous serez invité à créer un mot de passe utilisé lorsque vous signez des applications par le biais du keystore ou lorsque vous transférez la clé et le certificat stockés dans ce keystore vers un autre keystore.

Conversion d’un certificat de développement Apple en fichier P12 sous Windows

Pour développer des applications AIR for iOS, vous devez disposer d’un fichier de certificat P12. Vous générez ce certificat à partir du fichier de certificat de développement iPhone envoyé par Apple.

  1. Convertissez le certificat de développement reçu d’Apple en certificat PEM. Exécutez l’instruction de ligne de commande suivante à partir du répertoire bin d’OpenSSL : 

    openssl x509 -in developer_identity.cer -inform DER -out developer_identity.pem -outform PEM

  2. Si vous utilisez la clé privée extraite du trousseau sur un ordinateur Mac, convertissez-la en clé PEM : 

    openssl pkcs12 -nocerts -in mykey.p12 -out mykey.pem

  3. Vous pouvez maintenant générer un fichier P12 valide basé sur la clé et la version PEM du certificat de développement iPhone : 

    openssl pkcs12 -export -inkey mykey.key -in developer_identity.pem -out iphone_dev.p12

    Si vous utilisez une clé issue du trousseau Mac OS, utilisez la version PEM générée à l’étape précédente. Si tel n’est pas le cas, utilisez la clé OpenSSL générée précédemment (sous Windows).