AIR-bestanden digitaal ondertekenen

Als u uw AIR-installatiebestanden digitaal ondertekent met een certificaat dat is uitgegeven door een erkende certificeringsinstantie (CA), hebben uw gebruikers een goede garantie dat de toepassing die zij installeren niet per ongeluk of met boze opzet is gewijzigd en weten zij dat u de ondertekenaar (uitgever) bent. De uitgeversnaam wordt tijdens de installatie weergegeven wanneer de AIR-toepassing is ondertekend met een certificaat dat wordt vertrouwd of dat via een certificaatketen is gekoppeld aan een certificaat dat wordt vertrouwd op de installatiecomputer:

Installatiedialoogvenster voor bevestiging voor toepassing die met een vertrouwd certificaat is ondertekend

Als u een toepassing ondertekent met een zelfondertekend certificaat (of een certificaat dat niet aan een vertrouwd certificaat is gekoppeld), moet de gebruiker bij het installeren van de toepassing een groter beveiligingsrisico accepteren. In het dialoogvenster wordt dit extra risico aangegeven:

Installatiedialoogvenster voor bevestiging voor toepassing die met een zelfondertekend certificaat is ondertekend
Belangrijk: een kwaadwillende entiteit kan uw identiteit in een AIR-bestand vervalsen als deze op een of andere manier uw sleutelarchiefbestand voor ondertekening in handen krijgt of uw persoonlijke sleutel ontdekt.

Certificaten voor de ondertekening van code

De beveiligingsgaranties, beperkingen en wettelijke verplichtingen die betrekking hebben op het gebruik van certificaten voor ondertekening van programmacode worden beschreven in de CPS (Certificate Practice Statements) en gebruiksrechtovereenkomsten die zijn uitgegeven door de certificeringsinstantie. Voor meer informatie over de overeenkomsten voor de certificeringsinstanties die momenteel certificaten voor de ondertekening van AIR-code uitgeven, raadpleegt u:

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)

Thawte CPS (http://www.thawte.com/cps/index.html)

VeriSign CPS (http://www.verisign.com/repository/CPS/)

VeriSign Subscriber's Agreement (https://www.verisign.com/repository/subscriber/SUBAGR.html)

Informatie over ondertekening van AIR-programmacode

Wanneer een AIR-bestand wordt ondertekend, wordt een digitale handtekening opgenomen in het installatiebestand. De handtekening bevat een samenvatting van het pakket waarmee wordt geverifieerd of het AIR-bestand niet is gewijzigd sinds het werd ondertekend, en bevat informatie over het handtekeningcertificaat waarmee de identiteit van de uitgever wordt geverifieerd.

AIR maakt gebruik van PKI (Public Key Infrastructure, openbare-sleutelinfrastructuur) dat door het certificaatarchief van het besturingssysteem wordt ondersteund, om te bepalen of een certificaat kan worden vertrouwd. Om de gegevens van de uitgever te kunnen verifiëren moet de computer waarop een AIR-toepassing wordt geïnstalleerd het certificaat waarmee de AIR-toepassing wordt ondertekend rechtstreeks vertrouwen of een certificaatketen vertrouwen waarmee het certificaat aan een vertrouwde certificeringsinstantie wordt gekoppeld.

Als een AIR-bestand is ondertekend met een certificaat dat niet via een certificaatketen is gekoppeld aan een van de vertrouwde basiscertificaten (en dit betreft alle zelfondertekende certificaten), kunnen de gegevens van de uitgever niet worden geverifieerd. Hoewel AIR kan bepalen of het AIR-pakket niet is gewijzigd sinds het werd ondertekend, is niet bekend wie het bestand heeft gemaakt en ondertekend.

Opmerking: als een gebruiker een zelfondertekend certificaat vertrouwt, geven alle AIR-toepassingen die met het certificaat zijn ondertekend de waarde van de algemene naam (CN) in het certificaat weer als de uitgeversnaam. AIR beschikt niet over mogelijkheden waarmee een gebruiker een certificaat als vertrouwd kan aanmerken. Het certificaat (exclusief de persoonlijke sleutel) moet afzonderlijk aan de gebruiker worden gegeven en de gebruiker moet een van de mechanismen van het besturingssysteem of een geschikt hulpprogramma gebruiken om het certificaat te importeren op de juiste locatie in het certificaatarchief van het systeem.

Informatie over uitgevers-id's voor AIR

Belangrijk: vanaf AIR 1.5.3 is de uitgevers-id afgekeurd en wordt deze niet meer berekend op basis van het certificaat voor ondertekenen van code. Een uitgevers-id is niet meer nodig bij nieuwe toepassingen en moet niet meer worden gebruikt. Wanneer u bestaande toepassingen bijwerkt, moet u de oorspronkelijke uitgevers-id opgeven in het descriptorbestand van de toepassing.

Voorafgaand aan versie AIR 1.5.3 werd door het installatieprogramma van de AIR-toepassing een uitgevers-id gegenereerd bij de installatie van een AIR-bestand. Dit was een unieke id voor het certificaat waarmee het AIR-bestand wordt ondertekend. Als u hetzelfde certificaat had gebruikt voor meerdere AIR-toepassingen, werd dezelfde uitgevers-id toegepast. De uitgevers-id werd gewijzigd doordat de update van een toepassing met een ander certificaat en soms zelfs met een vernieuwde instantie van het oorspronkelijke certificaat werd ondertekend.

Bij AIR 1.5.3 en hoger wordt er geen uitgevers-id toegewezen door AIR. Een toepassing die is gepubliceerd met AIR 1.5.3 kan een tekenreeks voor de uitgevers-id opgeven in de toepassingsdescriptor. U moet alleen een uitgevers-id opgeven wanneer u updates voor toepassingen publiceert die oorspronkelijk zijn gepubliceerd voor versies van AIR die voorafgaan aan versie 1.5.3. Als u de oorspronkelijke id niet opgeeft in de toepassingsdescriptor, wordt het nieuwe AIR-pakket niet behandeld als een update van de bestaande toepassing.

Als u de oorspronkelijke gebruikers-id wilt bepalen, moet u zoeken naar het bestand publisherid in de submap META-INF/AIR waar de oorspronkelijke toepassing is geïnstalleerd. De uitgevers-id wordt aangegeven door de tekenreeks in dit bestand. Als u de uitgevers-id handmatig wilt kunnen opgeven, moet versie 1.5.3 (of hoger) van de AIR-runtime worden opgeven in de naamruimtedeclaratie van het descriptorbestand van de toepassing.

Indien aanwezig wordt de uitgevers-id gebruikt voor de volgende doeleinden:

  • Als onderdeel van de coderingssleutel voor de gecodeerde lokale opslagruimte

  • Als onderdeel van het pad voor de opslagmap van de toepassing

  • Als onderdeel van de verbindingstekenreeks voor lokale verbindingen

  • Als onderdeel van de identiteitstekenreeks waarmee een toepassing wordt aangeroepen met de AIR in-browser API

  • Als onderdeel van de OSID (gebruikt bij het maken van aangepaste programma's voor het installeren/verwijderen van software)

Wanneer u een uitgevers-id wijzigt, wordt ook het gedrag gewijzigd van de AIR-functies die afhankelijk zijn van de id. Zo zijn de gegevens in de bestaande gecodeerde lokale opslagruimte niet meer toegankelijk en moeten alle Flash- of AIR-instanties die een lokale verbinding maken met de toepassing ook gebruikmaken van de nieuwe id in de verbindingstekenreeks. De uitgever-id voor een geïnstalleerde toepassing kan niet worden gewijzigd in AIR 1.5.3 of later. Als u een andere uitgevers-id gebruikt wanneer u een AIR-pakket publiceert, wordt het nieuwe pakket door het installatieprogramma behandeld als een andere toepassing, en niet als een update.

Informatie over certificaatindelingen

De ondertekeningsprogramma's van AIR accepteren alle sleutelarchieven die toegankelijk zijn via JCA (Java Cryptography Architecture). Hiertoe behoren op bestanden gebaseerde sleutelarchieven, zoals PKCS12-bestanden (die gewoonlijk de extensie .pfx of .p12 hebben), sleutelarchiefbestanden van Java, PKCS11-hardwaresleutelarchieven en de sleutelarchieven van het systeem. Welke sleutelarchiefindelingen ADT kan openen, is afhankelijk van de versie en de configuratie van de Java-runtime waarmee ADT wordt uitgevoerd. Voor sommige typen sleutelarchieven, zoals PKCS11-hardwaretokens, moeten mogelijk extra stuurprogramma's en JCA-invoegtoepassingen worden geïnstalleerd en geconfigureerd.

Als u AIR-bestanden wilt ondertekenen, kunt u de meeste bestaande certificaten voor ondertekening van code gebruiken, of u kunt een nieuwe verkrijgen die speciaal voor de ondertekening van AIR-toepassingen is uitgegeven. U kunt bijvoorbeeld alle volgende typen certificaten gebruiken van VeriSign, Thawte, GlobalSign of ChosenSecurity:

  • ChosenSecurity

    • TC Publisher ID for Adobe AIR

  • GlobalSign

    • ObjectSign Code Signing Certificate

  • Thawte:

    • AIR-certificaat voor ontwikkelaars

    • Apple-certificaat voor ontwikkelaars

    • JavaSoft-certificaat voor ontwikkelaars

    • Microsoft Authenticode-certificaat

  • VeriSign:

    • Adobe AIR Digital ID

    • Digitale Microsoft Authenticode-id

    • Digitale handtekening-id van Sun Java

Opmerking: het certificaat moet zijn gemaakt voor het ondertekenen van code. U kunt geen SSL of ander type certificaat gebruiken om AIR-bestanden te ondertekenen.

Tijdstempels

Wanneer u een AIR-bestand ondertekent, wordt bij de server van een tijdstempelinstantie gevraagd om een datum en tijd van ondertekening die onafhankelijk te verifiëren zijn. Het tijdstempel wordt ingesloten in het AIR-bestand. Wanneer het handtekeningcertificaat geldig is op het moment van ondertekenen, kan het AIR-bestand worden geïnstalleerd, zelfs nadat het certificaat is verlopen. Als er geen tijdstempel wordt opgehaald, kan het AIR-bestand niet meer worden geïnstalleerd wanneer het certificaat is verlopen of is ingetrokken.

Standaard wordt een tijdstempel opgehaald wanneer een AIR-pakket wordt gemaakt. U kunt het ophalen van een tijdstempel echter uitschakelen, zodat u toepassingspakketten kunt maken wanneer de tijdstempelservice niet beschikbaar is. Adobe raadt u aan in alle openbaar gedistribueerde AIR-bestanden een tijdstempel op te nemen.

De standaardinstantie voor tijdstempels die voor AIR-pakketten wordt gebruikt, is Geotrust.

Certificaten ophalen

Als u een certificaat nodig hebt, gaat u gewoonlijk naar de website van een certificeringsinstantie en voltooit u het aankoopproces van dat bedrijf. Welke hulpprogramma's nodig zijn om het sleutelarchiefbestand te maken, is afhankelijk van het type van het gekochte certificaat, hoe het certificaat op de ontvangende computer wordt opgeslagen en, in sommige gevallen, de browser waarmee het certificaat is opgehaald. Als u bijvoorbeeld een Adobe Developer-certificaat wilt verkrijgen en exporteren van Thawte, moet u Mozilla Firefox gebruiken. Het certificaat kan vervolgens rechtstreeks vanuit de gebruikersinterface van Internet Explorer worden geëxporteerd als een .p12- of .pfx-bestand.

Opmerking: bij Java versie 1.5 en later worden hoge ASCII-tekens in wachtwoorden voor de beveiliging van PKCS12-certificatiebestanden niet geaccepteerd. Java wordt gebruikt door de AIR-ontwikkelingsprogramma's bij het maken van ondertekende AIR-pakketten. Wanneer u het certificaat exporteert als een .p12 of .pfx-bestand, moet u alleen normale ASCII-tekens gebruiken in het wachtwoord.

U kunt een zelfondertekend certificaat genereren met het hulpprogramma ADT (Air Development Tool) waarmee AIR-toepassingsbestanden in een pakket worden geplaatst. U kunt ook sommige hulpprogramma's van derden gebruiken.

Zie AIR Developer Tool (ADT) voor instructies voor het genereren van een zelfondertekend certificaat en het ondertekenen van een AIR-bestand. U kunt AIR-bestanden ook exporteren en ondertekenen met Flash Builder, Dreamweaver en de AIR-update voor Flash.

In het volgende voorbeeld ziet u hoe u een AIR-certificaat voor ontwikkelaars ophaalt bij de certificeringsinstantie Thawte en dit voorbereidt voor gebruik met ADT.

Voorbeeld: Een AIR-certificaat voor ontwikkelaars ophalen bij Thawte

Opmerking: dit voorbeeld bevat slechts een van de vele manieren waarop u een certificaat voor ondertekening van programmacode kunt ophalen en voorbereiden. Elke certificeringsinstantie heeft zijn eigen beleid en procedures.

Als u een AIR-certificaat voor ontwikkelaars wilt aanschaffen, moet u de website van Thawte bezoeken met de browser Mozilla Firefox. De persoonlijke sleutel voor het certificaat wordt opgeslagen in het sleutelarchief van de browser. Zorg ervoor dat het Firefox-sleutelarchief is beveiligd met een hoofdwachtwoord en dat de computer zelf fysiek is beveiligd. (U kunt het certificaat en de persoonlijke sleutel uit het sleutelarchief van de browser exporteren en verwijderen nadat het aankoopproces is voltooid.)

Tijdens het certificaatinschrijvingsproces wordt een combinatie van een persoonlijke en een openbare sleutel gegenereerd. De persoonlijke sleutel wordt automatisch opgeslagen in het sleutelarchief van Firefox. Voor het aanvragen en het ophalen van het certificaat op de website van Thawte moet u dezelfde computer en browser gebruiken.

  1. Ga op de website van Thawte naar de productpagina voor certificaten voor ondertekening van programmacode.

  2. Selecteer Adobe AIR Developer Certificate in de lijst met certificaten voor ondertekening van programmacode.

  3. Voltooi de drie stappen van het inschrijvingsproces. U moet gegevens van uw organisatie en een contactpersoon opgeven. Thawte verifieert vervolgens uw identiteit en kan om aanvullende informatie vragen. Nadat de verificatie is voltooid, stuurt Thawte u een e-mailbericht met instructies voor het ophalen van het certificaat.

    Opmerking: Meer informatie over het type documentatie dat nodig is, kunt u hier vinden: https://www.thawte.com/ssl-digital-certificates/free-guides-whitepapers/pdf/enroll_codesign_eng.pdf.
  4. Haal het uitgegeven certificaat op vanaf de site van Thawte. Het certificaat wordt automatisch opgeslagen in het sleutelarchief van Firefox.

  5. Exporteer op de volgende manier een sleutelarchiefbestand dat de persoonlijke sleutel en het certificaat uit het sleutelarchief van Firefox bevat:

    Opmerking: Wanneer u de persoonlijke sleutel en het certificaat vanuit Firefox exporteert, worden deze geëxporteerd naar een P12-indeling (.pfx) die in ADT, Flex, Flash en Dreamweaver kan worden gebruikt.
    1. Open in Firefox het dialoogvenster Certificatenbeheerder:

    2. In Windows: Open Extra -> Opties -> Geavanceerd -> Codering -> Certificaten weergeven

    3. In Mac OS: Open Firefox-> Voorkeuren-> Geavanceerd -> Codering -> Certificaten weergeven

    4. In Linux: Open Bewerken-> Voorkeuren-> Geavanceerd -> Codering -> Certificaten weergeven

    5. Selecteer het Adobe AIR-certificaat voor ondertekening van programmacode in de lijst met certificaten en klik op de knop Reservekopie maken.

    6. Voer een bestandsnaam en een locatie in voor het te exporteren sleutelarchiefbestand en klik op Opslaan.

    7. Als u het hoofdwachtwoord van Firefox gebruikt, moet u uw wachtwoord voor het softwarebeveiligingsapparaat invoeren om het bestand te exporteren. (Dit wachtwoord wordt alleen door Firefox gebruikt.)

    8. Maak in het dialoogvenster Wachtwoord voor reservekopie van certificaat kiezen een wachtwoord voor het sleutelarchiefbestand.

      Belangrijk: dit wachtwoord beveiligt het sleutelarchiefbestand en is vereist wanneer het bestand wordt gebruikt voor het ondertekenen van AIR-toepassingen. Kies een veilig wachtwoord.
    9. Klik op OK. U ontvangt een bericht wanneer de reservekopie is gemaakt. Het sleutelarchiefbestand dat de persoonlijke sleutel en het certificaat bevat, wordt opgeslagen met de extensie .p12 (in de PKCS12-indeling).

  6. Gebruik het geëxporteerde sleutelarchiefbestand in ADT, Flash Builder, Flash Professional of Dreamweaver. Het wachtwoord dat voor het bestand is gemaakt, is vereist wanneer een AIR-toepassing wordt ondertekend.

Belangrijk: de persoonlijke sleutel en het certificaat blijven opgeslagen in het sleutelarchief van Firefox. Hoewel u daardoor een extra kopie van het certificaatbestand kunt exporteren, is dit ook een toegangspunt dat u moet beveiligen om de veiligheid van uw certificaat en de persoonlijke sleutel te garanderen.

Certificaten wijzigen

In sommige gevallen moet u het certificaat wijzigen waarmee u de updates voor uw AIR-toepassing ondertekent. Bijvoorbeeld:

  • Bij het vernieuwen van het oorspronkelijke certificaat voor ondertekenen.

  • U wilt een zelfondertekend certificaat wijzigen in een certificaat dat door een ondertekeningsinstantie is uitgegeven.

  • U wilt een zelfondertekend certificaat dat bijna is verlopen, wijzigen in een ander certificaat.

  • U wilt een commercieel certificaat wijzigen in een ander commercieel certificaat, bijvoorbeeld wanneer de identiteit van uw bedrijf is gewijzigd.

Als u wilt dat een AIR-bestand door AIR wordt herkend als een update, moet u zowel de oorspronkelijke als de bijgewerkte versie van de AIR-bestanden met hetzelfde certificaat ondertekenen, of u moet een certificaat met migratiehandtekening toepassen op de update. Een migratiehandtekening is een tweede handtekening die wordt toegepast op het AIR-updatepakket met behulp van het oorspronkelijke certificaat. De migratiehandtekening gebruikt het oorspronkelijke certificaat, waardoor wordt vastgelegd dat de ondertekenaar de oorspronkelijke uitgever van de toepassing is.

Nadat een AIR-bestand met een migratiehandtekening is geïnstalleerd, wordt het nieuwe certificaat het primaire certificaat. Voor alle volgende updates is er geen migratiehandtekening vereist. U kunt migratiehandtekeningen het beste zo lang mogelijk toepassen om tegemoet te komen aan gebruikers die sommige updates overslaan.

Belangrijk: u moet voordat het verloopt het certificaat wijzigen en een migratiehandtekening toepassen op de update van het oorspronkelijke certificaat. Als dit niet plaatsvindt, moeten gebruikers hun bestaande versie van uw toepassing verwijderen voordat zij een nieuwe versie installeren. Voor AIR 1.5.3 of later kunt u binnen een respijtperiode van 365 dagen na het verlopen een migratiehandtekening toepassen met een verlopen certificaat. Met het verlopen certificaat kunt u echter de handtekening van de hoofdtoepassing niet toepassen.

Certificaten wijzigen:

  1. Maak een update voor uw toepassing.

  2. Plaats het AIR-updatebestand in een pakket en onderteken het met het nieuwe certificaat.

  3. Onderteken het AIR-bestand opnieuw met het oorspronkelijke certificaat (met de ADT-opdracht -migrate).

Een AIR-bestand met een migratiehandtekening is verder hetzelfde als een normaal AIR-bestand. Als de toepassing wordt geïnstalleerd op een systeem zonder de oorspronkelijke versie, wordt de nieuwe versie op de gebruikelijke manier geïnstalleerd.

Opmerking: voorafgaand aan AIR 1.5.3 was er voor het ondertekenen van een AIR-toepassing met een vernieuwd certificaat niet altijd een migratiehandtekening vereist. In AIR 1.5.3 en hogere versies is er altijd een migratiehandtekening vereist voor vernieuwde certificaten.

Als u een migratiehandtekening wilt toepassen, gebruikt u de ADT-opdracht voor migreren, zoals beschreven in Een bijgewerkte versie van een AIR-toepassing ondertekenen..

Opmerking: de ADT-opdracht voor migreren kan niet worden gebruikt met AIR-bureaubladtoepassingen die native extensies bevatten, omdat deze toepassingen in een pakket zijn opgenomen als native installatieprogramma's, en niet als AIR-bestanden. Als u certificaten wilt wijzigen voor een AIR-bureaubladtoepassing die een native extensie bevat, neemt u de toepassing op in een pakket met behulp van de ADT-opdracht voor verpakken met de markering -migrate.

Gewijzigde toepassingsidentiteit

Voorafgaand aan AIR 1.5.3 werd de identiteit van de AIR-toepassing gewijzigd bij het installeren van een update die was ondertekend met een migratiehandtekening. Het wijzigen van de identiteit van een toepassing heeft verschillende gevolgen, zoals:

  • De nieuwe versie van de toepassing heeft geen toegang tot gegevens in het bestaande gecodeerde lokale archief.

  • De locatie van de opslagmap van de toepassing wordt gewijzigd. Gegevens op de oude locatie worden niet naar de nieuwe map gekopieerd. (Maar de nieuwe toepassing kan de oorspronkelijke locatie wel vinden op basis van de oude uitgevers-id.)

  • De toepassing kan geen lokale verbindingen meer openen met de oude uitgevers-id.

  • De identiteitstekenreeks waarmee een toepassing toegankelijk wordt vanaf een webpagina verandert.

  • De OSID van de toepassing verandert. (De OSID wordt gebruikt bij het schrijven van aangepaste programma's voor het installeren en verwijderen van software.)

Bij het publiceren van een update met AIR 1.5.3 of later kan de identiteit van de toepassing niet worden gewijzigd. De oorspronkelijke toepassings-id en uitgevers-id moeten worden opgegeven in de toepassingsdescriptor van het AIR-bestand voor de update. Als dat niet het geval is, wordt het nieuwe pakket niet herkend als een update.

Opmerking: bij het publiceren van een nieuwe AIR-toepassing met AIR 1.5.3 of hoger, moet u geen uitgevers-id opgeven.

Terminologie

Deze sectie bevat een woordenlijst met een aantal belangrijke termen die u moet begrijpen wanneer u beslissingen neemt over de manier waarop u uw toepassing ondertekent voor openbare distributie.

Term

Beschrijving

Certificeringsinstantie (CA)

Een entiteit in een netwerk met een openbare-sleutelinfrastructuur die optreedt als vertrouwde derde partij en de identiteit van de eigenaar van een openbare sleutel certificeert. Een CA geeft gewoonlijk digitale certificaten uit, die met een eigen persoonlijke sleutel zijn ondertekend, om te verklaren dat de identiteit van de certificaathouder is geverifieerd.

CPS (Certificate Practice Statement)

Bevat de procedures en het beleid van de certificeringsinstantie voor het uitgeven en verifiëren van certificaten. De CPS is opgenomen in het contract tussen de CA en haar abonnees en afhankelijke partijen. Hierin wordt ook het beleid voor identiteitsverificatie beschreven en het garantieniveau van de uitgegeven certificaten.

CRL (Certificate Revocation List)

Een lijst met uitgegeven certificaten die zijn ingetrokken en niet meer mogen worden vertrouwd. AIR raadpleegt de CRL op het moment dat een AIR-toepassing wordt ondertekend, en als er geen tijdstempel aanwezig is, opnieuw wanneer de toepassing wordt geïnstalleerd.

Certificaatketen

Een certificaatketen is een reeks certificaten waarbij elk certificaat is ondertekend door het volgende certificaat.

Digitaal certificaat

Een digitaal document dat informatie bevat over de identiteit van de eigenaar, de openbare sleutel van de eigenaar en de identiteit van het certificaat zelf. Een certificaat dat door een certificeringsinstantie is uitgegeven, is zelf ondertekend door een certificaat dat eigendom is van de uitgevende certificeringsinstantie.

Digitale handtekening

Een gecodeerd bericht of gecodeerde samenvatting die alleen kan worden gedecodeerd met de openbare sleutel van een sleutelpaar met een openbaar en een persoonlijk gedeelte. In een PKI bevat een digitale handtekening een of meer digitale certificaten die uiteindelijk te traceren zijn tot de certificeringsinstantie. Een digitale handtekening kan worden gebruikt om te valideren of een bericht (of computerbestand) niet is veranderd sinds het werd ondertekend (binnen de zekerheidsbeperkingen van de gebruikte cryptografiealgoritme) en om de identiteit van de ondertekenaar te valideren (aangenomen dat de uitgevende certificeringsinstantie wordt vertrouwd).

Sleutelarchief

Een database die digitale certificaten bevat en soms ook de bijbehorende persoonlijke sleutels.

JCA (Java Cryptography Architecture)

Een uitbreidbare architectuur voor het beheer van en de toegang tot sleutelarchieven. Zie de Java Cryptography Architecture Reference Guide voor meer informatie.

PKCS #11

De interfacestandaard van RSA Laboratories voor cryptografietokens. Een sleutelarchief met hardwaretokens.

PKCS #12

De standaardsyntaxis van RSA Laboratories voor uitwisseling van persoonlijke gegevens. Een sleutelarchief met bestanden die gewoonlijk een persoonlijke sleutel en het bijbehorende digitale certificaat bevatten.

Persoonlijke sleutel

De persoonlijke helft van een asymmetrisch cryptografiesysteem dat uit een openbare en een persoonlijke sleutel bestaat. De persoonlijke sleutel moet geheim blijven en mag nooit via een netwerk worden verzonden. Digitaal ondertekende berichten worden door de ondertekenaar gecodeerd met de persoonlijke sleutel.

Openbare sleutel

De openbare helft van een asymmetrisch cryptografiesysteem dat uit een openbare en een persoonlijke sleutel bestaat. De openbare sleutel is algemeen beschikbaar en wordt gebruikt voor het decoderen van berichten die met de persoonlijke sleutel zijn gecodeerd.

PKI (Public Key Infrastructure)

Een systeem van vertrouwen waarin certificeringsinstanties de identiteit van de eigenaren van openbare sleutels bevestigen. Clients van het netwerk vertrouwen erop dat de digitale certificaten die door een vertrouwde CA zijn uitgegeven de identiteit van de ondertekenaar van een digitaal bericht (of bestand) garanderen.

Tijdstempel

Digitaal ondertekende informatie die de datum en tijd bevat waarop een gebeurtenis is opgetreden. ADT kan een tijdstempel van een RFC 3161-compatibele tijdserver opnemen in een AIR-pakket. Wanneer een tijdstempel aanwezig is, wordt dit gebruikt om de geldigheid van een certificaat vast te stellen op het moment van ondertekenen. Hierdoor kan een AIR-toepassing worden geïnstalleerd nadat het handtekeningcertificaat is verlopen.

Tijdstempelinstantie

Een instantie die tijdstempels uitgeeft. Om door AIR te worden herkend, moet een tijdstempel voldoen aan RFC 3161 en moet de handtekening van het tijdstempel via een certificaatketen kunnen worden gekoppeld aan een vertrouwd basiscertificaat op de installatiecomputer.

iOS-certificaten

De certificaten voor het ondertekenen van de code die door Apple worden uitgegeven, worden gebruikt voor het ondertekenen van iOS-toepassingen, inclusief toepassingen die zijn ontwikkeld met Adobe AIR. Wanneer u een toepassing op testapparatuur wilt installeren, wordt het toepassen van een handtekening met een Apple-ontwikkelingscertificaat vereist. Bij het distribueren van de voltooide toepassing wordt het toepassen van een handtekening met een distributiecertificaat vereist.

Wanneer u een toepassing wilt ondertekenen, wordt door ATD toegang vereist tot het certificaat voor het ondertekenen van de code en de bijbehorende persoonlijke sleutel. In het certificaatbestand zelf is geen persoonlijke sleutel opgenomen. U moet een sleutelarchief maken in de vorm van een uitwisselingsbestand van persoonlijke gegevens (P12-bestand of .pfx) waarin het certificaat en de persoonlijke sleutel zijn opgenomen. Zie Een ontwikkelingscertificaat omzetten in een P12-sleutelarchief-bestand.

Een certificaataanvraag genereren

U verkrijgt een ontwikkelingscertificaat door een certificaataanvraag te genereren en in te dienen op de Apple iOS Provisioning Portal.

Door het proces voor certificaataanvraag wordt een openbare-persoonlijke sleutelcombinatie gegenereerd. De persoonlijke sleutel blijft op uw computer. U verzendt de ondertekeningsaanvraag met de openbare sleutel en uw identificatiegegevens naar Apple, die fungeert als certificeringsinstantie. Apple ondertekent uw certificaat met het World Wide Developer Relations-certificaat van Apple.

Een certificaataanvraag genereren op Mac OS

In Mac OS genereert u een certificaataanvraag met de toepassing Sleutelhangertoegang. De toepassing Sleutelhangertoegang bevindt zich in de submap Hulpprogramma's van de map Toepassingen. Instructies voor het genereren van de certificaataanvraag zijn beschikbaar op de Apple iOS Provisioning Portal.

Een certificaataanvraag genereren in Windows

Voor Windows-ontwikkelaars is het wellicht het eenvoudigst om het iPhone-certificaat voor ontwikkelaars voor een Mac-computer te verkrijgen. Het is echter ook mogelijk om een certificaat te verkrijgen voor een Windows-computer. U maakt eerst een CSR-bestand (Certificate Signing Request) met OpenSSL:

  1. Installeer OpenSSL op de Windows-computer. (Ga naar http://www.openssl.org/related/binaries.html.)

    U moet wellicht ook de Visual C++ 2008 Redistributable-bestanden op de Open SSL-downloadpagina installeren. (Visual C++ hoeft niet op uw computer te staan.)

  2. Open een Windows-opdrachtregelsessie en ga naar de bin-map van OpenSSL (bijvoorbeeld c:\OpenSSL\bin\).

  3. Maak de persoonlijke sleutel door het volgende op de opdrachtregel op te geven:

    openssl genrsa -out mykey.key 2048

    Sla dit bestand met de persoonlijke sleutel op. U hebt het later nodig.

    Negeer foutberichten niet wanneer u OpenSSL gebruikt. Ook als OpenSSL een foutbericht genereert, voert het wellicht nog bestanden uit. Deze bestanden zijn dan echter waarschijnlijk niet bruikbaar. Als u fouten ziet, controleert u de syntaxis en voert u opdracht nogmaals uit.

  4. Maak het CSR-bestand door het volgende op de opdrachtregel op te geven:

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

    Vervang de waarden voor het e-mailadres, CN (certificaatnaam) en C (land) door uw eigen waarden.

  5. Upload het CSR-bestand naar Apple op de website voor iPhone-ontwikkelaars. (Zie "Een iPhone-certificaat voor ontwikkelaars aanvragen en een inrichtingsprofiel maken".)

Een ontwikkelingscertificaat omzetten in een P12-sleutelarchief-bestand

Wanneer u een P12-sleutelarchief wilt maken, moet u in één bestand uw Apple ontwikkelingscertificaat combineren met de bijbehorende persoonlijke sleutel. Het proces voor het maken van een sleutelarchiefbestand is afhankelijk van de methode die u hebt gebruikt om de oorspronkelijke certificaataanvraag te genereren en van de locatie waar de persoonlijke sleutel is opgeslagen.

Het iPhone-certificaat voor ontwikkelaars omzetten naar een P12-bestand in Mac OS

Als u het Apple iPhone-certificaat bij Apple hebt gedownload, exporteert u het certificaat naar de P12-sleutelarchiefindeling. Ga in Mac® OS als volgt te werk:

  1. Open de toepassing Sleutelhangertoegang (in de map Toepassingen/Hulpprogramma's).

  2. Als u het certificaat nog niet aan Keychain hebt toegevoegd, selecteert u Bestand > Importeren. Navigeer naar het certificaatbestand (*.cer) dat u van Apple hebt ontvangen.

  3. Selecteer de sleutelcategorie in Sleutelhangertoegang.

  4. Selecteer de persoonlijke sleutel die aan het ontwikkelingscertificaat van uw iPhone is gekoppeld.

    De persoonlijke sleutel wordt door de iPhone-ontwikkelaar geïdentificeerd: <Voornaam> <Achternaam> openbaar certificaat dat aan een de sleutel is gekoppeld.

  5. Houd Command ingedrukt en klik op het iPhone-certificaat voor ontwikkelaars en selecteer “iPhone Developer: Name...”(iPhone-ontwikkelaar: naam...) exporteren.

  6. Sla het sleutelarchief op in de P12-bestandsindeling (Personal Information Exchange).

  7. U wordt gevraagd een wachtwoord te maken dat wordt gebruikt wanneer u het sleutelarchief gebruikt om toepassingen te ondertekenen of voor het overbrengen van de sleutel en certificaat van dit sleutelarchief naar een ander sleutelarchief.

Een Apple-certificaat voor ontwikkelaars omzetten in een P12-bestand voor Windows

Voor het ontwikkelen van AIR voor iOS-toepassingen moet u een P12-certificaatbestand gebruiken. U genereert dit certificaat op basis van het Apple iPhone-certificaatbestand voor ontwikkelaars dat u van Apple ontvangt.

  1. Zet het certificaatbestand voor ontwikkelaars dat u van Apple ontvangt, om in een PEM-certificaatbestand. Voer de volgende opdrachtregelinstructie uit vanuit de OpenSSL-bin-map:

    openssl x509 -in developer_identity.cer -inform DER -out developer_identity.pem -outform PEM
  2. Als u de persoonlijke sleutel van de sleutelhanger op een Mac-computer gebruikt, zet u de sleutel om in een PEM-sleutel:

    openssl pkcs12 -nocerts -in mykey.p12 -out mykey.pem
  3. U kunt nu een geldig P12-bestand genereren op basis van de sleutel en de PEM-versie van het iPhone-certificaat voor ontwikkelaars:

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

    Als u een sleutel gebruikt van een Mac OS-sleutelhanger, gebruikt u de PEM-versie die u in de vorige stap hebt gegenereerd. Gebruik in het andere geval de OpenSSL-sleutel die u eerder hebt gegenereerd (op de Windows-computer).