Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
de:dfnpki:faq:codesigning [2018/06/01 14:56] Heike Ausserfeldde:dfnpki:faq:codesigning [Unbekanntes Datum] (aktuell) – gelöscht - Externe Bearbeitung (Unbekanntes Datum) 127.0.0.1
Zeile 1: Zeile 1:
-~~NOTOC~~ 
-===== Fragen und Antworten zum Code-Signing mit Zertifikaten aus der DFN-PKI ===== 
- 
-{{INLINETOC 3-4}} 
- 
-===1. Was ist Code-Signing und Object-Signing?=== 
- 
-Code-Signing oder auch Object-Signing ist das Signieren von Programm- oder Skript-Code, um dessen Integrität und Authentizität sicherzustellen. Welche Programme oder Skripte signiert werden können und welche Werkzeuge verwendet werden müssen, hängt von der dazugehörigen Umgebung ab. 
-Code-Signing gibt es für Java Applets, Java Web-Start-Applikationen, Microsoft Office Macros, VBScript bzw. Powershell-Skripte, Windows Treiber, Android Apps und viele weitere. 
- 
-===2. Welche Code-Signing Umgebungen unterstützt die DFN-PKI?=== 
- 
-In der DFN-PKI wird Java Code-Signing im Sicherheitsniveau „Global” voll unterstützt. 
- 
-Microsoft Windows Code-Signing (egal für welchen Einsatzzweck) wird nicht direkt unterstützt, da das Wurzelzertifikat der DFN-PKI „Global” in Microsoft Windows für diesen Zweck nicht freigeschaltet ist. Weitere Hinweise finden Sie unter Punkt 5. 
- 
-Android Apps werden insbesondere für den Google Play Store mit selbst-signierten Zertifikaten signiert, die direkt durch die Entwicklerwerkzeuge generiert werden. Daher gibt es keine Notwendigkeit, hierfür die DFN-PKI zu verwenden. Weitere Erläuterungen finden Sie unter Punkt 6. 
- 
-===3. Wie wird ein Code-Signing Zertifikat beantragt?=== 
- 
-Code-Signing-Zertifikate können folgendermaßen über die CA Ihrer Einrichtung bezogen werden: 
- 
-  * Beantragen Sie das Code-Signing Zertifikat mit Ihrem Webbrowser über den Antragsweg „Nutzerzertifikat”. Wählen Sie als Namen im Zertifikat //„PN: <Vorname Nachname> - CodeSigning”//, und verwenden Sie gegebenenfalls eine rollenbasierte E-Mail-Adresse. Wir empfehlen, das Zertifikat nicht veröffentlichen zu lassen. Merken Sie sich die von Ihnen vergebene (Sperr-)PIN sehr gut, denn Sie benötigen diese zum späteren Import des ausgestellten Zertifikats in Ihren Webbrowser. 
-  * Duch die Beantragung wird in Ihrem Webbrowser ein privater Schlüssel erzeugt. 
-  * Teilen Sie Ihrem Teilnehmerservice bei Abgabe des unterschriebenen Papier-Antrages mit, dass Sie ein Code-Signing Zertifikat benötigen, damit der Teilnehmerservice das korrekte Zertifikatsprofil setzen kann. 
-  * Nach der Ausstellung des Code-Signing Zertifikats erhalten Sie eine E-Mail. Folgen Sie der Anleitung in der E-Mail, um alle CA-Zertifikate und das neue Zertifikat korrekt in Ihren Webbrowser zu importieren. 
-  * Exportieren Sie das Zertifikat zusammen mit dem privaten Schlüssel über den Zertifikatmanager des Browsers als PKCS#12-Datei. Wählen Sie dabei ein starkes Passwort, und speichern Sie die PKCS#12-Datei möglichst auf einem externen, nicht dauerhaft an Ihren Rechner angeschlossenen Medium wie einen USB-Stick. 
-  * Löschen Sie anschließend das Zertifikat aus dem Zertifikatmanager Ihres Browsers. 
- 
-===4. Wie wird ein Code-Signing Zertifkat für das Signieren von Java-Code verwendet?=== 
- 
-Zum Signieren von Java-Code werden die Werkzeuge keytool und jarsigner benötigt, die im Java SDK enthalten sind. Wir empfehlen die Verwendung von Schlüsseln in PKCS#12-Dateien (siehe voriger Abschnitt), da die Arbeit mit dem nativen Java-Keystore (über das Werkzeug „keytool”) komplizierter und fehleranfälliger ist. 
-Bevor Sie eine PKCS#12-Datei zum Signieren verwenden können, müssen Sie den Parameter „<Alias>” in Erfahrung bringen. Hierzu verwenden Sie den folgenden Befehl 
- 
-  keytool -list -keystore <PKCS#12-Datei> -storetype pkcs12 
- 
-Sie erhalten die folgende Ausgabe, in der Sie vor dem Zertifikat-Fingerprint den Alias finden: 
- 
-<code>Keystore-Typ: PKCS12 
-Keystore-Provider: SunJSSE 
- 
-Keystore enthält 1 Eintrag 
- 
-<Alias>, 20.02.2015, PrivateKeyEntry, 
-Zertifikat-Fingerprint (SHA1):\\  
-48:B5:50:C5:18:48:9E:29:59:30:B2:1C:7A:A0:15:7E:CF:85:46:93</code> 
- 
-Das Signieren erfolgt mit folgendem Aufruf: 
- 
-<code>jarsigner -tsa zeitstempel.dfn.de -keystore <PKCS#12-Datei> -storetype pkcs12 <Zu signierendes JAR> '<Alias>'</code> 
- 
-Optional kann, entgegen teilweise anzutreffender Dokumentation, ein Proxy für den Zeitstempelserver angegeben werden. Die zusätzlichen Parameter hierfür sind: 
- 
-<code>-J-Dhttp.proxyHost=<ProxyHost> -J-Dhttp.proxyPort=<ProxyPort></code> 
- 
-Online-Resourcen zum Thema finden sich unter folgenden Links: 
- 
-http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html\\ 
-http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/manifest.html#A1148525 
- 
-===5. Was ist beim Code-Signing in Microsoft Windows zu beachten?=== 
- 
-Die beiden Wurzel-CA-Zertifikate der alten DFN-PKI Hierarchie "Deutsche Telekom Root CA 2" und der neuen DFN-PKI Hierarchie "T-TeleSec GlobalRoot Class 2" sind im Windows-Zertifikatsspeicher nicht für den Zertifikats­zweck "Codesignatur" freigeschaltet. 
- 
-Obwohl es technisch nicht vollkommen ausgeschlossen ist, die Zertifikate der DFN-PKI „Global” für Code-Signing unter Windows zu verwenden, empfehlen wir dies nicht. 
- 
-Damit Windows-Systeme die Code-Signing-Zertifikate der DFN-PKI als solche akzeptieren, muss auf den Windows-Systemen im Windows-eigenen Zertifikatmanager in den Eigenschaften des "Deutsche Telekom Root CA 2" Zertifikats bzw. "T-TeleSec GlobalRoot Class 2" Zertifikats der Zertifikatszweck "Codesignatur" aktiviert werden. 
- 
-Diese Änderung kann auf jedem betroffenen Windows-System manuell durchgeführt werden. Da Microsofts Auto-Update-Mechanismen diese manuell gemachte Einstellung unserer Erfahrung nach sporadisch (ohne erkennbares Muster) zurücksetzen, wird nicht empfohlen, dieses Vorgehen zu wählen. 
- 
-Diese Einstellung kann darüber hinaus über eine Windows-Gruppenrichtlinie an alle Mitglieder einer vorhandenen Windows-Domäne verteilt werden. In diesem Fall wird die Einstellung nicht automatisch zurückgesetzt. Für Windows-Systeme, die nicht Mitglied in einer entsprechenden zentral verwalteten Windows-Domäne sind, ist dieses Vorgehen allerdings nicht möglich. 
- 
-Vorsicht mit automatischen kritischen Prozessen, die diese signierten Programme/Skripte/Macros benutzen und ggf. nicht mehr laufen, falls sich der Zertifikatszweck (unbemerkt) zurückgesetzt hat. 
- 
-===6. Was ist beim Code-Signing von Android Apps für Google Play zu beachten?=== 
- 
-Obwohl es technisch nicht vollkommen ausgeschlossen ist, die Zertifikate der DFN-PKI „Global” für Code-Signing unter Android zu verwenden, empfehlen wir dies nicht. 
- 
-Zum Signieren von Android Apps für Google Play werden selbst-signierte Zertifikate mit einer sehr langen Laufzeit verwendet. Diese selbst-signierten Zertifikate werden üblicherweise direkt von den Android Entwicklertools erzeugt. 
- 
-Das Zertifikat hat bei Android keine Sicherheitsfunktion bzgl. Identifizierung. Das Signieren und die Verwendung von Zertifikaten dient ausschließlich dazu, Updates sicher zu einer Ursprungs-App zurück zu verfolgen, und **nicht**, um den Entwickler zu identifizieren. Die Nutzung von Zertifikaten aus einer PKI bringt daher keine Vorteile. Die Verwendung von selbst-signierten Zertifikaten ist, wenn auch ungewohnt, sicherheitstechnisch angemessen. 
- 
-Wie man sich ein selbst-signiertes Zertifikat mit Android Studio erzeugt, ist auf der folgenden Seite beschrieben: 
- 
-http://developer.android.com/tools/publishing/app-signing.html#studio 
  
  • Zuletzt geändert: vor 6 Jahren