Transportverschlüsselung?
Transportverschlüsselung stellt in der IT-Sicherheit die Verschlüsselung der Daten während dem Transport 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 selbiger 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 o.a. 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 Computers 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 OpenStreetmap-WMS von Terrestris notwendig.
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.
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. Wenn der WEGA-AuthService per HTTPS erreichbar ist, kann aber dort die URL zum Dienst entsprechend angepasst werden.
Schlusswort
Die Einrichtung einer verschlüsselten Kommunikation ist in modernen Infrastrukturen problemlos möglich. Dabei können sowohl öffentliche Zertifikate für das Internet als auch private Zertifikate im Intranet zum Einsatz kommen.
Wenn Sie Fragen haben, kommen Sie gerne auf uns zu.
