7 WebShare Webserver

Der WebShare Webserver („webshare.woa“) ist ein Java-Programm, welches auf einem Server mit Internetanbindung läuft. Er kann auf demselben Host wie der WebShare File Server installiert werden. In diesem Fall spricht man von einer „Ein-Server-Lösung“. In Bezug auf die Datensicherheit sollte der WebShare Webserver jedoch auf einer separaten Maschine, als zweistufiger Serveraufbau, installiert werden.

Im Idealfall laufen auf dem WebShare Webserver keinen weiteren Anwendungen oder Dienste. Der Vorteil dieser eigenständigen Lösung ist, dass alle Ports und Dienste, die nicht von WebShare benötigt werden, abgeschaltet werden können (z. B. durch Soft- oder Hardware Firewalls).

Da keine Dateien auf dem WebShare Webserver gespeichert oder temporär abgelegt werden, ist ein Höchstmaß an Datensicherheit auf dem WebShare File Server gewährleistet. Der WebShare Webserver benutzt für alle Webclients einen TCP/IP Port (Standard: 2009).

Während der WebShare Installation wird die gepackte Datei „websharewoa.tar“ in das Verzeichnis „HELIOSDIR/etc/webshare“ installiert. Das Kommando „start-helios“ entpackt die Datei dann in das Verzeichnis „HELIOSDIR/var/run“ in das Paket „webshare.woa“.

7.1 WebShare Lizenzinformationen

WebShare als Produkt beinhaltet zwei Serverkomponenten: den WebShare File Server, der auf einem bestehenden HELIOS Server mit dessen Maschinen-ID (mach ID) lizensiert wird sowie den WebShare Webserver, der auf einem separaten Server installiert werden kann. Der WebShare Webserver benötigt als Komponente des WebShare Serverprodukts keinen separaten WebShare Aktivierungsschlüssel.

Sie müssen während der Installation die HELIOS Software-Lizenzbestimmungen akzeptieren. Diese finden Sie auf unserer Produkt-CD.

7.2 Dateien auf dem WebShare Webserver

Im Ordner „HELIOSDIR/var/run/webshare.woa/Contents/Resources/“ befinden sich im Paket „Contents/Resources“ folgende Dateien:

Accounting.wo/: HTML-Abrechnungskomponente
AccountingDetails.wo/: HTML-Seitenkomponente für detaillierte Abrechnungsinformationen
AdmPrefs.wo/: HTML-Seitenkomponente für die Verwaltung von Präferenzen
AdmShares.wo/: HTML-Seitenkomponente für die Verwaltung von Sharepoints
AdmUsers.wo/: HTML-Seitenkomponente für die Verwaltung von Benutzern
Admin.wo/: HTML-Seitenkomponente für die Hauptverwaltung
FileBrowser.wo/: HTML-Komponente zum Durchsuchen von Dateien und Verzeichnissen
FilePreview.wo/: HTML-Komponente für Voransichten von Dokumenten und Bildern
ForgotPassword.wo/: HTML-Vorgabekomponente für vergessene Kennwörter
Goodbye.wo/: HTML-Seitenkomponente für die Abmeldung vom Server
Login.wo/: HTML-Seitenkomponente für die Anmeldung am Server
Main.wo/: Begrüßungs- und Serverauswahl-Seitenkomponente
PagePreview.wo/: HTML-Komponente für detaillierte Proofs
RegisterNewUser.wo/: HTML-Vorgabekomponente zum Registrieren neuer Benutzer
Sharepoints.wo/: HTML-Seitenkomponente zum Erstellen von Sharepointlisten
Upload.wo/: HTML-Komponente zum Hochladen von Dateien
UserPrefs.wo/: HTML-Seitenkomponente für Benutzereinstellungen
WSBrandingEditor.wo/: HTML-Komponente für den Branding Editor
WSCSSComponent.wo/: Systeminterne Komponente
WSExceptionPage.wo/: Systeminterne Komponente
WSFileAnnotationsContent.wo/: Systeminterne Komponente
WSFileAnnotationsEntryContent.wo/: Systeminterne Komponente
WSFileAnnotationsTemplate.wo/: Vorlage für Anmerkungsdialog
WSFileListingMenu.wo/: Systeminterne Komponente
WSOpenFile.wo/: Vorlage für Seite „Datei öffnen“
WSToolbar.wo/: HTML-Komponente für die Menüleiste
WSToolbarButton.wo/: Systeminterne Komponente
WSToolbarLink.wo/: Systeminterne Komponente
WSUploadForm.wo/: Systeminterne Komponente
WSUploadReport.wo/: Systeminterne Komponente
WSUploadStatus.wo/: Systeminterne Komponente
WebShareStats.wo/: HTML-Seitenkomponente für die Serverstatistik
ZipDownload.wo/: Systeminterne Komponente

Jedes einzelne „*.wo“-Verzeichnis enthält die Dateien „*.html“, „*.wod“ und „*.woo“.

Das Skript „sbin/start-websharewoa“ startet den WebShare Webserver. Normalerweise wird dieser jedoch mit dem Kommando „srvutil start websharewoa“ während des Aufrufs „start-helios“ gestartet. Für den Fall, dass es beim Start des Dienstes zu Problemen kommen sollte, kann dieser auch manuell aufgerufen werden. Etwaige Fehlermeldungen werden dann im Terminalfenster angezeigt:

# cd /usr/local/helios 
# sbin/start-websharewoa

Ergänzende Meldungen werden in die WebObjects-Logdateien geschrieben. Diese befinden sich im Verzeichnis „HELIOSDIR/var/adm/“ und haben den Dateinamen „websharewoa.log“. Sie bekommen „.0“ (gestern), bis „.6“ (vor sieben Tagen) an den Dateinamen angehängt. Alle internen WebObjects-Meldungen werden in die Datei „websharewoa.log“, die von HELIOS erzeugten WebShare Webserver-Meldungen in die Systemmeldungen geschrieben.

7.3 Benutzerdefinierte Anpassung/Lokalisierung

Die Benutzeroberfläche in WebShare unterstützt mehrere Sprachen, die der Benutzer auswählen kann. Dieses Kapitel beschreibt, wie Sie eine bestehende Sprachversion anpassen können.

Hinweis:: Dieser Abschnitt behandelt die benutzerdefinierte Anpassung des Pakets „webshare.woa“. Wollen Sie keine Anpassung vornehmen, so können Sie diesen Abschnitt überspringen

: Um persönliche Anpassungen auf dem WebShare Webserver vorzunehmen, kopieren Sie bitte das Paket „webshare.woa“ von „HELIOSDIR/var/run“ nach „HELIOSDIR/var/webshare“.

Die Anpassungen sollen ausschließlich in „var/webshare“ vorgenommen werden, da WebShare nach jedem Start im Verzeichnis „var/webshare“ nach „webshare.woa“ sucht. Nur wenn „webshare.woa“ dort nicht gefunden werden kann, wird die Kopie aus „var/run“ verwendet. Die Idee dabei ist, dass z. B. bei einer Softwareaktualisierung „webshare.woa“ immer in „var/run“ ersetzt wird. Angepasste Dateien in „var/webshare“ werden nicht überschrieben.

Hinweis:: Für neue WebShare Produktversionen oder Updates, die neue Funktionen einführen, müssen Sie jedoch „webshare.woa“ wieder von „var/run“ nach „var/webshare“ kopieren, was das alte Paket überschreibt, und dann die Anpassungen erneut vornehmen. Andernfalls besteht die Gefahr, dass das Paket nicht mehr mit dem WebShare File Server kompatibel ist oder neue Funktionen nicht zur Verfügung stehen.

7.3.1 „*.html“-Dateien anpassen

Benutzen Sie beim Anpassen aller „*.html“-Dateien UTF-8-Zeichen. Damit Änderungen an den „*.html“-Dateien wirksam werden, muss der Dienst „websharewoa“ gestoppt und wieder neu gestartet werden.

7.3.2 „*.wod“-Dateien anpassen

Benutzen Sie beim Anpassen aller „*.wod“-Dateien UTF-8-Zeichen. Sie können dies mit jedem anderen UTF-8-kompatiblen Texteditor tun. Damit Änderungen an den „*.wod“-Dateien wirksam werden muss der Dienst „websharewoa“ gestoppt und wieder neu gestartet werden.

7.3.3 Aktionsskripte anpassen

Eigene Aktionsskripte lassen sich anpassen, indem Sie den gewünschten Titel des Skripts über #Title=<UTF-8-Name> innerhalb der ersten 5 Zeilen in das Skript kopieren. Gleichermaßen können Sie in jedem Skript auch den Kommentar #NameField= bearbeiten. Wenn Sie nach der nächsten Anmeldung aus dem WebShare Menüleisteneintrag „Aktionen“ das Skript ausgewählt haben, erscheint ein Textfeld, über das sich dem Skript Werte übergeben lassen.

Detaillierte Informationen darüber, wie benutzerdefinierte oder Aktionsskripte angelegt oder verändert werden finden Sie in Kapitel 8.4 „WebShare Skripte“.

7.3.4 Weitere Sprachen

WebShare unterstützt Englisch, Deutsch, Französisch, Spanisch und Japanisch. Unterstützung für zusätzliche Sprachen wird ausschließlich von HELIOS bereitgestellt. Haben Sie den Wunsch, Unterstützung für weitere Sprachen zu erhalten, dann fragen Sie bitte Ihren HELIOS Partner.

Hinweis:: Sollen Anpassungen auch für lokalisierten Ressourcen gelten, müssen die Ordner „<Sprache>.lproj“ auch angepasst werden.

7.4 Unterstützung für HTTPS/SSL

7.4.1 Einleitung

Dieser Abschnitt umreißt kurz die Konfiguration Ihrer SSL Installation. Die HELIOS WebShare SSL Unterstützung wird durch standardmäßiges Java SSL realisiert. In dieser Dokumentation beschreiben wir die Benutzung der Standard-Sicherheitswerkzeuge (ab JDK 1.6) zur Einrichtung von SSL.

Was bedeutet SSL?

SSL (Secure Sockets Layer) ist ein Protokoll, welches von der Netscape Communications Corporation für die verschlüsselte Übertragung von Daten über das Internet entwickelt wurde. SSL liegt unter Anwendungsprotokollen wie HTTP, SMTP, FTP, Telnet, Gopher und NNTP, und setzt auf dem Verbindungsprotokoll TCP/IP auf. Es wird via HTTPS benutzt. SSL benutzt zur Verschlüsselung der zu übertragenden Daten einen geheimen Schlüssel. Die meisten aktuellen Browser unterstützen SSL und viele Webseiten verwenden dieses Protokoll beim Transfer persönlicher oder geheimer Daten, z. B. Kreditkartennummern. Die Konvention gibt vor, dass die URLs von Webseiten, die über SSL aufgerufen werden, mit https: anstatt http: beginnen.

7.4.2 Hintergrund

Ein Server mit SSL-Aktivierung verwendet gewöhnlich eine gesicherte Datei oder Datenbank, eine so genannte Keystore-Datei zur Speicherung von Schlüsseln und Zertifikaten. Diese Sicherheitszertifikate dienen dem Client als Beweis, dass der Server tatsächlich zu einer bestimmten Domain gehört. Falls Ihr Server allein eine Domain darstellt, benötigen Sie lediglich einen Schlüssel sowie ein Zertifikat im Keystore. Schlüssel werden im Keystore als Alias gespeichert. Jedes Alias entspricht einem Domainnamen, z. B.
webshare.meinserver.de.

Zertifikate sollen ein Beleg dafür sein, dass eine bestimmte Domain auch die ist, für die sie sich ausgibt. Ob ein Zertifikat beglaubigt ist wird davon bestimmt, wer das Zertifikat signiert hat. Bei nur geringem Sicherheitsbedarf, z. B. innerhalb des Intranets, können Sie Eigenzertifikate (self-signed certificates) verwenden. Eigenzertifikate verschlüsseln den Kommunikationskanal zwischen Client und Server. Der Client muss jedoch die Legitimität der Eigenzertifikate auf demselben Kanal überprüfen. Die gebräuchlichste Reaktion eines Clients auf ein Eigenzertifikat ist die Frage, ob dem Zertifikat zu trauen ist oder ihm gleich stillschweigend zu vertrauen. Leider macht das blinde Vertrauen gegenüber Eigenzertifikaten das System anfällig für so genannte „Man-in-the-middle“-Angriffe.

Der Vorteil der Eigenzertifizierung liegt darin, dass sie gebührenfrei ist, was sich besonders für Testzwecke lohnt. Da „LetsEncrypt“-Zertifikate jedoch ebenfalls kostenlos sind, lohnen sich Eigenzertifikate nicht ¹. Außerdem kann man einem Eigenzertifikat vertrauen, wenn das eigene Zertifikat seriös ist. Wenn also ein Systemadministrator ein Eigenzertifikat erstellt, es persönlich in einem so genannten „Truststore“ des Clients installiert (so dass es ein beglaubigtes Zertifikat darstellt) können Sie sicher sein, dass die SSL-Verbindung nur zwischen dem Client und dem richtigen Server funktioniert.

Für höhere Sicherheitsanforderungen sollten Sie Ihr Zertifikat von einer CA (Certificate Authority = Zertifizierungsstelle) signieren lassen. Normalerweise beinhalten Client-Truststores Zertifikate der größeren CAs und können so prüfen, ob ein Zertifikat von einer CA signiert wurde. Durch diese Sicherheitskette können Clients auch Zertifikaten von Servern, mit denen sie bisher noch nicht verbunden waren, vertrauen. Das Signieren von Zertifikaten gleicht dem Gang zum Notar (Identitätsprüfung, Einträge und Kosten).

7.4.3 Ein vorhandenes Zertifikat importieren

Mit dem Dienstprogramm „wskeytool“ (siehe 7.5 „wskeytool“) lassen sich Zertifikate in den WebShare Webserver importieren:

wskeytool -import -keyfile <private key> -file <public key> -trustcacerts

Beispiel:

wskeytool -import -keyfile
          /etc/letsencrypt/live/example.com/privkey.pem
          -file /etc/letsencrypt/live/example.com/fullchain.pem
          -trustcacerts

Ist der private Schlüssel verschlüsselt, muss die Option -keyfilepass angegeben werden. Sind privater und öffentlicher Schlüssel in einer Datei gespeichert, muss die Option -file weggelassen werden.

Eine umfangreiche Dokumentation sämtlicher Optionen erhalten Sie mit dem folgenden Aufruf:
wskeytool -import -h -v

Den Import überprüfen:
wskeytool -list

Das Zertifikat sollte nun als „PrivateKeyEntry“ aufgeführt sein.

7.4.4 Ein neues Zertifikat von der CA anfordern und importieren

Um SSL auf Ihrem Server konfigurieren zu können, müssen Sie zuerst folgende Schritte abarbeiten:

Legen Sie eine Domain für den HELIOS WebShare Webserver fest
Erstellen Sie ein Schlüsselpaar für das Zertifikat Ihrer Serverdomain
Lassen Sie das SSL-Serverzertifikat von einer CA zertifizieren
a) Erstellen Sie ein CSR (Certificate Signing Request)
b) Schicken Sie Ihr CSR zur Signierung an die CA
Importieren Sie das Serverzertifikat, welches Sie von der CA zurückerhalten haben, in den Keystore

Detaillierte Anwesungen für die oben aufgeführten Schritte:

1. Legen Sie eine Domain für den HELIOS WebShare Webserver fest
Die WebShare Webserver-Domain sollte mit dem Hostnamen des Servers, z. B. „webshare.meinedomain.de“, identisch sein; der WebShare Webserver muss unter diesem Domainnamen erreichbar sein.

2. Erstellen Sie ein Schlüsselpaar für das Zertifikat Ihrer Serverdomain
Nutzen Sie zur Erstellung eines Schlüsselpaars für das Serverzertifikat das HELIOS-Dienstprogramm „wskeytool“ auf dem WebShare Web Server:
# cd /usr/local/helios/bin

Einen Schlüssel erstellen:
wskeytool -genkey -alias <WebShare Web Server domain>

Hinweis:: Wenn für ein vorhandenes Zertifikat die CA gewechselt werden soll, beginnen Sie einfach mit dem folgenden Abschnitt. WebShare arbeitet bis zum -importcert mit dem bisherigen Zertifikat weiter.

3. Lassen Sie das SSL-Serverzertifikat von einer CA zertifizieren
Um ein von der CA signiertes ZErtifikat zu erhalten, müssen Sie das Zertifikat zuerst in das Standard CSR-Format exportieren.

a) Ein CSR erstellen:
wskeytool -certreq -file <CSR_filename>

b) Schicken Sie Ihr CSR zur Signierung an eine CA.

4. Importieren Sie das Serverzertifikat, welches Sie von der CA zurückerhalten haben, in den Keystore
Wenn Sie sich Ihr Serverzertifikat von einer CA haben signieren lassen, müssen Sie es in Ihren vorhandenen Keystore importieren:
wskeytool -importcert -file <signed_certificate_file> -trustcacerts

Wichtig:: Der Keystore muss die vollständige Zertifizierungskette enthalten, von Ihrem Domain-Zertifikat bis zum Root-Zertifikat der CA. Sind die Angaben nicht vollständig, startet der Dienst „websharewoa“ ohne korrekte HTTPS-Unterstützung.

7.4.5 Ein selbstsigniertes Zertifikat erstellen

wskeytool -genkey -alias <Web Server domain>

Hinweis:: Wird von Internetbrowsern nur mit definierter Ausnahmeregel akzeptiert.

7.5 wskeytool

„wskeytool“ ist ein Dienstprogramm zum Verwalten von Schlüsseln und Zertifikaten. Es soll dem Anwender dabei helfen, den für die HTTP/SSL-Unterstützung erforderlichen „HELIOS WebShare Web Server“-Keystore zu verwalten.

Sämtlichen Befehls- und Optionsnamen wird ein Minuszeichen (-) vorangestellt. Die Optionen für einen Befehl können in beliebiger Reihenfolge angegeben werden.

Befehle:

-certreq

Erzeugt einen CSR im PKCS#10-Format. Ein CSR ist dafür vorgesehen, an die CA gesandt zu werden. Die CA bestätigt den Zertifikatsantragsteller (in der Regel offline) und gibt ein Zertifikat oder eine Zertifikatskette zurück, die dazu verwendet wird, die bestehende Zertifikatskette (die anfänglich aus einem selbstsignierten Zertifikat besteht) im Keystore zu ersetzen. Der mit -alias assoziierte private Schlüssel wird zum Erstellen des PKCS#10-Zertifikatantrags verwendet. Wird -dname angegeben, wird es als Betreff des CSR verwendet. Andernfalls wird der mit -alias assoziierte X.500 distinguished name genutzt. Bei Angabe von -ext werden die Alias-Erweiterungen ersetzt. Der CSR wird in der Datei „<file>“ gespeichert. Wird keine Datei angegeben, wird der CSR nach „stdout“ ausgegeben.

Hinweis:: verwenden Sie den Befehl -importcert um die Antwort der CA zu importieren.

Optionen:

-alias <alias>: Alias des zu verarbeitenden Prozesses
-sigalg <alg>: Algorithmus der Signatur
-file <file>: Name der Ausgabedatei
-keypass <arg>: Passwort für den Schlüssel
-dname <name>: Distinguished Name
-ext <name{:critical}{=value}>: X.509-Erweiterung
-keystore <keystore>: Name des Keystores
-storepass <arg>: Passwort für den Keystore
-storetype <type>: Typ des Keystores
-v: Erweiterte Ausgabe
-q: Konsolenausgabe unterdrücken
-h: Hilfe

-changealias

Bestehenden Keystore-Eintrag vom angegebenen -alias in einen neuen Alias, -destalias, verschieben. Wird kein neuer Alias angegeben, fordert der Befehl zur Eingabe eines neuen Alias auf. Wird kein Passwort für den Schlüssel eingegeben, versucht das Programm es zunächst mit dem Keystore-Passwort. Ist dies erfolglos, wird der Anwender aufgefordert, ein Passwort einzugeben.

Optionen:

-alias <alias>: Alias des zu verarbeitenden Prozesses
-destalias <alias>: Neues Alias
-keypass <arg>: Passwort für den Schlüssel
-cacerts: Zugriff auf den CAcert-Keystore
-keystore <keystore>: Name des Keystores
-storepass <arg>: Passwort für den Keystore
-storetype <type>: Typ des Keystores
-v: Erweiterte Ausgabe
-q: Konsolenausgabe unterdrücken
-h: Hilfe

-delete

Entfernt den mit -alias gekennzeichneten Eintrag aus dem Keystore. Der Anwender wird aufgefordert einen Alias einzugeben, sollte es auf der Kommandozeile keinen Alias geben.

Optionen:

-alias <alias>: Alias des zu verarbeitenden Prozesses
-cacerts: Zugriff auf den CAcert-Keystore
-keystore <keystore>: Name des Keystores
-storepass <arg>: Passwort für den Keystore
-storetype <type>: Typ des Keystores
-v: Erweiterte Ausgabe
-q: Konsolenausgabe unterdrücken
-h: Hilfe

-exportcert

Liest das mit -alias assoziierte Zertifikat aus dem Keystore und speichert es in der Datei „<file>“. Standardmäßig (wenn die Option -rfc nicht gesetzt ist), wird das Zertifikat im Binärformat ausgegeben. Wenn -alias auf einen Schlüsseleintrag mit assoziierter Zertifikatskette verweist, wird das erste Zertifikat in der Kette ausgegeben. Dieses Zertifikat bestätigt den öffentlichen Schlüssel der durch -alias ausgewiesenen Einrichtung. Wenn -alias auf ein vertrauenswürdiges Zertifikat verweist, wird dieses ausgegeben.

Optionen:

-rfc: Ausgabe im RFC-Format
-alias <alias>: Alias des zu verarbeitenden Prozesses
-file <file>: Name der Ausgabedatei
-cacerts: Zugriff auf den CAcert-Keystore
-keystore <keystore>: Name des Keystores
-storepass <arg>: Passwort für den Keystore
-storetype <type>: Typ des Keystores
-v: Erweiterte Ausgabe
-q: Konsolenausgabe unterdrücken
-h: Hilfe

-genkeypair

Verpackt den öffentlichen Schlüssel in ein selbstsigniertes X.509-v3-Zertifikat, welches als Einzelelement-Zertifikatskette gespeichert wird. Diese Zertifikatskette sowie der private Schlüssel werden in einem neuen, durch -alias gekennzeichneten Keystore abgelegt.
Der in -dname definierte Wert wird als Aussteller- und Betreff-Feld im selbstsignierten Zertifikat verwendet.

Optionen:

-alias <alias>: Alias des zu verarbeitenden Prozesses
-keyalg <alg>: Name des Schlüsselalgorithmus
-keysize <size>: Bitgröße des Schlüssels
-sigalg <alg>: Name des Signaturalgorithmus
-dname <name>: Distinguished Name
-ext <name{:critical}{=value}>: X.509-Erweiterung
-startdate <date>: Beginn der Gültigkeit des Zertifikats (Datum/Uhrzeit)
-validity <days>: Gültigkeitsdauer in Tagen
-keypass <arg>: Passwort für den Schlüssel
-keystore <keystore>: Name des Keystores
-storepass <arg>: Passwort für den Keystore
-storetype <type>: Typ des Keystores
-v: Erweiterte Ausgabe
-q: Konsolenausgabe unterdrücken
-h: Hilfe

-import

Liest den privaten Schlüssel aus einer PKCS#1-, PKCS#5-, PKCS#8-, oder PKCS#12-formatierten Datei sowie das Zertifikat oder die Zertifikatskette (wenn diese in einer PKCS#7-formatierten Antwort oder einer Sequenz aus X.509-Zertifikaten vorliegt) aus einer zweiten Datei und legt diese in einem durch -alias gekennzeichneten Keystore ab. Sind weder -keyfile noch -file angegeben, werden Zertikat und privater Schlüssel von „stdin“ gelesen. Die zu importierenden Daten müssen, gemäß dem Internet RFC#1421 Standard, entweder im Binärformat (DER) oder in einem druckbaren Format (PEM, auch als Base64 bekannt) vorliegen.
Der Alias ist standardmäßig auf den ersten in der HELIOS Präferenz WOHost gefundenen Hostnamen voreingestellt. Kann diese diese Präferenz nicht gefunden werden, wird der Standard-Alias aus dem ersten „DNS“-SubjectAlternativeName oder dem aus dem Zertifikat extrahierten X.500 distinguished name „CN“ gebildet.

Optionen:

-noprompt: Ohne Nachfrage
-trustcacerts: Zertifikaten von CAcert vertrauen
-alias <alias>: Alias des zu verarbeitenden Prozesses
-keyfile <file>: Dateiname des privaten Schlüssels
-keyfilepass <arg>: Passwort für den Quellschlüssel
-keyalg <alg>: Name des Schlüsselalgorithmus
-file <file>: Name der Eingangsdatei
-keystore <keystore>: Name des Keystores
-storepass <arg>: Passwort für den Keystore
-storetype <type>: Typ des Keystores
-v: Erweiterte Ausgabe
-q: Konsolenausgabe unterdrücken
-h: Hilfe

-importcert

Liest ein Zertifikat oder eine Zertifikatskette (wenn diese in einer PKCS#7-formatierten Antwort oder einer Sequenz aus X.509-Zertifikaten vorliegt) aus -file und legt diese in einem durch -alias gekennzeichneten Keystore ab. Ist keine Datei angegeben, werden Zertikat und privater Schlüssel von „stdin“ gelesen.
„wskeytool“ kann X.509-v1, -v2 und -v3-Zertifikate importieren sowie PKCS#7-formatierte Zertifikatsketten, die aus Zertifikaten dieses Typs bestehen. Die zu importierenden Daten müssen, gemäß dem Internet RFC#1421 Standard, entweder im Binärformat oder in einem druckbaren Format (auch als Base64 bekannt) vorliegen. Bei letzterem muss die Kodierung am Anfang durch eine Zeichenkette, die mit -----BEGIN beginnt und am Ende durch eine Zeichenkette, welche mit -----END beginnt, begrenzt sein.

Es gibt zwei Gründe für den Import eines Zertifikats: um es der Liste vertrauenswürdiger Zertifikate hinzuzufügen oder um eine Zertifikatsantwort von der CA – als Ergebnis der Einreichung eines CSR bei dieser CA – zu importieren (siehe Befehl -certreq). Um welchen der beiden Fälle es sich handelt, wird durch den Wert der Option -alias bestimmt.
Verweist der Alias nicht auf einen Schlüsseleintrag, nimmt „wskeytool“ an, dass Sie ein vertrauenswürdiges Zertifikat hinzufügen. In diesem Fall sollte der Alias nicht bereits im Keystore existieren. Ist dies dennoch der Fall, gibt „wskeytool“ einen Fehler aus, da es bereits ein vertrauenswürdiges Zertifikat für diesen Alias gibt. Das Zertifikat wird dann nicht importiert.
Verweist der Alias auf einen privaten Schlüssel (oder es existiert bei exakt einem privaten Schlüssel im Keystore kein Alias), nimmt „wskeytool“ an, dass Sie eine Zertifikatsantwort importieren. Der öffentliche Schlüssel des Zertifikats muss mit dem privaten Schlüssel übereinstimmen.

Optionen:

-noprompt: Ohne Nachfrage
-trustcacerts: Zertifikaten von CAcert vertrauen
-alias <alias>: Alias des zu verarbeitenden Prozesses
-file <file>: Name der Eingabedatei
-keypass <arg>: Passwort für den Schlüssel
-cacerts: Zugriff auf den CAcert-Keystore
-keystore <keystore>: Name des Keystores
-storepass <arg>: Passwort für den Keystore
-storetype <type>: Typ des Keystores
-v: Erweiterte Ausgabe
-q: Konsolenausgabe unterdrücken
-h: Hilfe

-importkeystore

Importiert einen oder alle Einträge aus einem anderen Keystore. (für den Import aus PKCS#12 beachten Sie bitte die Unterschiede zum Befehl -import, der ebenfalls einen Eintrag aus PKCS#12 importieren kann, aber mit einer abweichenden Handhabung der Vorgaben).

Ohne Angabe der Option -srcalias werden sämtliche Einträge im Quell-Keystore in den Ziel-Keystore importiert. Wird der Typ eines Quell-Keystores im Ziel-Keystore nicht unterstützt, oder wenn während des Speicherns eines Eintrags im Ziel-Keystore ein Fehler auftritt, kann der Anwender entscheiden, ob er den Eintrag überspringen und fortfahren oder den Vorgang abbrechen möchte.
Falls der Ziel-Alias im Ziel-Keystore bereits existiert, kann der Anwender den Eintrag entweder überschreiben oder einen neuen Eintrag unter einem anderen Alias-Namen anlegen.
Mit der Option -noprompt wird der Anwender nicht nach einem neuen Ziel-Alias gefragt. Bestehende Einträge werden dann mit dem Namen des Ziel-Alias überschrieben. Einträge, die sich nicht importieren lassen, werden übersprungen und eine Warnung wird ausgegeben.
Die Optionen -destalias und -srckeypass können nur bei gleichzeitiger Angabe der Option -srcalias gesetzt werden.

Optionen:

-srckeystore <keystore>: Name des Quell-Keystores
-destkeystore <keystore>: Name des Ziel-Keystores
-srcstoretype <type>: Typ des Quell-Keystores
-deststoretype <type>: Typ des Ziel-Keystores
-srcstorepass <arg>: Passwort für den Quell-Keystore
-deststorepass <arg>: Passwort für den Ziel-Keystore
-srcalias <alias>: Quell-Alias
-destalias <alias>: Ziel-Alias
-srckeypass <arg>: Passwort für den Quell-Schlüssel
-destkeypass <arg>: Passwort für den Ziel-Schlüssel
-noprompt: Ohne Nachfrage
-v: Erweiterte Ausgabe
-q: Konsolenausgabe unterdrücken
-h: Hilfe

-keyclone

Bestehenden Keystore-Eintrag vom angegebenen -alias in den neuen -destalias kopieren. Ist kein Ziel-Alias angegeben, fordert der Befehl zur Eingabe eines neuen Alias auf. Wenn der Originaleintrag passwortgeschützt ist, kann dies mit der Option -keypass angegeben werden. Wird kein Passwort für den Schlüssel eingegeben, versucht das Programm es zunächst mit -storepass. Ist dies erfolglos, wird der Anwender aufgefordert, ein Passwort einzugeben.

Ist der WebShare Webserver über mehrere Hostnamen verbunden, lässt sich mit dem Befehl -keyclone ein Schlüsseleintrag in den Alias für einen anderen Hostnamen kopieren. Das Zertifikat muss diesen Namen als Wildcard oder mit einer X.509-Zertifikatserweiterung („SubjectAlternativeName“) unterstützen.

Optionen:

-alias <alias>: Alias des zu verarbeitenden Prozesses
-destalias <alias>: Ziel-Alias
-keypass <arg>: Passwort für den Schlüssel
-keystore <keystore>: Name des Keystores
-storepass <arg>: Passwort für den Keystore
-storetype <type>: Typ des Keystores
-v: Erweiterte Ausgabe
-q: Konsolenausgabe unterdrücken
-h: Hilfe

-list

Gibt die mit -alias gekennzeichneten Inhalte des Keystores nach „stdout“ aus. Ist kein Alias angegeben, werden sämtliche Inhalte des Keystores ausgegeben.
Standardmäßig gibt dieser Befehl den „Common Name“ (CN) und den SHA1-Fingerabdruck eines Zertifikats aus. Ist die Option -v gesetzt, wird das Zertifikat in einem direkt lesbaren Format, mit Zusatzinformationen wie Eigentümer, Aussteller, Seriennummer und mögliche Erweiterungen, ausgegeben. -v und -rfc können nicht zusammen angegeben werden.

Beim Abrufen von Informationen aus dem Keystore ist das Passwort optional. Wenn kein Passwort angegeben wird, kann die Integrität der abgerufenen Informationen nicht überprüft werden und eine Warnung wird ausgegeben.

Optionen:

-rfc: Ausgabe im RFC-Format
-alias <alias>: Alias des zu verarbeitenden Prozesses
-cacerts: Zugriff auf den CAcert-Keystore
-keystore <keystore>: Name des Keystores
-storepass <arg>: Passwort für den Keystore
-storetype <type>: Typ des Keystores
-v: Erweiterte Ausgabe
-h: Hilfe

-printcert

Liest das Zertifikat aus -file, dem SSL-Server (-sslserver) oder der signierten JAR-Datei (-JAR_file) und gibt die Inhalte in einem direkt lesbaren Format aus. Beachten Sie, dass die Optionen -jarfile, -sslserver sowie -file nicht gleichzeitig angegeben werden können. Ist keine der Optionen gesetzt, wird das Zertifikat von „stdin“ gelesen.
Wenn das Zertifikat aus einer Datei oder „stdin“ gelesen wird, kann es, gemäß dem Standard RFC 1421 Certificate Encoding, entweder binär kodiert oder im druckbaren Kodierungsformat vorliegen.

Hinweis:: Dieser Befehl lässt sich unabhängig von einem Keystore verwenden.

Optionen:

-rfc: Ausgabe im RFC-Format
-file <file>: Name der Eingabedatei
-sslserver <server[:port]>: SSL-Server mit Portangabe
-jarfile <JAR_file>: Signierte JAR-Datei
-help: Hilfe

-printcertreq

Gibt den Inhalt einer Zertifikatsanforderung, die mit dem Befehl -certreq erzeugt werden kann, im Format PKCS#10 aus. Der Befehl liest die Anforderung von -file. Ist keine Datei vorhanden, wird die Anforderung von „stdin“ gelesen.

Hinweis:: Dieser Befehl lässt sich unabhängig von einem Keystore verwenden.

Optionen:

-file <file>: Name der Eingabedatei
-v: Erweiterte Ausgabe
-help: Hilfe

-printcrl

Liest die „Certificate Revocation List“ (CRL) aus -file. Eine CRL ist eine Liste digitaler Zertifikate, welche von der CA, die sie ausgestellt hat, widerrufen wurden. Die Datei wird von der CA erstellt.

Optionen:

-file <file>: Name der Eingabedatei
-v: Erweiterte Ausgabe
-help: Hilfe

-storepasswd

Ändert das verwendete Passwort um die Integrität der Keystore-Inhalte zu schützen.
Existiert bereits eine Passwort-Datei für den Keystore, muss der Anwender dafür schreibberechtigt sein. Der Schutz für Schlüsseleinträge, die mit dem Keystore-Passwort (Standard, wie WebShare-Webserver-Zertifikate) geschützt sind, ändert sich mit dem neuen Passwort.

Optionen:

-new <arg>: Neues Passwort
-cacerts: Zugriff auf den CAcert-Keystore
-keystore <keystore>: Name des Keystores
-storepass <arg>: Passwort für den Keystore
-storetype <type>: Typ des Keystores
-v: Erweiterte Ausgabe
-h: Hilfe

Mit der Option -v erhält man eine erweiterte, umfangreichere Ausgabe. Die Option lässt sich auch in Verbindung mit -help nutzen.

7.5.1 Fertigstellung

: Starten Sie den WebShare Webserver neu.

# srvutil stop websharewoa 
# srvutil start websharewoa

Das Einrichten der sicheren Serververbindung (SSL) ist nun abgeschlossen. WebShare kann jetzt sowohl über HTTP als auch über HTTPS erreicht werden.

Hinweis:: Um ausschließlichen Zugriff über HTTPS und nicht über HTTP zu erlauben, muss die Präferenz WOPort auf 0 gesetzt werden (siehe Kapitel 7.6 „Präferenzen“).

7.5.2 Fragen & Antworten

Wie sieht ein „Certificate Request“ aus?

-----BEGIN NEW CERTIFICATE REQUEST----- 
MIIBxzCCATACAQAwgYYxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdHZXJt 
YW55MRAwDgYDVQQHEwdHYXJic2VuMR0wGwYDVQQKExRIRUxJT1MgU29m 
dHdhcmUgR21iSDEXMBUGA1UECxMOSEVMSU9TIFN1... 
-----END NEW CERTIFICATE REQUEST-----

Gewöhnlich muss dies mit den Zeilen „-----BEGIN...“ und „-----END...“ Ihrer CA (Certificate Authority, z. B. verisign.com) übermittelt werden.

Warum sagt mir mein Browser, dass das Zertifikat ungültig ist?

Dafür gibt es mehrere Möglichkeiten:

Die URL Ihrer Serverdomain stimmt nicht mit der im Zertifikat überein
Ihr Zertifikat wurde nicht von einer CA signiert
Ihr Zertifikat ist abgelaufen
Der von Ihnen verwendete Browser kennt die CA nicht, VeriSign ist beispielsweise bei führenden Browsern installiert

Nach unserer Erfahrung bieten Mozilla basierte Browser mehr Detailinformationen über Zertifikate als andere. Sollte ein Problem auftauchen, können diese Browser benutzt werden um zu sehen, wie die Antwort des CA-Zertifikats aussehen würde.

7.5.3 Bekannte Probleme

Problem:

Für den Fall, dass der „websharewoa“ während des Neustarts folgende Fehlermeldung ausgibt:

websharewoa: [2009-11-28 15:54:30 MEST] <main> Unable to 
establish an SSL connection to port 443 on this host

und sich dann beendet, stellen Sie sicher, dass der SSL Port nicht von einer anderen Anwendung benutzt wird. Beispielsweise sollte:

# netstat -an | grep 443

nicht die folgende Zeile ausgeben:

*.443 *.* 0 0 24576 0 LISTEN

Prüfen Sie auch die folgende Meldung:

websharewoa: [2009-11-28 15:54:30 MEST] <main> com.webob- 
jects.foundation.NSForwardException for com.webob- 
jects.foundation.NSForwardException for 
java.security.NoSuchAlgorithmException: Algorithm 
SunX509 not available "Algorithm SunX509 not available"

Diese zeigt an, dass die verwendete JVM SSL nicht unterstützt. Versuchen Sie diese JVM zu aktualisieren oder installieren Sie die Oracle JVM.

Problem:: Microsofts Internet Explorer 6 kann für eine sichere „websharewoa“-Verbindung (über HTTPS) ausschließlich Port 443 verwenden.

7.6 Präferenzen

Hinweis:: Dieses Kapitel wurde nicht übersetzt, um die Eindeutigkeit der Beschreibung zu bewahren.

This section lists all the preference keys that are pertinent to the WebShare Webserver. Find a description of how to set, view, change or delete preferences, with the HELIOS “prefdump”, “prefvalue”, and “prefrestore” utility programs in “HELIOS utility programs” in the HELIOS Base manual.

Wichtig:: Make sure that preference keys DO NOT start or end with a slash (“/”) character, and note that they are case-sensitive! Also, if any preference key or preference value includes spaces, that key or value must be enclosed in quotes.

The following keys require a restart (see “srvutil” in the HELIOS Base manual) of the service to take effect:

: Key: Programs/websharewoa/<preference>

WOPort

int

2009

Specifies the WebShare Webserver port number for HTTP access. If set to “0” (without quotes) any HTTP connection to the WebShare Webserver is denied, only HTTPS/SSL connections are accepted. In that case, make sure the preference SSLPort is set, otherwise no connection to the WebShare Webserver can be established.

Hinweis:: If you wish to use HTTP port 80, and Apache or another web server is also running on the WebShare Webserver, see 10.1.11 „WebShare Webserver für Port 80 konfigurieren“ for configuration details.

MDNSPort

int

2006

Specifies the port number of the mDNS proxy server that is used for mDNS (“Bonjour”) branding registrations. If more than one WebShare Webserver is used, all used ports must have the same number.

Wichtig:: The value of this preference needs to be identical with the mDNS proxy server TelnetPort preference (see HELIOS Base manual). If there should be the need to change a value, then make sure that both preference keys are assigned the same value!

SSLPort

int

443

Specifies the WebShare Webserver port number for HTTPS/SSL connections to the browser.

WOHost

str

(see description)

Specifies the host name or IP address of the WebShare Web Server. This is useful on machines with multiple IP addresses/host names. If this preference is not set, the WebShare Web Server can be reached via any IP address/host name on the machine. The preference can also be set to a comma-separated list of IP addresses/host names. In addition, this preference allows specifying a port or SSL port, meaning that, if a port or SSL port is specified, the default settings (given by WOPort and SSLPort) are overridden.

Example 1:

(WOHost="myDomain:2035:2036"; WOPort="2009"; SSLPort="443";)

For “myDomain”, the default settings 2009 and 443 are overridden.

Access to the application:
http://myDomain:2035
and via SSL:
https://myDomain:2036

Example 2:

(WOHost="myDomain::2036"; WOPort="2009"; SSLPort="443";)

For “myDomain”, no individual port is specified so the standard settings apply.

Access to the application:
http://myDomain:2009
and via SSL:
https://myDomain:2036

Example 3:

(WOHost="myDomain:0:2036"; WOPort="2009"; SSLPort="443";)

Specifying the port “0” for “myDomain” means that there are no standard (i.e. unencrypted and therefore insecure) connections available.

Access via SSL only:
https://myDomain:2036

WSRedirectToSSL

bool

FALSE

If set to TRUE, this preference induces the server to redirect the request to a secure Internet connection, for example:

http://webshare.helios.de:2009 => https://webshare.helios.de:2012

Hinweis:: It is required that an SSL port be specified via the SSLPort or WOHost preference.

WSDenyAccessForUA

strlist

"+http"

This preference contains a string list to specify user agents which should not be serviced. This is helpful to disable web crawlers that do not honor the “robots.txt”² file, e.g.:

prefvalue -k 'Programs/websharewoa/WSDenyAccessForUA' -t strlist
              "+http://baidu.com,+http://webcrawlerXYZ.com"

Requests with a user agent string containing a string of this preference receive a status 404 (“not found”) response.

Wichtig:: A faulty entry, e.g. a string that is included in many user agents, can block access completely!

WSPublicHost

str

This preference determines which host name is used by default when multiple network interfaces are active on the Webshare Web Server. Setting a public host name may also become necessary if the internal WebShare Web Server host name is different from that when used from external, e.g. via port mapping in a router/firewall, or via a proxy server. This setting is mainly used for Quickshare generated URLs. Two different settings are supported:

Qualified host name:: (e.g.: "webshare.yourdomain.com"); This specifies the host name for public access when multiple network interfaces are valid. The port and SSL configuration will be used from the matching WOHost configuration with the WSPublicHost host name specified.

URLs:

(e.g.: "https://webshare.yourdomain.com:80")

Specifies the protocol, e.g. http or https, the host name and, optionally, a port for generated public URLs. In this case, it must be ensured that public host connections are forwarded to the WebShare Web Server, e.g.:

<external host name>:80 => <internal host name>:2009.

WSDisabledSSLProtocols

strlist

"SSLv3,SSLv2Hello"

By default, this preference is not set which means that SSLv3 and SSLv2Hello are disabled. This configuration is advised by Oracle for all server applications supporting HTTPS.

The list of supported HTTPS protocols depends on the Java version.

Protocols supported by Java 7:
SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2

If this preference is set, all protocols that should be disabled must be specified. Example configuration to allow TLSv1.2 and newer only:

prefvalue -k 'Programs/websharewoa/WSDisabledSSLProtocols' -t
              strlist "SSLv2Hello,SSLv3,TLSv1,TLSv1.1"

Hinweis:: Use this preference with care. Disabling additional protocols may cause incompatibilities with older web browsers using HTTPS.

WSHostName

strlist

localhost,*

Specifies the WebShare File Server default host name prompt for the login dialog. It corresponds to the WebShare File Server entry in the WebShare login page. This preference can also be set to a comma-separated list of IP addresses or host names. In this case a pop-up menu to choose a WebShare File Server will be available at the login dialog.

Also aliases for IP addresses/host names can be defined:

prefvalue -k 'Programs/websharewoa/WSHostName' -t str 
"localhost,Server 1=fileserver,Server 2=172.16.2.222"

In this case, a pop-up menu will be available to choose a WebShare File Server showing the strings “localhost”, “Server 1” and “Server 2”.

It is also possible to specify a port number with the host name, e.g.

prefvalue -k 'Programs/websharewoa/WSHostName' -t str
"localhost:2010,Server 1=fileserver,Server 2=172.16.2.222:2010"

However, specifying a port number requires that this port has also been set, together with the host name, in the WSAllowedHostNames preference, provided that WSAllowedHostNames was specified. If not, the connection is refused and an error message is issued.

If an “*” is found as a host name in the WSHostName preference the user is allowed to enter a file server name manually, in addition to choosing a file server from the pop-up menu:

prefvalue -k Programs/websharewoa/WSHostName -t str
"localhost:2010,Server 1=fileserver,Server 2=172.16.2.222,*"

However, if more than one host name or/and host alias are defined together with an “*”, JavaScript needs to be activated in the client application to get a pop-up menu displayed – otherwise a plain text field, showing the first defined hostname, is displayed.

If only one host name or alias is defined, the user can neither choose nor enter a file server name.

The following examples give an overview of the possible cases:

Preference value: "*"
Display on login page: an empty text field.

Preference value: "localhost:2010"
Display on login page: the string "localhost:2010".

Preference value: "Server 1=localhost"
Display on login page: the string “Server 1”.

Preference value: "localhost,*" (default)
Display on login page: a text field with the value “localhost”.

Preference value: "Server 1=localhost,*"
Display on login page: a text field with the value “Server 1”.

Preference value: "Server 1=localhost,otherhost"
Display on login page: a pop-up menu with the values “Server 1” and “otherhost”.

Preference value: "Server 1=localhost,otherhost,*"
Display on login page: a pop-up menu with the values “Server 1” and “otherhost”, and in addition the ability to enter a file server name manually.

Hinweis:: If a list of file servers without an “*” is defined in the “WSHostName” preference, only file server names or file server aliases defined in this preference are accepted. However, if only one file server name or alias is defined – or an “*” is found as a host name – the file server name defined by the “wshost” parameter (see wshost) is used.

WSAllowedHostNames

str

(see description)

List of WebShare File Server host names or IP addresses which are allowed to be used on the WebShare Webserver. The string must be comma-separated if more than one “allowed” host name or IP address is specified. If not set, all host names are allowed.

WSHostPort

int

2010

Specifies the WebShare File Server port number. If more than one WebShare File Server is used, they all have to use the same port.

Hinweis:: The value of this preference needs to be identical with the WebShare File Server preference TcpPort (8.5 „Präferenzen“). If there should be the need to change a value, then make sure that both preference keys are assigned the same value!

WSUploadChunkSize

int64

1024

This preference specifies the chunk size for drag & drop uploads in MB for uploads that exceed the 4 GB limit. Split uploads become necessary because of web browser and proxy server limits.

WSDisableHTML5Upload

bool

FALSE

If this preference is set to TRUE, the drag & drop upload functionality is switched off completely. Instead the standard upload form and window will be used.

WSEventDisplayPassword

str

This preference allows specifying a password for a protected HTML page, which allows monitoring the WebShare Webserver and the events it is processing. By default, the page is unavailable until a password is set. For security reasons, this preference should not be used unless you are an WebObjects deployment specialist and you know how the WebShare Webserver and WebObjects work internally.

WSUpDownloadTimeOut

int

86400

The default time-out value for uploads and downloads of the WebShare Webserver is 24 h (=86400 s). If more time is needed, e.g. due to a slow Internet connection, this preference may be set to a higher value.

WOSessionTimeOut

int

3600

Specifies that, after a user has been idle for a time, i.e. no web activity has occurred, the session will automatically be closed after one hour (=3600 s).

WSGZIPResponse

bool

TRUE

Modern browsers, e.g. Safari, Firefox, Internet Explorer support “gzip” compressed HTML pages. If supported by the browser, the WebShare Webserver generates “gzip” compressed HTML pages. For slow connections, e.g. via modem or ISDN lines this will increase the browsing performance by a factor of 2-5, depending on the content. In case of problems with compressed pages this feature can be turned off by setting this preference to FALSE.

WSPrintJavaExceptions

bool

FALSE

If this preference is set to TRUE, and an error occurs, a stack trace (debugging information) is printed on the error page.

JavaOptions

strlist

The values of this preference are passed through to the Java command when starting the “websharewoa” service. If specified, behavior, performance or debugging options can be set.

Hinweis:: Use this preference with caution! Providing invalid arguments will preclude “websharewoa” from starting! Providing wrong argument values can cause considerable performance issues.

7.6.1 WOStarter preference keys

WatchdogInterval: int
600; Specifies the interval in seconds in which the watchdog process checks the WebShare Webserver (“websharewoa”) for plausibility of its output to the web browser.
ResponsePositive: strlist
""; Specifies a list of strings that are mandatory in the WebShare Webserver response to the web browser if the behavior is normal. If just one of these strings is missing, the “websharewoa” service is restarted. An example for a mandatory string is: “<!DOCTYPE html PUBLIC”.
ResponseNegative: strlist
""; Specifies a list of strings that must not be contained in the WebShare Webserver response to the web browser. If just one of these strings is included, the “websharewoa” service is restarted.

¹ LetsEncrypt erfordert Root-Zugriff auf den Rechner, auf welchem der WebShare Webserver installiert ist!
² “robots.txt” in the domain root allows defining the behavior of search robots on a website.

HELIOS Handbücher 29. September 2020