Java-Applets und Java WebStart-Anwendungen signieren

Anwendung signieren

Dieser Beitrag wird derzeit noch bearbeitet. Der Text ist deshalb unvollständig und kann Fehler oder ungeprüfte Aussagen enthalten.

Java-Applets haben seit Java 7 Update 51 keine Rechte mehr auf dem Gastsystem! Es muss mindestens eine Anpassung der Sicherheitseinstellungen im Java Control Panel erfolgen.
Der Artikel Java Applets starten - ab Java 7 Update 51 befasst sich eingehender mit der Inbetriebnahme von Java-Applets.

Unsignierte Applets haben außerdem keinen Zugriff auf die lokale Datei- und Verzeichnisebene des Clients und dürfen sich nur zu dem Rechner verbinden, von dem sie auch heruntergeladen wurden. Für Applikationen erlaubte Dinge, wie Ports öffnen, sensible oder persönliche Daten aus dem Client-PC auslesen oder die VM beenden, sind einem unsignierten Applet ebenfalls untersagt.

Ein nicht signiertes Applet wird daher bei einem unerlaubten Zugriff immer eine java.security.AccessControlException werfen.

Hinweis: Signierte Applets können jedoch erweiterte Rechte auf dem Client erhalten.

Möglichkeiten der Signierung

Es gibt zwei Möglichkeiten eine Java-Anwendung zu signieren:

1. Die kostenpflichtige Ausstellung eines Zertifikats von einem darauf spezialisierten Unternehmen, wie z.B. VeriSign (ehem. Thawte). So ein Zertifikat kann mehrere 100 Dollar kosten.
2. Die Signierung des Programms durch den Programmierer selbst.

Dabei wird mit den Tools des JDK/SDK ein Zertifikat erzeugt. Auch die Erzeugung eines Zertifikats mittels OpenSSL ist denkbar.

In beiden Fällen öffnet sich vor dem Start der Anwendung ein Fenster mit einem Sicherheitshinweis, welches sich vom Benutzer die Erlaubnis einholt, eventuell potenziell unsichere/gefährliche Operationen auf seinem System durchführen zu dürfen.
Der Benutzer selbst muss entscheiden, ob er dem Applet vertrauen möchte, oder nicht.

Warn-, Hinweis- oder Informationsdialoge

Die Dialoge vor dem Start eines Java-Applets sehen sehr verschieden aus und unterscheiden sich in ihrer optischen Auffälligkeit.
Je aggressiver der Warndialog optisch dargestellt wird, um so weniger sollte man dem Applet dahinter vertrauen.

Der Informationsdialog, dass ein Applet gestartet werden soll, welches ein beglaubigtes Zertifikat besitzt, sie so aus:

Der Warndialog, dass ein Applet gestartet werden soll, dessen Herkunft nicht beglaubigt wurde, also das Applet selbst signiert wurde, sie so aus:

Hinweis: Die Informationsdialoge sind in keinem Fall modifizierbar oder unterdrückbar.

Hinweis: Wenn die Anwendung mit einem selbst erzeugten Zertifikat signiert wurde, wird der Hersteller immer als 'UNKNOWN' ausgewiesen.

Dieser Beitrag wird derzeit noch bearbeitet. Der Text ist deshalb unvollständig und kann Fehler oder ungeprüfte Aussagen enthalten.

Hier kannst du auch ein signiertes Applet testen. Es wird einige System-Informationen aus deinem System lesen und anzeigen, wenn du den Zugriff gestattest. Zugriffe, die erweiterte Rechte benötigen sind im Applet pink dargestellt. (Link wird nachgereicht!)

Häufig ist zu beobachten, dass Programmierer in ihren Applets Bilder mit den verkehrten Methoden einbinden. Dazu mehr unter Grafikdateien laden und anzeigen.

Hinweis: Zum Signieren eines Java-Applets muss dieses in einer Jar-Datei gespeichert sein.

SignTool für Windows

Folgende kleine Batchdatei, kann das komfortable Erstellen einer Jar-Datei und anschließende Signieren eines Applets vereinfachen. Einfach die blauen Texte der Datei mit Hilfe eines Texteditors modifizieren, unter einem Namen wie bspw. SignTool.bat in deinem Projektverzeichnis speichern und per Doppelklick ausführen.

Hinweis: Die Batchdatei darf auf keinen Fall den Namen eines der Tools aus dem JDK erhalten!

@echo off
rem * SignTool by L-ectron-X ( byte-welt.net )
rem **************************************************************************
rem * Ablauf beim Signieren
rem *
rem * Erzeugen eines eigenen Schlüssels
rem * keytool -genkeypair -alias Signer -dname "cn=Dein Name, c=de"
rem *
rem * Erzeugen eines verschlüsselten Zertifikats:
rem * keytool -selfcert -alias Signer -dname "cn=Dein Name, c=de"
rem * Gib anschließend Dein Passwort ein.
rem *
rem * keytool unterstützt weitere Angaben:
rem * CN=commonName
rem * OU=organizationUnit
rem * O=organizationName
rem * L=localityName
rem * S=stateName
rem * C=country
rem *
rem * Mehr über keytool: http://docs.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html 
rem *
rem * Signieren des Applets mit Hilfe des Tools jarsigner
rem * jarsigner signed.jar Signer
rem * Und noch einmal dein Passwort eingeben.
rem ***************************************************************************
echo = SignTool =
echo Dieses Tool hilft beim Erzeugen von signierten jar-Dateien
echo.
echo Schritt 1: jar-Dateien erzeugen
echo -------------------------------

rem Pfad zum SDK setzen 
rem --> optional, (auskommentieren, wenn eine Umgebungsvariable gesetzt wurde)
set java_home=.;C:\Programme\Java\jdk1.8.0\bin
set path=.;%path%;%java_home%

echo Manifestdatei erzeugen...
echo Manifest-Version: 1.0>manifest.mf 
echo Created-by: SignTool by L-ectron-X - byte-welt.net>>manifest.mf

rem --> Anpassen, wenn eine Applikation statt eines Applets signiert werden soll!
rem * Applikationen brauchen die Main-Class-Definition im Manifest. Dann ist das rem zu entfernen.
rem echo Main-Class: package.MainClass>>manifest.mf

rem --> Anpassen, wenn das Applet bzw. die Applikation Resourcen weiterer Jar-Dateien benutzt!
rem echo Class-Path: ./lib/External.jar>>manifest.mf

rem --> Anpassen, wenn eine Webstart-Applikation oder ein Applet, JNLP benutzt, muss der Wert mit dem im JNLP-File übereinstimmen.
rem * Es wird zwischen den Werten sandbox und all-permissions unterschieden.
rem * Wenn im Applet-Tag keine Permission angegeben wurde, gilt der Standardwert: all-permissions für signierte, sandbox für unsignierte Applets
rem * Wenn das Permission-Attribut im Manifest nicht angegeben wird, wird die Anwendung blockiert!
rem * Mehr dazu unter http://docs.oracle.com/javase/8/docs/technotes/guides/jweb/security/manifest.html#permissions
echo Permissions: sandbox>>manifest.mf

rem --> Anpassen, wenn verhindert werden soll, dass die Anwendung auf einer anderen Domain 're-deployed' wird.
rem * Die Domain muss mit dem Speicherort der Anwendung übereinstimmen, sonst wird die Anwendung blockiert.
rem * Mehr dazu unter http://docs.oracle.com/javase/8/docs/technotes/guides/jweb/security/manifest.html#codebase
rem echo Codebase: http://byte-welt.net>>manifest.mf

rem --> Anpassen, es wird empfohlen, den Namen der Anwendung anzugeben.
rem * Der Name wird im Warndialog angezeigt und soll dem Benutzer die Entscheidung erleichtern, der Anwendung zu vertrauen.
rem * Mehr dazu unter http://docs.oracle.com/javase/8/docs/technotes/guides/jweb/security/manifest.html#app_name
rem echo Application-Name: Hallo Welt!>>manifest.mf

rem * Leerzeile nicht vergessen!
echo.>>manifest.mf

if exist *.jar goto key
echo jar-Datei mit angegebenen Parametern erzeugen...
rem --> anpassen!
rem * In folgendem Beispiel werden alle .class-Dateien mit Package (de.domain.applets) und die Verzeichnisse bilder und etc
rem * mit ins jar-Archiv gepackt.
jar cfmv MeinJar.jar manifest.mf de/domain/applets/*.class bilder etc

:key
echo.
echo Schritt 2: Schluessel generieren
echo -----------------------------------------------
rem --> anpassen!
rem -validity 18250 (365 Tage x 50) erzeugt ein 50 Jahre gültiges Zertifikat
keytool -genkeypair -alias Signer -dname "cn=Dein Name, c=de"

echo.
echo Schritt 3: Zertifikat generieren
echo -----------------------------------------------
rem --> anpassen!
rem -validity 18250 (365 Tage x 50) erzeugt ein 50 Jahre gültiges Zertifikat
keytool -selfcert -validity 3650 -alias Signer -dname "cn=Dein Name, c=de"

if not exist *.jar goto error

echo.
echo Schritt 4: jar-Datei signieren
echo ------------------------------
echo jarsigner erwartet hier nochmals dein Passwort.
rem --> anpassen!
jarsigner MeinJar.jar Signer

echo.
echo Schritt 5: Zertifikat testen
echo ----------------------------
rem --> anpassen!
jarsigner -verify -verbose -certs MeinJar.jar
goto end

:error
echo.
echo Es wurde keine jar-Datei zum Signieren gefunden.
echo Die Erzeugung der jar-Datei ist moeglicherweise fehlgeschlagen.
echo Pruefe deine Modifikationen in der SignTool-Batchdatei!
goto console
 
:end
if not exist manifest.mf goto console
echo.
rem Manifest von Festplatte löschen
del manifest.mf
echo Zur Kontrolle: Ein paar Zeilen weiter oben sollte nun 'jar signed' stehen!
echo Das ist die Bestaetigung dafür, dass die Jar-Datei sigiert wurde.

:console
rem Console für Ausgaben noch geöffnet lassen
echo.
pause

In deinem Projekt-Verzeichnis sollte vorzugsweise noch keine jar-Datei angelegt sein, das Tool wird dann auch eine korrekte jar-Datei aus deinen .class-Dateien erzeugen können. Auch wenn Du eine jar-Datei schon erzeugt hast und nur die Signierung mit Hilfe dieser Batchdatei durchführen möchtest, genügt die Modifikation der Batchdatei an den ausgewiesenen Stellen. Wenn du bisher noch keine Signierung gemacht hast, wirst du im Verlauf des Batchdatei-Ablaufes nach einem Passwort gefragt, welches du selbst wählen kannst. Merke es dir gut. Wenn du es vergisst, kannst du so lange keine weiteren Applets signieren, bis du die .keystore-Datei aus deinem Benutzer-Verzeichnis gelöscht hast.

Damit das nun in einer Jar-Datei verpackte und signierte Applet auch ausgeführt werden kann, muss die HTML-Datei angepasst werden:
Einbinden von Applets in HTML-Dateien

Für Webstart-Anwendungen müsste noch die JNLP-Datei angepasst werden, damit sie mit Annahme des Zertifikats (Vertrauenserklärung) alle Rechte des Benutzers auf seinem Rechner erhält:
<code=xml> <security>

  <all-permissions/>

</security> </code=xml>

Weitere Infos: JAR File Overview

Fehlermeldungen

• Der Interpreter meldet, dass in einer signierten Jar-Datei ein unsignierter Eintrag gefunden wurde:

com.sun.deploy.net.JARSigningException: Unsignierter Eintrag in Ressource: <Jar file>

Wenn es Dateinamen mit Umlauten in der Jar-Datei gibt, kann es passieren, dass diese nicht signiert werden (können).
Also sollten diese umbenannt, die referenzierenden Dateien aktualisiert und die Jar-Datei erneut signiert werden. Unter Umständen wird es notwendig, die .ds- und .dsa-Dateien aus dem META-INF-Verzeichnis der Jar-Datei zu löschen, damit beim erneuten Signieren saubere Schlüsseldateien erzeugt werden könnnen.

Die Alternative

Wer nicht signieren möchte, kann das Problem auch mit der JNLP-API angehen. Hier ein Beispiel, wie man ohne Signieren vom Client lesen und auch auf ihn schreiben kann:

• Oracle - Accessing the Client Using JNLP API

Weiterführende Links

• Understanding Signing and Verification (The Java™ Tutorials > Deployment > Packaging Programs in JAR Files)
• keytool-Key and Certificate Management Tool
• jarsigner-JAR Signing and Verification Tool
• Accessing the Client Using JNLP API (The Java™ Tutorials > Deployment > Doing More With Java Rich Internet Applications)
• JNLP File Syntax

-- L-ectron-X (15.05.2005, 18:58)