Digitales Signieren von AIR-Dateien

Die digitale Unterzeichnung von AIR-Installationsdateien mit Zertifikaten, die von einer anerkannten Zertifizierungsstelle (CA) ausgegeben wurden, gibt Ihren Benutzern die Sicherheit, dass die Anwendung, die sie installieren, nicht versehentlich oder in böser Absicht verändert wurde, und weist Sie als Unterzeichner (Herausgeber) aus. AIR zeigt den Namen des Herausgebers während der Installation an, wenn die AIR-Anwendung mit einem vertrauenswürdigen Zertifikat signiert wurde oder sie über eine Kette mit einem Zertifikat verknüpft ist, dem der Computer Vertrauen schenkt:

Bestätigungsdialogfeld bei der Installation einer mit einem vertrauenswürdigen Zertifikat signierten Anwendung

Wenn Sie eine Anwendung mit einem selbst signierten Zertifikat signieren (oder mit einem Zertifikat, das nicht mit einem vertrauenswürdigen Zertifikat verkettet ist), muss der Benutzer ein höheres Sicherheitsrisiko in Kauf nehmen, wenn er Ihre Anwendung installiert. Das Installationsdialogfeld weist auf dieses zusätzliche Risiko hin:

Bestätigungsdialogfeld bei der Installation einer mit einem selbst signierten Zertifikat signierten Anwendung
Wichtig: Wenn Ihre Keystore-Datei oder Ihr privater Schlüssel in andere Hände geraten, besteht die Möglichkeit, dass eine AIR-Datei in böswilliger Absicht mit Ihrer Identität gefälscht wird.

Codesignatur-Zertifikat

Die Gewährleistungen für die Sicherheit, Einschränkungen und rechtlichen Verpflichtungen in Zusammenhang mit der Verwendung von Codesignatur-Zertifikaten werden in den Certificate Practice Statements (CPS) und den Abonnentenvereinbarungen, die von der Zertifizierungsstelle herausgegeben werden, näher beschrieben. Weitere Informationen zu den Vereinbarungen für die Zertifizierungsstellen, die zurzeit Zertifikate für Signaturen von AIR-Code ausgeben, finden Sie unter:

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-Abonnentenvertrag (https://www.verisign.com/repository/subscriber/SUBAGR.html)

AIR-Codesignatur

Wenn eine AIR-Datei signiert wird, wird eine digitale Unterschrift in die Installationsdatei aufgenommen. Die Signatur enthält einen Digest des Pakets, mit dem verifiziert wird, dass die Datei seit der Signierung nicht verändert wurde. Der Digest enthält Informationen über das Signaturzertifikat, mit dem die Identität des Herausgebers überprüft wird.

AIR verwendet die durch den Zertifikatspeicher des Betriebssystems unterstützte Public Key Infrastructure (PKI), um festzustellen, ob das Zertifikat vertrauenswürdig ist. Der Computer, auf dem eine AIR-Anwendung installiert wird, muss entweder dem Zertifikat direkt vertrauen oder muss der Kette vertrauen, über die das Zertifikat mit einer vertrauenswürdigen Zertifizierungsstelle verknüpft ist, damit die Herausgeberinformationen überprüft werden können.

Wenn eine AIR-Datei mit einem Zertifikat signiert wurde, das nicht mit einem vertrauenswürdigen Stammzertifikat verknüpft ist (hierzu gehören in der Regel alle selbst signierten Zertifikate), können die Herausgeberinformationen nicht überprüft werden. Obwohl AIR feststellen kann, dass ein AIR-Paket seit der Unterzeichnung nicht verändert wurde, kann nicht festgestellt werden, wer die Datei tatsächlich erstellt und signiert hat.

Hinweis: Der Benutzer kann sich dafür entscheiden, einem selbst signierten Zertifikat zu vertrauen. In diesem Fall zeigen alle mit dem Zertifikat signierten AIR-Anwendungen den Wert des allgemeinen Namensfelds im Zertifikat als Herausgeber-Namen an. AIR stellt keine Möglichkeiten für Benutzer zur Verfügung, ein Zertifikat als vertrauenswürdig zu markieren. Das Zertifikat (ohne den privaten Schlüssel) muss dem Benutzer separat zur Verfügung gestellt werden und der Benutzer muss einen der vom Betriebssystem oder einem angemessenen Werkzeug bereitgestellten Mechanismus verwenden, um das Zertifikat an der richtigen Speicheradresse im Zertifikatspeicher des Systems zu speichern.

Herausgeber-IDs in AIR

Wichtig: Ab Version AIR 1.5.3 ist die Herausgeber-ID veraltet und wird nicht länger anhand des Codesignaturzertifikats berechnet. Neue Anwendungen benötigen keine Herausgeber-ID und sollten diese auch nicht verwenden. Beim Aktualisieren vorhandener Anwendungen müssen Sie die Originalherausgeber-ID in der Anwendungsdeskriptordatei angeben.

Vor Version 1.5.3 hat der Installer der AIR-Anwendung während der Installation einer AIR-Datei eine Herausgeber-ID generiert. Diese ID war einmalig und eindeutig dem Zertifikat zugeordnet, mit dem die AIR-Datei erstellt wurde. Wenn Sie dasselbe Zertifikat für mehrere AIR-Anwendungen verwendeten, verfügten diese alle über die gleiche Herausgeber-ID. Durch das Signieren eines Anwendungsupdates mit einem anderen Zertifikat, manchmal sogar bei Verwendung einer erneuerten Instanz des Originalzertifikats, wurde die Herausgeber-ID geändert.

In AIR 1.5.3 und höher wird keine Herausgeber-ID durch AIR zugewiesen. Eine mit AIR 1.5.3 veröffentlichte Anwendung kann eine Herausgeber-ID im Anwendungsdeskriptor angeben. Sie sollten nur dann eine Herausgeber-ID angeben, wenn Sie Updates für Anwendungen veröffentlichen, die ursprünglich für ältere AIR-Versionen als 1.5.3 veröffentlicht wurden. Wenn Sie die Original-ID nicht im Anwendungsdeskriptor angeben, wird das neue AIR-Paket nicht als Update der vorhandenen Version behandelt.

Um die Originalherausgeber-ID zu ermitteln, suchen Sie die Datei publisherid im Unterverzeichnis META-INF/AIR, in dem die Originalanwendung installiert ist. Der String in dieser Datei ist die Herausgeber-ID. Der Anwendungsdeskriptor muss die AIR 1.5.3-Laufzeitumgebung (oder neuer) in der Namespacedeklaration der Anwendungsdeskriptordatei angeben, damit die Herausgeber-ID manuell spezifiziert werden kann.

Die Herausgeber-ID, sofern vorhanden, wird für die folgenden Zwecke verwendet:

  • Als Teil des Verschlüsselungsschlüssels für den verschlüsselten lokalen Speicher

  • Als Teils des Pfads für das Anwendungsspeicherverzeichnis

  • Als Teil des Verbindungsstrings für lokale Verbindungen

  • Als Teil des Kennungsstrings, der zum Aufrufen einer Anwendung mit der AIR „in browser“-API verwendet wird

  • Als Teil der OSID (verwendet beim Erstellen von benutzerdefinierten Installations-/Deinstallationsprogrammen)

Wenn eine Herausgeber-ID geändert wird, ändert sich auch das Verhalten aller AIR-Funktionen, die mit der ID arbeiten. Daten im bestehenden verschlüsselten lokalen Speicher sind zum Beispiel nicht mehr zugänglich und alle Flash- oder AIR-Instanzen, die eine lokale Verbindung zur Anwendung herstellen, müssen die neue ID im Verbindungsstring verwenden. Die Herausgeber-ID für eine installierte Anwendung kann in AIR 1.5.3 oder höher nicht geändert werden. Wenn Sie beim Veröffentlichen eines AIR-Pakets eine andere Herausgeber-ID verwenden, behandelt der Installer das neue Paket als eine andere Anwendung, nicht als Update.

Zertifikat-Formate

Die Unterzeichnungswerkzeuge von AIR akzeptieren alle Keystores, auf die über Java Cryptography Architecture (JCA) zugegriffen werden kann. Hierzu gehören datei-basierte Keystores wie PKCS12-formatierte Dateien (die gewöhnlich eine .pfx- oder .p12-Dateierweiterung verwenden), Java-Keystore-Dateien, PKCS11-Hardware-Keystores und die System-Keystores. Die Keystore-Formate, auf die ADT zugreifen kann, sind von der Version und Konfiguration der Java-Laufzeit, die für die Ausführung von ADT verwendet wird, abhängig. Für den Zugriff auf einige Keystore-Typen, wie beispielsweise PKCS11-Hardware-Token, ist es möglicherweise erforderlich, zusätzliche Softwaretreiber und JCA-Zusatzmodule zu installieren und zu konfigurieren.

Um AIR-Dateien zu signieren, können Sie die meisten erhältlichen Codesignaturzertifikate verwenden oder ein neues Zertifikat beziehen, das ausdrücklich zum Signieren von AIR-Anwendungen ausgegeben wurde. Es können zum Beispiel die folgenden Zertifikat-Typen von VeriSign, Thawte, GlobalSign oder ChosenSecurity werden:

  • ChosenSecurity

    • TC Publisher ID für Adobe AIR

  • GlobalSign

    • ObjectSign-Codesignaturzertifikat

  • Thawte :

    • Apple-Entwicklerzertifikat

    • AIR-Entwicklerzertifikat

    • JavaSoft-Entwicklerzertifikat

    • Microsoft Authenticode-Zertifikat

  • VeriSign :

    • Adobe AIR Digital ID

    • Microsoft Authenticode Digital ID

    • Sun Java Signing Digital ID

Hinweis: Die Zertifikate müssen für die Codesignatur erstellt werden. Sie können AIR-Dateien nicht mit einem SSL-Zertifikat oder sonstigem Zertifikat signieren.

Zeitstempel

Wenn Sie eine AIR-Datei signieren, fordert das Komprimierungswerkzeug beim Server einer Zeitstempelvergabestelle ein unabhängig verifizierbares Datum mit Uhrzeit der Signierung an. Dieser Zeitstempel wird in die AIR-Datei eingebettet. Ist das Unterzeichnungszertifikat zum Zeitpunkt der Unterzeichnung gültig, kann die Datei auch nach Ablauf des Zertifikats noch installiert werden. Wurde dagegen kein Zeitstempel bezogen, kann die AIR-Datei nach Ablauf oder Sperrung des Zertifikats nicht mehr installiert werden.

Das Komprimierungswerkzeug von AIR holt standardmäßig einen Zeitstempel ein. Um jedoch zuzulassen, dass die Anwendung auch dann komprimiert werden kann, wenn keine Zeitstempelvergabe möglich ist, können Sie die Vergabe auch ausschalten. Adobe empfiehlt, alle öffentlich verteilten AIR-Dateien mit einem Zeitstempel zu versehen.

Die vom AIR-Komprimierungswerkzeug verwendete Zeitstempelvergabestelle ist Geotrust.

Beziehen von Zertifikaten

Um ein Zertifikat einzuholen, besuchen Sie in der Regel die Website einer Zertifizierungsstelle und durchlaufen das Anmeldungsverfahren des Unternehmens. Welche Werkzeuge benötigt werden, um die vom AIR-Werkzeug benötigte Keystore-Datei zu erstellen, hängt davon ab, welcher Zertifikattyp erworben wurde, wie das Zertifikat auf dem Empfangscomputer gespeichert wird und in manchen Fällen auch davon, über welchen Browser das Zertifikat bezogen wurde. Wenn Sie zum Beispiel ein Adobe-Entwicklerzertifikat von Thawte erhalten und exportieren möchten, müssen Sie Mozilla Firefox verwenden. Das Zertifikat kann dann als .p12- oder .pfx-Datei direkt von der Firefox-Oberfläche exportiert werden.

Hinweis: In den Java-Versionen 1.5 und höher werden hohe ASCII-Zeichen für Kennwörter, die PKCS12-Zertifikatdateien schützen, nicht akzeptiert. Java wird von den AIR-Entwicklungstools verwendet, um die signierten AIR-Pakete zu erstellen. Wenn Sie das Zertifikat als .p12- oder .pfx-Datei exportieren, können Sie nur reguläre ASCII-Zeichen im Kennwort verwenden.

Mit dem AIR Development Tool (ADT), mit dem Sie AIR-Installationsdateien komprimieren, können Sie auch selbst signierte Zertifikate erzeugen. Auch Werkzeuge von manchen Drittanbietern können verwendet werden.

Anweisungen zum Erzeugen von selbst signierten Zertifikaten sowie zum Signieren von AIR-Dateien finden Sie unter AIR Developer Tool (ADT) . Sie können AIR-Dateien auch mit Flash Builder, Dreamweaver und dem AIR-Update für Flash exportieren und signieren.

Im folgenden Beispiel wird beschrieben, wie Sie ein Zertifikat für AIR-Entwickler von der Zertifizierungsstelle Thawte beziehen und dieses für die Verwendung mit ADT vorbereiten.

Beispiel: Beziehen eines AIR-Entwicklerzertifikat von Thawte

Hinweis: Dieses Beispiel zeigt nur einen der vielen Wege auf, über die ein Codesignatur-Zertifikat bezogen und zur Verwendung vorbereitet werden kann. Jede Zertifizierungsstelle verwendet eigene Richtlinien und Vorgehensweisen.

Um ein AIR-Entwicklerzertifikat von Thawte einzuholen, setzt Thawte die Verwendung von Mozilla Firefox voraus. Der private Schlüssel für das Zertifikat wird im Keystore des Browsers gespeichert. Stellen Sie sicher, dass der Firefox-Keystore mit einem Masterkennwort gesichert ist und dass der Computer selbst nicht von Unbefugten verwendet werden kann. (Sie können das Zertifikat und den privaten Schlüssel auch aus dem Keystore des Browsers exportieren und entfernen, sobald Sie das Zertifikat bezogen haben.)

Als Teil des Antragstellung wird ein privates/öffentliches Schlüsselpaar erzeugt. Der private Schlüssel wird automatisch im Firefox-Keystore gespeichert. Sie müssen das Zertifikat über denselben Computer und Browser bei Thawte anfordern und einholen.

  1. Besuchen Sie die Website von Thawte und navigieren Sie zur Produktseite für Zertifikate mit Codesignierung .

  2. Wählen Sie aus der Liste der Codesignatur-Zertifikate das Adobe AIR-Entwicklerzertifikat.

  3. Durchlaufen Sie die drei Schritte des Anmeldungsverfahrens. Sie müssen Kontaktinformationen und Informationen zu Ihrem Unternehmen angeben. Thawte überprüft dann die Identität und fordert u. U. weitere Informationen an. Nach abgeschlossener Verifizierung sendet Thawte Ihnen eine E-Mail mit Anweisungen dazu, wie Sie das Zertifikat abholen können.

    Hinweis: Weitere Informationen zu der erforderlichen Dokumentation finden Sie hier: https://www.thawte.com/ssl-digital-certificates/free-guides-whitepapers/pdf/enroll_codesign_eng.pdf .

  4. Holen Sie das ausgestellte Zertifikat von Thawte ab. Das Zertifikat wird automatisch im Firefox-Keystore gespeichert.

  5. Exportieren Sie Keystore-Dateien mit privatem Schlüssel und Zertifikat wie folgt aus dem Firefox-Keystore:

    Hinweis: Aus Firefox exportierte private Schlüssel und Zertifikate werden in einem .p12-Format (pfx) exportiert, welches von ADT, Flex, Flash und Dreamweaver verwendet werden kann.

    1. Öffnen Sie das Firefox-Dialogfeld Zertifikat-Manager :

    2. Wählen Sie unter Windows „Extras“ > „Optionen“ > „Erweitert“ > „Verschlüsselung“ > „Zertifikate anzeigen“.

    3. Wählen Sie unter Mac OS „Firefox“ > „Einstellungen“ > „Erweitert“ > „Verschlüsselung“ > „Zertifikate einsehen“.

    4. Wählen Sie unter „Bearbeiten“ > „Einstellungen“ > „Erweitert“ > „Verschlüsselung“ > „Zertifikate anzeigen“.

    5. Wählen Sie das Codesignatur-Zertifikat von Adobe AIR aus der Liste der Zertifikate und klicken Sie auf die Schaltfläche Sicherungskopie .

    6. Geben Sie einen Dateinamen und den Speicherort, an den die Keystore-Datei exportiert werden soll, ein und klicken Sie auf Speichern .

    7. Wenn Sie das Firefox-Masterkennwort verwenden, werden Sie aufgefordert, Ihr Kennwort für das Softwaresicherungsgerät einzugeben, um die Datei exportieren zu können. (Dieses Kennwort wird nur von Firefox verwendet.)

    8. Erstellen Sie im Dialogfeld Kennwort für Zertifikatsicherung wählen ein Kennwort für die Keystore-Datei.

      Wichtig: Dieses Kennwort schützt die Keystore-Datei und muss eingegeben werden, wenn die Datei zum Signieren von AIR-Anwendungen verwendet wird. Sie sollten ein sicheres Kennwort wählen.

    9. Klicken Sie auf „OK“. Sie sollten eine Meldung erhalten, dass das Kennwort erfolgreich gesichert wurde. Die Keystore-Datei mit dem privaten Schlüssel und dem Zertifikat wird mit einer .p12-Erweiterung (im PKCS12-Format) gespeichert.

  6. Verwenden Sie die exportierte Keystore-Datei mit ADT, Flash Builder, Flash Professional oder Dreamweaver. Das für die Datei erstellte Kennwort wird benötigt, wenn eine AIR-Anwendung signiert wird.

Wichtig: Der private Schlüssel und das Zertifikat werden weiterhin im Firefox-Keystore gespeichert. Obgleich Sie so eine zusätzliche Kopie der Zertifikatdatei exportieren können, wird gleichzeitig ein neuer Zugangspunkt erzeugt, den Sie schützen müssen, um die Integrität Ihres Zertifikats und privaten Schlüssels zu schützen.

Wechseln von Zertifikaten

In bestimmten Situationen müssen Sie das Zertifikat, mit dem Sie Updates für Ihre AIR-Anwendung signieren, ändern. Hierzu gehören:

  • Erneuerung des Original-Signaturzertifikats

  • Aktualisierung von einem selbst signierten Zertifikat zu einem Zertifikat einer Zertifizierungsstelle

  • Wechsel von einem selbst signierten Zertifikat, das bald abläuft, zu einem neuen Zertifikat.

  • Wechsel von einem kommerziellen Zertifikat zu einem anderen Zertifikat – beispielsweise bei einer Änderung der Unternehmensidentität.

Damit AIR eine AIR-Datei als ein Update erkennt, müssen Sie entweder sowohl die Original- als auch die Update-AIR-Dateien mit demselben Zertifikat signieren oder eine Zertifikatmigrationssignatur auf das Update anwenden. Eine Migrationsignatur ist eine zweite Signatur, die mit dem Originalzertifikat auf ein Update-AIR-Paket angewendet wird. Die Migrationssignatur verwendet das Originalzertifikat, um den Unterzeichner als Originalherausgeber der Anwendung auszuweisen.

Nachdem eine AIR-Datei mit einer Migrationssignatur installiert wurde, wird das neue Zertifikat zum Hauptzertifikat. Für nachfolgende Updates ist keine Migrationssignatur erforderlich. Sie sollten Migrationssignaturen jedoch so lange wie möglich anwenden, um Benutzern entgegenzukommen, die Updates überspringen.

Wichtig: Sie müssen das Zertifikat ändern und eine Migrationssignatur auf das Update mit dem Originalzertifikat anwenden, bevor es abläuft. Andernfalls müssen Benutzer ihre vorhandene Version Ihrer Anwendung deinstallieren, bevor sie eine neue Version installieren. In AIR 1.5.3 oder höher können Sie eine Migrationssignatur mit einem abgelaufenen Zertifikat innerhalb eines Toleranzzeitraums von 365 Tagen anwenden. Sie können das abgelaufene Zertifikat jedoch nicht für die Hauptanwendungssignatur verwenden.

Zertifikate wechseln:

  1. Erstellen Sie eine Aktualisierung für Ihre Anwendung.

  2. Komprimieren und signieren Sie die AIR-Datei mit dem neuen Zertifikat.

  3. Signieren Sie die AIR-Datei ein weiteres Mal mit dem Original -Zertifikat mithilfe des ADT-Befehls -migrate .

Eine AIR-Datei mit Migrationssignatur ist in jeder anderen Hinsicht eine normale AIR-Datei. Wenn die Anwendung auf einem System ohne Originalversion installiert wird, installiert AIR die neue Version wie gewöhnlich.

Hinweis: Vor Version AIR 1.5.3 war für das Signieren einer AIR-Anwendung mit einem erneuten Zertifikat nicht immer eine Migrationssignatur erforderlich. Ab Version AIR 1.5.3 ist immer eine Migrationssignatur für erneuerte Zertifikate erforderlich.

Verwenden Sie den ADT-Befehl „migrate“ , um eine Migrationssignatur anzuwenden, wie unter Signieren einer aktualisierten Version einer AIR-Anwendung beschrieben.

Hinweis: Der ADT-Befehl „migrate“ kann nicht mit AIR-Desktopanwendungen verwendet werden, die native Erweiterungen enthalten, da diese Anwendungen als native Installationsprogramme komprimiert sind, nicht als .air-Dateien. Zum Ändern von Zertifikaten für AIR-Desktopanwendungen, die native Erweiterungen enthalten, komprimieren Sie die Anwendung mithilfe des ADT-Befehl „package“ mit dem -migrate-Flag.

Änderungen der Anwendungsidentität

Vor AIR 1.5.3 hat sich die Identität einer AIR-Anwendung geändert, wenn ein mit einer Migrationssignatur signiertes Update installiert wurde. Das Ändern der Identität einer Anwendung hat verschiedene Auswirkungen, darunter:

  • Die neue Anwendungsversion kann nicht auf Daten im vorhandenen verschlüsselten lokalen Speicher zugreifen.

  • Der Speicherort des Anwendungsspeicherverzeichnisses wird gewechselt. Daten am alten Speicherort werden nicht in das neue Verzeichnis kopiert. (Die neue Anwendung kann jedoch das Originalverzeichnis basierend auf der alten Herausgeber-ID finden.)

  • Die Anwendung kann die lokalen Verbindungen nicht länger mit der alten Herausgeber-ID öffnen.

  • Der Identitätsstring, der für den Zugriff auf eine Anwendung von einer Webseite aus verwendet wird, ändert sich.

  • Die OSID der Anwendung ändert sich. (Die OSID wird beim Schreiben von benutzerdefinierten Installations-/Deinstallationsprogrammen verwendet.)

Beim Veröffentlichen eines Updates mit AIR 1.5.3 oder höher kann die Anwendungsidentität nicht geändert werden. Die Original-IDs der Anwendung und des Herausgebers müssen im Anwendungsdeskriptor der Update-AIR-Datei angegeben werden. Andernfalls wird das neue Paket nicht als Update erkannt.

Hinweis: Beim Veröffentlichen einer neuen AIR-Anwendung mit AIR 1.5.3 oder höher sollten Sie keine Herausgeber-ID angeben.

Terminologie

Dieser Abschnitt enthält ein Glossar der wichtigsten Begriffe, die Ihnen bekannt sein sollten, wenn Sie Entscheidungen zur Unterzeichnung Ihrer Anwendung für die öffentliche Verbreitung treffen.

Begriff

Beschreibung

Zertifizierungsstelle (Certification Authority - CA)

Eine Organisation, die Teil der Public-Key-Infrastruktur ist und als vertrauenswürdiger Dritter fungiert, der die Identität des Eigentümers eines öffentlichen Schlüssels beglaubigt. Eine Zertifizierungsstelle gibt in der Regel digitale Zertifikate aus, die durch einen eigenen privaten Schlüssel signiert werden, um zu bezeugen, dass die Identität des Zertifikatinhabers überprüft wurde.

Erklärungen zum Zertifizierungsbetrieb (Certificate Practice Statement - CPS)

Führt die Praktiken und Richtlinien der Zertifizierungsstelle bei der Vergabe und Überprüfung von Zertifikaten auf. Die CPS bilden Teil des Vertrags zwischen der Zertifizierungsstelle und den Zertifikatinhabern und auf die Zertifikate zurückgreifende Dritte. Sie geben außerdem die Richtlinien an, die bei der Identitätsüberprüfung angewendet werden, sowie die Sicherheitsebene, die durch die verfügbaren Zertifikate geboten wird.

Zertifikatsperrliste (Certificate Revocation List - CRL)

Eine Liste der ausgegebenen Zertifikate, die gesperrt wurden und nicht länger bedingungslos vertrauenswürdig sind. AIR überprüft die CRL zu dem Zeitpunkt, an dem die AIR-Anwendung signiert wird und, sofern kein Zeitstempel vergeben wurde, zum Zeitpunkt der Installation.

Zertifikatkette

Eine Zertifikatkette ist eine Abfolge von Zertifikaten, in der jedes Zertifikat in der Kette durch das nächste Zertifikat signiert wurde.

Digitales Zertifikat

Ein digitales Dokument, das Informationen zur Identität des Eigentümers, dem öffentlichen Schlüssel des Eigentümers und der Identität des Zertifikats selbst enthält. Ein Zertifikat, das von einer Zertifizierungsstelle ausgegeben wurde, wird selbst wiederum durch ein Zertifikat der ausgebenden Zertifizierungsstelle signiert.

Digitale Signatur

Verschlüsselte Meldungen oder Digests, die nur mit dem öffentlichen Schlüssel des öffentlich/privaten Schlüsselpaars entschlüsselt werden können. In einer PKI enthalten digitale Unterschriften ein oder mehrere digitale Zertifikate, die sich auf die Zertifizierungsstelle zurückführen lassen. Eine digitale Unterschrift kann verwendet werden, um zu bestätigen, dass eine Meldung (oder eine Computerdatei) seit Unterzeichnung nicht verändert wurde (innerhalb der Einschränkungen, die durch den verwendeten kryptographischen Algorithmus gegeben sind) und um die Identität des Unterzeichnenden zu verifizieren (vorausgesetzt, man betrachtet die Zertifizierungsstelle als vertrauenswürdig).

Keystore

Eine Datenbank, die digitale Zertifikate und in manchen Fällen damit verknüpfte private Schlüssel enthält.

Java Cryptography Architecture (JCA)

Eine erweiterbare Architektur für die Verwaltung von und den Zugriff auf Keystores. Weitere Informationen finden Sie unter Java Cryptography Architecture Reference Guide .

PKCS #11

Der Cryptographic Token Interface Standard von RSA Laboratories. Ein auf Hardware-Token basierender Keystore.

PKCS #12

Der Personal Information Exchange Syntax Standard von RSA Laboratories. Ein Keystore auf Dateibasis, der gewöhnlich einen privaten Schlüssel und damit verknüpfte digitale Zertifikate enthält.

Privater Schlüssel

Die private Hälfte des zweiteiligen, aus privatem und öffentlichem Schlüssel bestehenden asymmetrischen Kryptographiesystems. Der private Schlüssel muss geheim gehalten werden und sollte nie über ein Netzwerk übertragen werden. Digital signierte Meldungen werden mit dem privaten Schlüssel des Unterzeichners verschlüsselt.

Öffentlicher Schlüssel

Die öffentliche Hälfte des zweiteiligen, aus privatem und öffentlichem Schlüssel bestehenden asymmetrischen Kryptographiesystems. Der öffentliche Schlüssel ist offen verfügbar und wird dazu verwendet, mit dem privaten Schlüssel verschlüsselte Meldungen zu entschlüsseln.

Public Key Infrastructure - PKI

Ein auf Vertrauen basierendes System, in dem die Zertifizierungsstelle die Identität der Eigentümer öffentlicher Schlüssel bestätigt. Kunden des Netzwerks vertrauen auf die digitalen Zertifikate, die von einer vertrauenswürdigen Zertifizierungsstelle herausgegeben wurden, um die Identität des Unterzeichners einer digitalen Meldung (oder Datei) zu verifizieren.

Zeitstempel

Ein digital signiertes Datum, das Datum und Uhrzeit des Ereignisses angibt. ADT kann Zeitstempel eines RFC 3161 -konformen Zeitstempelservers in AIR-Pakete aufnehmen. Ist ein Zeitstempel vorhanden, verwendet AIR diesen, um die Gültigkeit des Zertifikats zum Zeitpunkt der Unterzeichnung zu überprüfen. So können AIR-Anwendungen auch dann installiert werden, wenn das signierende Zertifikat ungültig ist.

Zeitstempelvergabestelle

Eine Stelle, die Zeitstempel vergibt. Damit Zeitstempel von AIR anerkannt werden, müssen diese RFC 3161-konform sein und die Zeitstempelsignatur muss über eine Kette mit einem vertrauenswürdigen Stammzertifikat auf dem Installationsgerät verknüpft sein.

iOS-Zertifikate

Die von Apple ausgegebenen Codesignaturzertifikate dienen zum Signieren von iOS-Anwendungen, einschließlich solcher, die mit Adobe AIR entwickelt wurden. Das Anwenden einer Signatur mit einem Apple-Entwicklerzertifikat ist erforderlich, damit eine Anwendung auf Testgeräten installiert werden kann. Das Anwenden einer Signatur mit einem Distributionszertifikat ist erforderlich, um die fertige Anwendung zu verteilen.

Um eine Anwendung zu signieren, muss ADT sowohl auf das Codesignaturzertifikat als auch auf den zugeordneten privaten Schlüssel zugreifen können. Die Zertifikatsdatei selbst enthält den privaten Schlüssel nicht. Sie müssen einen Keystore in Form einer „Personal Information Exchange“-Datei (.p12 oder .pfx) erstellen, die sowohl das Zertifikat als auch den privaten Schlüssel enthält. Siehe Konvertieren eines Entwicklerzertifikats in eine P12-Keystore-Datei .

Generieren einer Zertifikatsignaturanforderung

Um ein Entwicklerzertifikat zu beziehen, generieren Sie eine Zertifikatsignaturanforderung, die Sie an das Apple iOS Provisioning Portal übermitteln.

Der Prozess der Zertifikatsignaturanforderung generiert ein Öffentlich-Privat-Schlüsselpaar. Der private Schlüssel verbleibt auf Ihrem Computer. Sie senden die Signaturanforderung mit dem öffentlichen Schlüssel sowie Ihre Identifizierungsinformationen an Apple, die Zertifizierungsstelle. Apple signiert Ihr Zertifikat mit dem Apple-eigenen „World Wide Developer Relations“-Zertifikat.

Generieren einer Zertifikatsignaturanforderung unter Mac OS

Wenn Sie mit Mac OS arbeiten, können Sie die Schlüsselbundverwaltung verwenden, um eine Codesignaturanforderung zu generieren. Sie finden die Schlüsselbundverwaltung im Dienstprogramm-Unterverzeichnis unter „Programme“. Anweisungen zum Generieren der Zertifikatsignaturanforderung erhalten Sie beim Apple iOS Provisioning Portal.

Generieren einer Zertifikatsignaturanforderung unter Windows

Für Windows-Entwickler ist es vielleicht am einfachsten, das iPhone-Entwicklerzertifikat über einen Mac-Computer zu beziehen. Es ist jedoch auch möglich, für den Erwerb eines Zertifikats einen Windows-Computer zu benutzen. Erstellen Sie zunächst eine Zertifikatsignaturanforderung (eine CSR-Datei) mit OpenSSL:

  1. Installieren Sie OpenSSL auf dem Windows-Computer. (Gehen Sie zu http://www.openssl.org/related/binaries.html .)

    Möglicherweise müssen Sie auch die Dateien für Visual C++ 2008 Redistributable installieren, die auf der Open SSL-Downloadseite aufgeführt sind. (Sie brauchen jedoch nicht Visual C++ auf Ihrem Computer zu installieren.)

  2. Öffnen Sie ein Windows-Befehlseingabefenster und wechseln Sie zum Open-SSL-bin-Verzeichnis (zum Beispiel c:\OpenSSL\bin\).

  3. Erstellen Sie den privaten Schlüssel, indem Sie Folgendes in die Befehlszeile eingeben: 

    openssl genrsa -out mykey.key 2048

    Speichern Sie diese private Schlüsseldatei. Sie benötigen sie später.

    Wenn Sie OpenSSL verwenden, ignorieren Sie etwaige Fehlermeldungen nicht. Wenn OpenSSL eine Fehlermeldung generiert, werden möglicherweise dennoch Dateien ausgegeben. Diese Dateien sind jedoch nicht verwendbar. Wenn Fehler auftreten, überprüfen Sie die Syntax und führen Sie den Befehl erneut aus.

  4. Erstellen Sie die CSR-Datei, indem Sie Folgendes in die Befehlszeile eingeben: 

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

    Ersetzen Sie die E-Mail-Adresse, CN (Zertifikatname) und C (Land) durch die für Sie geltenden Werte.

  5. Laden Sie die CSR-Datei auf der iPhone Entwickler-Site an Apple hoch. (Siehe „Anfordern von iPhone-Entwicklerzertifikaten und Erstellen eines Provisioning-Profils“.)

Konvertieren eines Entwicklerzertifikats in eine P12-Keystore-Datei

Um einen P12-Keystore zu generieren, müssen Sie Ihr Apple-Entwicklerzertifikat und den dazugehörigen privaten Schlüssel in einer Datei zusammenführen. Wie die Keystore-Datei erstellt wird, richtet sich nach der Methode, die Sie zum Generieren der ursprünglichen Zertifikatsignaturanforderung verwendet haben, und nach dem Speicherort des privaten Schlüssels.

Konvertieren von iPhone-Entwicklerzertifikaten in P12-Dateien unter Mac OS

Nachdem Sie das Apple-iPhone-Zertifikat von Apple heruntergeladen haben, exportieren Sie es in das P12-Keystore-Format. Unter Mac® OS gehen Sie dazu folgendermaßen vor:

  1. Öffnen Sie die Schlüsselbundverwaltung (unter „Programme/Dienstprogramme“).

  2. Wenn Sie das Zertifikat noch nicht dem Schlüsselbund hinzugefügt haben, wählen Sie „Ablage“ > „Importieren“. Navigieren Sie dann zu der Zertifikatsdatei (.cer-Datei), die Sie von Apple erhalten haben.

  3. Wählen Sie in der Schlüsselbundverwaltung die Kategorie „Schlüssel“.

  4. Wählen Sie den privaten Schlüssel aus, der Ihrem iPhone-Entwicklerzertifikat zugeordnet ist.

    Der private Schlüssel wird durch das öffentliche Zertifikat iPhone-Entwickler: <Vorname> <Nachname> identifiziert, das mit ihm verknüpft ist.

  5. Klicken Sie bei gedrückter Befehlstaste auf das iPhone-Entwicklerzertifikat und wählen Sie „iPhone Developer: Name...“ exportieren .

  6. Speichern Sie den Keystore im Dateiformat Personal Information Exchange (.p12).

  7. Sie werden aufgefordert, ein Kennwort zu erstellen, das verwendet wird, wenn Sie mit dem Keystore Anwendungen signieren oder den Schlüssel und das Zertifikat in diesem Keystore an einen anderen Keystore übertragen.

Konvertieren von Apple-Entwicklerzertifikaten in P12-Dateien unter Windows

Wenn Sie Anwendungen mit AIR for iOS erstellen möchten, müssen Sie eine P12-Zertifikatdatei verwenden. Sie generieren dieses Zertifikat basierend auf der Apple iPhone-Entwicklerzertifikatdatei, die Sie von Apple erhalten.

  1. Konvertieren Sie die Entwicklerzertifikatdatei von Apple in eine PEM-Zertifikatdatei. Führen Sie die folgenden Befehlszeilenanweisungen aus dem OpenSSL-Verzeichnis „bin“ aus: 

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

  2. Wenn Sie den privaten Schlüssel aus der Schlüsselbundverwaltung auf einem Mac-Computer verwenden, konvertieren Sie ihn in einen PEM-Schlüssel: 

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

  3. Sie können jetzt eine gültige P12-Datei generieren, die auf dem Schlüssel und der PEM-Version des iPhone-Entwicklerzertifikats basiert: 

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

    Wenn Sie einen Schlüssel aus der Mac OS-Schlüsselbundverwaltung benutzen, verwenden Sie die PE-Version, die Sie im vorherigen Schritt generiert haben. Andernfalls verwenden Sie den OpenSSL-Schlüssel, den Sie zuvor erstellt haben (unter Windows).