Ermöglicht grundlegende Verbindungseinstellungen für den internen Webserver, wie HTTP und HTTPS Verbindungen.

Der interne Webserver ermöglicht das Konfigurieren von HTTP und HTTPS Verbindungen. Zu Testzwecken von gesicherten HTTPS Verbindungen, kann ein selbst signiertes Zertifikat vom Server erstellt werden, bevor welche von einem Anbieter erworben werden.

Es kann gewählt werden, welche Verbindungen der Server beim Starten erzeugt und zugreifbar macht. HTTP-Verbindungen sind der Standard und für die häufigsten Szenarien ausreichend. HTTPS hingegen überträgt alle Daten verschlüsselt. Es können beide Verbindungen gleichzeitig genutzt werden.

• Standardwert: HTTP

In der Standardkonfiguration ist der Server auf allen verfügbaren IP-Adressen ansprechbar. Sobald man die Verfügbarkeit auf eine spezielle IP-Adresse oder Hostnamen beschränken möchten kann man diese Wert entsprechend angeben. Nach dem Neustart ist der interne Webserver nur noch über die angegebene IP-Adresse bzw. Hostnamen erreichbar.

Mit der Context-Option wird der i-net CoWork-Server unter dem angegebenen Pfad ausgeführt. Sie ermöglicht es, den Server neben anderen Anwendungen mit der gleichen Server-URL laufen zu lassen - ähnlich wie bei Anwendungsservern.

Hinweis: Der angegebene Context muss mit einem / beginnen und darf nicht mit einem / enden.

Hinweis: Mit dem Einstellen eines anderen Context wird der Abruf von Let's Encrypt-Zertifikaten deaktiviert, da Let's Encrypt die Challenge-Antwort im Verzeichnis /.well-known/acme-challenge, vom Stammverzeichnis des Servers aus gesehen, aufruft.

Die Serveranwendung lauscht auf dem angegebenen Port auf neue Berichtsanfragen.

Die Serveranwendung lauscht für verschlüsselte Anfragen auf dem angegebenen Port auf neue Berichtsanfragen.

Alle unverschlüsselten Anfragen auf dem Standard HTTP Port werden auf HTTPS weitergeleitet.

Die hier eingestellt Adresse wird im System verwendet um Verlinkungen, zum Beispiel in E-Mails, korrekt zu erzeugen. Sie wird für den Standardwert aus dem Hostnamen erzeugt. Diese Eigenschaft ändert nicht die URL, auf der der Server zur Verfügung steht.

Die externe sichtbare URL muss verwendet werden, wenn sich der i-net CoWork-Server hinter einem Reverse Proxy befindet.

Hinweis: In einer Cloud-basierten Umgebung wird hier die Adresse des Proxy-Server eingetragen.

Hinweis: Die URL kann für die Lizenzierung relevant sein und sollte daher auf den korrekten Wert für den Zugriff auf den Server eingestellt werden - die Startseite des Servers sollte darüber erreichbar sein. Hier sind sowohl die Angabe des Protokolls, FQDN, Port und Application Server Kontext erlaubt.

Es gibt mehrere Möglichkeiten, den Server mit einem SSL-Zertifikat zu versorgen, das für sichere HTTP-Verbindungen verwendet werden kann:

• Eigenes Zertifikat hochladen
• Eigenes Zertifikat vom Server bereitstellen
• Let's Encrypt

Anhand des Domänen (FQDN) kann geprüft werden, für welchen Server die Zertifikate ausgestellt wurden.

Ein benutzerdefiniertes Zertifikat muss per Drag&Drop oder über die Dateiauswahl des Browsers hochgeladen werden. Normalerweise können Sie eines von einem Anbieter wie Thawte oder VeriSign erwerben. Zu Testzwecken kann auch ein selbst signiertes HTTPS-Zertifikat erstellt werden.

Zusätzlich zum Zertifikat wird der entsprechende private Schlüssel benötigt, um die verschlüsselten Anfragen zu lesen. Auch diesen Schlüssel erhalten Sie von Ihrem SSL-Zertifikatsanbieter. Oft handelt es sich um eine Datei mit der Erweiterung .key oder um einen Teil der Datei .pem.

Private Schlüssel können im PKCS8-, X509- oder PEM-Format gespeichert werden.

Hinweis: Einige Browser und Anwendungen benötigen alle Zwischenzertifikate der Kette. Die Zertifikate müssen ebenfalls in der Zertifikatsdatei gespeichert werden. Beim PEM Format (Base64) kann man dies mit einem Texteditor machen.

Hinweis: Für den privaten Schlüssel darf kein Passwort gesetzt sein.

Hinweis: Sie können neue Zertifikate auch über die entsprechende Web-API

Ein benutzerdefiniertes Zertifikat muss vom Benutzer als Dateien auf dem Server bereitgestellt werden. Sie müssen die Dateien über eine Dateiauswahl oder durch Eingabe der Dateipfade auswählen. Es gelten die gleichen Regeln wie beim Hochladen eines benutzerdefinierten Zertifikats.

Auch hier können Sie ein selbst signiertes Zertifikat erstellen und dessen Speicherort auf dem Server angeben.

Let's Encrypt ist ein externer Dienst, der es ermöglicht, Server-URL-spezifische SSL-Zertifikate zu erzeugen. Ein Zertifikat kann nur angefordert werden, wenn der Server auf den Standardports 80 und 443 läuft, ansonsten kann Let's Encrypt die Installation der neuen Zertifikate nicht überprüfen.

Einstellungen, welche die Anzahl gleichzeitiger Anfragen begrenzen, um den internen Webserver zu beschleunigen.

Dieser Wert gibt die maximale Länge der Queue für ankommende Socket-Verbindungen an (z.B. Verbindungsanfragen). Ist der Maximumwert erreicht, wird jede weitere Verbindung abgewiesen.

• Standardwert: 500

Dies ist die Anzahl der gleichzeitigen HTTP-Anfragen, die vom Server angenommen und bearbeitet werden. Weitere Anfragen werden eingereiht.

• Standardwert: 250

Maximaler Heap Speicher für den Server Prozess. Der Standardwert beträgt 1/4 des installierten Arbeitsspeichers (bei 32 Bit Betriebssystemen liegt er bei 256 MB). Der angegebene Wert sollte nicht größer sein als der freie Arbeitsspeicher, da die Nutzung der Auslagerungsdatei die Performance stark reduziert.

Die Sprache des Servers wird für die Ausgabe von Fehlermeldungen verwendet. Diese Eigenschaft entspricht dem Java VM Parameter: -Duser.language.

• Standardwert: Systemeinstellung des Betriebssystems

Das Land des Servers wird für die Währungsformatierung verwendet. Diese Eigenschaft entspricht dem Java VM Parameter: -Duser.country.

• Standardwert: Systemeinstellung des Betriebssystems

Dies wird direkt an die Java VM als Argument weitergeleitet.

• Standardwert: leer
• Beispiel: -javaagent:c:\path\to\your\javaagent.jar

Wenn es erforderlich sein sollte, kann man den Server hier neu starten. Beachten Sie dabei bitte, dass ungespeicherte Änderungen verloren gehen. Unter Umständen kann sich der Konfigurationsmanager anschließend nicht erneut mit dem Server verbinden. Das kann beispielsweise auftreten, wenn der Port des internen Webservers oder die Zugriffsrechte des aktuellen Benutzers geändert wurden.

Einige Sicherheitseinstellungen

Ändert das Attribut SameSite des HTTP-Antwort-Headers Set-Cookie. Weitere Informationen zum SameSite-Cookie finden Sie hier: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite

Hinweis: Die Verwendung des Wertes None erfordert, dass der Browser über eine HTTPS-Verbindung auf den i-net CoWork-Server zugreift. Die Anmeldung über HTTP ist nicht mehr möglich. Wenn aufgrund einer Fehlkonfiguration des HTTPS-Zugriffs eine Anmeldung nicht mehr möglich ist, müssen Sie den Recovery Manager starten, um das Problem zu beheben.

Note: Bei der Verwendung eines OAuth-Authentifizierungsanbieters, muss entweder Lax verwendet oder die OAuth-URL des Anbieters zu den Erlaubte Cross Origins hinzugefügt werden.

Mit dieser Konfigurationseigenschaft können Frame-Einbettungen unter Verwendung des Header-Feldes X-Frame-Options eingerichtet werden. Die unterstützten Werte sind:

• Immer erlaubt: Der Header ist nicht gesetzt
• Verweigern: Der Header ist auf DENY gesetzt und die Frame-Einbettung der Anwendungen ist nicht erlaubt
• Gleicher Ursprung: Der Header ist auf SAMEORIGIN gesetzt und erlaubt die Einbettung der Anwendung nur von derselben Ursprungsadresse.

Aktiviert die Cross-Origin Resource Sharing (CORS) Prüfungen. Ist ein Wert in diesem Feld eingegeben (siehe unten), dann wird der Access-Control-Allow-Origin-Header an den Browser gesendet und enthält die folgenden Werte:

1. die Werte aus diesem Feld und
2. die externe sichtbare URL

Der Header-Eintrag stellt sicher, dass sich der Browser an die CORS-Regeln hält. Zusätzlich prüft der Server auch, ob er mit einem der angegebenen Werte angesprochen wird. Das bedeutet, dass Sie die Web-Oberfläche des Servers nicht mit anderen Adressen ansprechen können, als mit der öffentlich sichtbaren URL oder einem der Werte im Feld Erlaubte Origins.

*

oder

https://foo.example.com, http://bar.example:9000

oder

*.example.com

Mit dieser Option wird der Inhalt der Datei crossdomain.xml dieses Servers angepasst. Die Datei crossdomain.xml regelt, wie andere Domänen und Quellen mit den Webinhalten des Benutzers interagieren können. Sie können in der Datei crossdomain.xml Regeln und Berechtigungen definieren, um festzulegen, welche externen Domänen auf Daten oder Ressourcen auf diesem Server zugreifen dürfen. Diese Anpassung gewährleistet kontrollierte und sichere domänenübergreifende Interaktionen, schützt sensible Informationen und verbessert die allgemeine Sicherheitslage dieses Servers.

Die Option robots.txt ermöglicht die Anpassung des Inhalts der entsprechenden Datei im Stammverzeichnis dieses Servers. Die Datei robots.txt weist Suchmaschinen-Bots und andere automatisierte Tools an, welche Teile der Website zu crawlen und welche zu vermeiden sind. Sie können Regeln mit Direktiven wie "User-agent", "Disallow" und "Allow" festlegen, um die Indizierung und Sichtbarkeit des Inhalts Ihrer Website in den Suchergebnissen zu steuern. Diese Anpassung hilft dabei, die Interaktion von Bots mit der Website zu steuern und den Datenschutz zu wahren.

Mit der Konfiguration security.txt können Sie den Inhalt der Datei /.well-known/security.txt dieses Servers festlegen. Die Datei security.txt dient als standardisierte Methode für Organisationen, ihre Sicherheitskontaktinformationen und Richtlinien zur Offenlegung von Schwachstellen zu kommunizieren. Mit dieser Konfiguration können Sie angeben, wie sicherheitsbezogene Angelegenheiten gemeldet und behandelt werden sollen, einschließlich der Kontaktdaten und bevorzugten Kommunikationskanäle. Durch die Anpassung des Inhalts der Datei security.txt können Sie den Meldeprozess für Sicherheitsforscher und ethische Hacker rationalisieren und so eine sicherere Online-Umgebung fördern.

Es gibt jeweils eine Sektion für zusätzliche HTTP sowie HTTPS Header Felder. Einträge in den jeweiligen Tabellen werden als Header Felder der HTTP/HTTPS Antwort vom Server an den Browser gesendet. Es können beliebige Felder gesetzt werden, z.B. Felder die für das HSTS Verfahren benötigt werden. Es wird empfohlen, eigene Header Felder mit dem Präfix X- zu versehen, um sie von den Standardfeldern unterscheiden zu können.

Hinweis: Header, die für die Einrichtung von HSTS interessant sein können, sind in der Reverse-Proxy-Konfiguration dokumentiert. Wenn Sie keinen Reverse-Proxy verwenden, können Sie diese Header auch hier setzen.

Hinweis: Die Verwendung dieses Features muss sorgfältig abgewogen werden, da Fehler dazu führen können, dass der Zugriff mittels Browser auf die Oberfläche nicht mehr funktioniert.