Hinweis: Dieser Artikel stellt ein Update des Textes aus dem Jahr 2021 dar.

Transportverschlüsselung

Transportverschlüsselung stellt in der IT-Sicherheit die Verschlüsselung der Daten während des Transports der Daten zwischen zwei Servern oder einem Server und dem Client dar. Dabei handelt es sich um eine Punkt-zu-Punkt-Verschlüsselung. Bekanntestes Beispiel für eine Transportverschlüsselung ist HTTPS, bei dem das eigentlich unverschlüsselte HTTP durch einen TLS-Tunnel verschlüsselt übertragen wird.

Im Folgenden wird die Einrichtung von HTTPS für novaFACTORY und WEGA unter dem Betriebssystem Windows beschrieben.

Voraussetzungen

Die Verwendung von HTTPS setzt die Benutzung eines X.509-Zertifikats für den Server voraus. Mit diesem Zertifikat weist sich der Server gegenüber dem Client aus. Auf Basis des Zertifikats kann der Client beim Aufbau der Verbindung beurteilen, dass die Kommunikation mit dem richtigen Server aufgebaut wird. Dazu muss das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (CA) explizit für den abzusichernden Server ausgestellt worden sein. Zum Zertifikat gehört grundsätzlich ein serverspezifischer, privater Schlüssel, auf dessen Basis die Anfrage bei der CA zur Ausstellung des Zertifikats gestellt wurde.

Bei der Zertifizierungsstelle kann es sich sowohl um eine öffentliche oder eine interne Stelle handeln. Eine öffentliche CA stellt Zertifikate aus, die von jedem Browser als vertrauenswürdig eingestuft werden. Diese Zertifikate kommen in der Regel bei Servern zum Einsatz, die aus dem Internet erreichbar sein sollen. Eine interne CA stellt in der Regel Zertifikate aus, die nur im Behörden- oder Firmenintranet akzeptiert werden. Eine CA besitzt ebenfalls ein Zertifikat, dem explizit das Vertrauen ausgesprochen werden muss. Bei öffentlichen Stellen sind diese in der Regel bereits im Browser bzw. im System hinterlegt. Bei internen CAs muss dies durch die Systemadministration z.B. durch das Active Directory erledigt werden.

Für Zertifikate gibt es verschiedene Dateiformate, in denen das Zertifikat und der dazugehörige Schlüssel vorliegen können. Unter Windows hat sich das Format „PKCS 12“ als Standard etabliert. Dieses ist an der Dateiendung „.p12“ oder „.pfx“ erkennbar. Dieses Format enthält das Zertifikat und den dazugehörigen Schlüssel in einer einzelnen Datei, womit die Einrichtung stark vereinfacht wird.

Zertifikatsspeicher in Windows

Unter Windows gibt es zwei Zertifikatsspeicher: Einen Speicher für den Benutzer und einen Speicher für den Computer. Im Computerspeicher sind normalerweise die beglaubigten Zertifikate der CAs hinterlegt. Im persönlichen Speicher des Benutzers hingegen werden die Zertifikate hinterlegt, für die der Anwender einen privaten Schlüssel besitzt. Aus Sicht von novaFACTORY und WEGA handelt es sich bei „dem Benutzer“ um die Betriebssystembenutzer, unter dem die Windowsdienste – speziell der Apache Tomcat – laufen.

Für die Einrichtung von HTTPS für novaFACTORY und WEGA muss daher zuerst das Zertifikat mit dem dazugehörigen Schlüssel in den persönlichen Zertifikatsspeicher des Dienstebenutzers importiert werden. Bei Vorliegen einer pfx-Datei passiert dies am einfachsten durch Doppelklick auf die Datei. Alternativ kann die Konfigurationskonsole „certmgr.msc“ als Dienstebenutzer gestartet und der Import manuell durchgeführt werden. Es ist wichtig, dass das Zertifikat in den persönlichen Speicher des Benutzers importiert wird.

Nach dem Import wird das Zertifikat in der Zertifikatskonsole von Windows angezeigt. Dabei wird der Servername angezeigt, für den das Zertifikat ausgestellt wurde. Dabei handelt es sich um den sogenannten Common Name (CN). Dieser wird später noch benötigt.

Konfiguration in Apache Tomcat

Da sowohl novaFACTORY als auch WEGA die Servlet Engine Apache Tomcat für die Auslieferung der Weboberfläche benutzen, erfolgt die eigentliche Einrichtung von HTTPS in dieser Software. Dazu ist in der Konfigurationsdatei conf\server.xml in der Installation des Apache Tomcat folgender „Connector“ zu konfigurieren:

<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
    sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
    maxThreads="150"
    SSLEnabled="true"
    scheme="https"
    secure="true"
    keyAlias="<CN_des_Zertifikats>"
    keystoreFile=""
    keystorePass=""
    keystoreType="Windows-My"
    clientAuth="false"
    sslProtocol="TLS"
    sslEnabledProtocols="TLSv1.2"
    keepAliveTimeout="200000" />

Beim Parameter keyAlias ist der Common Name des Zertifikats einzutragen. Der keystoreType „Windows-My“ stellt den persönlichen Zertifikatsspeicher des Dienstebenutzers dar, in den das Zertifikat vorher importiert wurde. Die leeren Parameter zum Zertifikatsspeicher sind aufgrund eines Bugs notwendig. Die aktivierten Protokolle („sslEnabledProtocol“) sind mit der IT-Administration abzustimmen. Beim Einsatz moderner Browser kann die oben beschriebene Konfiguration verwendet werden.

Zusätzlich muss die Java-Ausführungsumgebung für den Apache Tomcat so angepasst werden, dass die Windows-Zertifikatsspeicher verwendet werden können. Die Konfiguration erfolgt im Tomcat-Monitor im Reiter „Java“. Dort müssen folgende Parameter unter „Java Options“ ergänzt werden.

-Djavax.net.ssl.trustStoreProvider=SunMSCAPI
-Djavax.net.ssl.trustStoreType=Windows-ROOT
-Djavax.net.ssl.keyStoreProvider=SunMSCAPI
-Djavax.net.ssl.keyStoreType=Windows-MY
-Dcom.sun.security.enableAIAcaIssuers=true

Hier wird festgelegt, dass für die beglaubigten CA-Zertifikate der Zertifikatsspeicher des Benutzers verwendet wird („Windows-ROOT“). Zusätzlich wird nochmals der Zertifikatsspeicher des Dienstebenutzers für die Zertifikate mit privatem Schlüssel angegeben („Windows-My“). Der letzte Parameter ermöglicht eine zusätzliche Suchmöglichkeit nach CA-Zertifikaten, die die AIA-Erweiterung der Zertifikate nutzt. Diese Erweiterung ist z.B. für den OSM-WMS von Terrestris notwendig.

Alternativ ist es ab Java 11.0.18  auch möglich, auf Zertifikate im Computer anstatt des Benutzers zurückzugreifen. In den obigen Parametern ist dazu der Parameter trustStoreType auf „Windows-ROOT-LOCALMACHINE“ und der Parameter keyStoreType auf „Windows-MY-LOCALMACHINE“ zu ändern. Dann ist es nicht mehr notwendig, das Zertifikat mit dem privaten Schlüssel in den Benutzer des Apache Tomcat zu importieren, sondern das Zertifikat kann mit Mitteln des Active Directory dem Computer selbst zugewiesen werden. Die angesprochene Java-Version steht ab dem Frühjahrsrelease 2023 mit novaFACTORY und WEGA bereit.

Mit diesen Konfigurationsoptionen wird der integrierte Zertifikatsspeicher der Java JRE deaktiviert und nur noch auf die in Windows eingebauten Speicher zugegriffen. Wenn Sie Zertifikate in Java importiert haben, müssen diese damit in Windows importiert werden. Vorteil ist, dass die Zertifikate und Schlüssel auch ein Update der JRE überstehen, das den dortigen Zertifikatsspeicher überschreibt.

Nach einem Neustart des Apache Tomcat stehen die Weboberflächen von novaFACTORY und / oder WEGA damit unter HTTPS zur Verfügung.

Konfiguration in novaFACTORY

Wenn ein selbstsigniertes Zertifikat oder ein Zertifikat von einer nicht öffentlich beglaubigten CA verwendet werden soll, so sind in novaFACTORY noch verschiedene Konfigurationen anzupassen, damit dieses im Betrieb eingesetzt werden kann. Dies hängt damit zusammen, dass im Standardauslieferungszustand novaFACTORY auf die öffentlichen Beglaubigungsketten gesetzt wird, die solche Zertifikate nicht umfassen.

Zuerst sind in der Konfigurationsdatei rds.ini für die beiden Parameter „javaOpts“, „java64Opts“ und „pcmCmdOpts“ die Windows-CA-Speicher zu aktivieren. Dazu sind wieder die gleichen Parameter wie beim Apache Tomcat zuständig, die entsprechend ergänzt werden müssen.

-Djavax.net.ssl.trustStoreProvider=SunMSCAPI
-Djavax.net.ssl.trustStoreType=Windows-ROOT
-Dcom.sun.security.enableAIAcaIssuers=true

Da hier kein Zertifikat eingesetzt, sondern nur gelesen werden soll, können die beiden Parameter für den Zertifikatsspeicher weggelassen werden. Es gilt auch das oben gesagte, das statt „Windows-ROOT“ auch „Windows-ROOT-LOCALMACHINE“ verwendet werden kann, wenn der CA-Speicher des Rechners anstatt des Benutzers verwendet werden soll.

Zusätzlich sind in der Konfigurationsdatei rosy.ini folgende Umgebungsparameter zu ergänzen.

CURL_CA_BUNDLE=<Pfad zum Stammzertifikatsbundle>
REQUESTS_CA_BUNDLE=<Pfad zum Stammzertifikatsbundle>

Diese beiden Variablen dienen dazu, der Programmiersprache Python beziehungsweise deren Modul Requests aktualisiertes CA-Bundle zur Verfügung zu stellen. Dieses CA-Bundle dient Python als CA-Speicher analog dem in Windows integrierten Speicher, der weiter oben für Java verwendet wird.

Das entsprechende CA-Bundle muss manuell erzeugt werden. Dazu ist zuerst ein aktuelles Bundle in Form der Datei „cacert.pem“ unter https://curl.se/docs/caextract.html herunterzuladen. Dabei handelt es sich um den aktuellen CA-Speicher des Mozilla Firefox, das im Rahmen des Curl-Projekts in einer standardisierten Form zur Verfügung gestellt wird. Bei der heruntergeladenen Datei handelt es sich um eine Textdatei, die die CA-Zertifikate im Format PEM bzw. RFC 1422 enthält.

Um die Datei für novaFACTORY zu erweitern, benötigen Sie Ihr selbstsigniertes Zertifikat oder das Root-Zertifikat ihre eignen CA in ebendiesem Format. Kopieren Sie den Inhalt dieser PEM-Datei an das Ende der zuvor heruntergeladenen „cacert.pem“ und speichern Sie die Datei auf dem novaFACTORY-Server. Der Pfad der so veränderten „cacert.pem“ muss abschließend in die beiden o.g. Parameter in der rosy.ini eingetragen werden.

Konfiguration in WEGA-AuthService

Wenn Sie den WEGA-AuthService mit einem Active Directory verbunden haben, dann kann auch dort die Transportverschlüsselung für die Kommunikation mit den Domänen Controllern konfiguriert werden. Dabei kommt im Gegensatz zur Kommunikation im Browser das Protokoll LDAPS zum Einsatz.

Ausgehend von obiger Konfiguration im Apache Tomcat ist nur eine Zeile in der Konfigurationsdatei shiro.ini des WEGA-AuthService zu ändern und eine Zeile hinzuzufügen.

ldapContextFactory.environment[java.naming.security.protocol] = ssl
ldapContextFactory.url = ldaps://<DC-Servername>:636

Die erste Zeile aktiviert dabei die Transportverschlüsselung für die Kommunikation mit dem Active Directory. Der Wert „ssl“ ist hier historisch zu sehen. Auf modernen Systemen wird tatsächlich ein Tunnel mittels TLS aufgebaut. In der zweiten Zeile ist die Adresse des Domain Controllers eingetragen. Wichtig sind hier der Protokollname „ldaps“ und der Port 636 über den anschließend die verschlüsselte Verbindung läuft.

Nach der Änderung der Konfiguration ist ein Neustart des Apache Tomcat notwendig. Da die Clients nicht direkt mit dem Active Directory kommunizieren, sind dort keine Änderungen notwendig.