TLS Verschlüsselung mit einem Automic JCP ab V21

Zur Nutzung von TLS sind zunächst ein Schlüsselpaar, bestehend aus privaten und öffentlichen Schlüssel, notwendig. Zusätzlich wird ein Zertifikat benötigt, welches aus diesem Schlüsselpaar hervorgeht und wichtige Informationen des Servers beinhaltet.

Nachfolgend ein Beispiel eines Zertifikats, ausgestellt für ein Automic V21 System mit dem Namen ul-srv21

Zum besseren Verständnis der Verschlüsselung betrachten wir nun aber zunächst einmal den Verbindungsaufbau anhand eines Beispiels mit https. Aufgrund der Tatsache, dass TLS auf der Transportschicht des OSI Models durchgeführt wird, lässt es sich für unterschiedliche Protokolle, wie zum Beispiel https, ftps, imaps usw., anwenden.

Ein Zertifikat beinhaltet Informationen, um ein Objekt oder eine Person zu beschreiben. Zur späteren Verwendung im Automic-Umfeld nutzen wir Zertifikate, um Objekte, genauer genommen Rechnerobjekte, zu beschreiben (und zu validieren).

Der wichtigste Parameter ist an dieser Stelle der Common Name (CN).  Wie kann nun aber der Client validieren ob das Zertifikat auch wirklich korrekt ist? Der Client kennt den Server bzw. die Person, welche das Zertifikat ausgestellt hat, ja nicht. Vielleicht hat auch jemand etwas an der Netzwerk-Konfiguration geändert und wir sprechen nun mit einem ganz anderen Server, welcher sich nur als das System ausgibt, welches wir eigentlich ansprechen wollen.

Vertrauen ist an dieser Stelle das Stichwort. Hierzu gibt es zwei Möglichkeiten.

1. Dem Client wird mitgeteilt, dass das ihm gesendete Zertifikat vertrauenswürdig ist. Das Zertifikat ist somit in den eigenen Zertifikatsspeicher als vertrauenswürdig abzulegen. In diesem Fall handelt es sich dann um ein sog. self signed Zertifikat
2. Eine (externe) Zertifizierungsstelle (Certificate Authority, CA) signiert das Zertifikat und bestätigt somit die Echtheit des Zertifikats. Technisch wird ein sog. Certificate Singing Request (CSR)  erstellt, welcher sich aus dem Zertifikat und geheimen Schlüssel ableitet. Die CA prüft nun diesen CSR mit dem öffentlichen Schlüssel und unterschreibt die Echtheit mit ihrem eigenen geheimen Schlüssel. Jeder im Besitz des öffentlichen Schlüssels der CA kann somit die Unterschrift verifizieren.

Wir erinnern uns, dass TLS auf der Transportschicht stattfindet. Somit treffen die beschrieben Verfahren und Techniken neben vielen weiteren Protokollen auch für https und letztendlich auch für die Kommunikation der Automic Automation Engine über ihre JCPs mit Agenten, TLS Gateway(s), REST-API usw. zu.

Zur Erstellung eines Zertifikats ist zunächst ein Schlüsselpaar, bestehend aus öffentlichem und geheimem Schlüssel notwendig. Der geheime Schlüssel wird dazu verwendet, das spätere Zertifikat zu signieren. Der öffentliche Schlüssel dient dabei den Clients der Verifizierung des entsprechende Zertifikates. Zu diesem Zeitpunkt ist das entsprechende Zertifikat noch nicht (von einer Zertifizierungsstelle) signiert. Schauen wir uns aber zunächst einmal die Erstellung eines Schlüsselpaares an. Dabei sollen die Schritte jeweils mit folgenden Tools aufgezeigt werden. Alle drei erzeugen das selbe Ergebnis, sind aber ggf. nicht überall verfügbar. Der KeyStore-Explorer bietet auch eine grafische Oberfläche so dass diese Beispiele ebenfalls aufgezeigt werden.

Am Beispiel von OpenSSL soll dies sehr detailliert geschehen. Für das java keytool wird ein grober Ablauf beschrieben.

Zur Erstellung eines Zertifikats welches letztendlich unseren Servernamen ul-srv21 als Common Name beinhaltet soll, ist zunächst ein Schlüsselpaar notwendig

In diesem Beispiel erzeugen wir uns zunächst ein Schlüsselpaar auf der Kommandozeile. Es empfiehlt sich für die Dateien sprechende Namen zu verwenden. Wichtig dabei ist zu beachten, dass der private Schlüssel auch wirklich privat bleibt. In produktiven Umgebungen empfiehlt es sich sehr den Schlüssel mit einem Passwort zu versehen. Während der Erstellung des Schlüssels wird man automatisch nach dieser Option gefragt. Das Passwort ist anschließend sicher zu verwahren.

# erzeugen eines Private RSA 2048 Keys (für den Server)
openssl genrsa -out ul-srv21_private_key.pem 2048

# erzeugen des public Keys aus dem Private Key
openssl rsa -in ul-srv21_private_key.pem -outform PEM -pubout -out ul-srv21_public_key.pem

Mit dem soeben erzeugten Schlüsselpaar bestehend aus

• Geheimem Schlüssel ul-srv21_private_key.pem
• Öffentlichem Schlüssel ul-srv21_public_key.pem

lässt sich nun ein Zertifikatsrequest erstellen.

# erstellen eines CSR
openssl req -new -key ul-srv21_private_key.pem -out ul-srv21.csr

In diesem Schritt werden unterschiedliche Optionen abgefragt. Zwingend korrekt ist hier der Common Name (CN) anzugeben, welcher unserem Systemnamen entspricht.

Ein Beispiel ist nachfolgend für das System ul-srv21 zu finden, welches zu best-blu consulting with energy GmbH gehört.

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Niedersachsen
Locality Name (eg, city) []:Salzgitter
Organization Name (eg, company) [Internet Widgits Pty Ltd]:best-blu consulting with energy GmbH
Organizational Unit Name (eg, section) []:bbc.local
Common Name (e.g. server FQDN or YOUR name) []:ul-srv21
Email Address []:info@best4automic.de

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Dieser Signierungsrequest kann nun entweder von einer PublicCA, einer eigenen root CA im Haus oder selbst signiert werden.

Im ersten Schritt signieren wir unser Zertifikat selbst

openssl x509 -signkey ul-srv21_private_key.pem -in ul-srv21.csr -req -days 365 -out ul-srv21.crt

Das Zertifikat ist nun für 365 Tage gültig und wurde als ul-srv21.crt gespeichert. Dieses kann nun für TLS Verbindungen genutzt werden. Allerdings vertrauen die Clients dem Zertifikat nicht, da es von keiner ihnen bekannten Zertifizierungsstelle signiert worden ist.

Im Beispiel des Automic-Systems müsste nun dieses Zertifikat auf allen Clients entsprechend als vertrauenswürdigen Zertifikat hinzugefügt werden. Nach 365 Tagen müsste dieser Schritt dann spätestens wiederholt werden, da dann das Zertifikat seine Gültigkeit verliert.

Diese Option des Self Sign ist daher nicht zu empfehlen.

Sollte es im Hause bereits eine eigene CA geben, so lässt man der CA einfach den CSR zukommen und bekommt ein signiertes Zertifikat zurück. Sämtlichen Clients muss dann nur einmalig die entsprechende CA als vertrauenswürdige CA hinzugefügt werden. Läuft das Zertifikat nach 365 Tagen ab, so wird es ein neues CSR an die CA geschickt, welche dieses wieder signiert. Da die Clients der CA bereits vertrauen, ist hier kein weiterer Schritt auf den Clients notwendig.

Was nun aber machen, wenn man noch keine eigene CA im Haus hat, man aber trotzdem dieses Verfahren nutzen möchte? 

Selbst ist die CA, also erstellen wir uns einfach unsere eigene CA mit welcher wir dann unsere Zertifikate signieren.

Mit OpenSSL ist dazu zunächst wieder ein Schlüsselpaar zu erstellen. Diesmal allerdings für die CA selbst.

# erzeugen eines Private RSA 2048 Keys (für eine CA)
openssl genrsa -out ca_private_key.pem 2048
  
#Erstellen einer eigenen CA
openssl req -x509 -new -nodes -extensions v3_ca -key ca_private_key.pem -days 1024 -out ca-root.pem -sha512

Mit dieser nun erstellten CA können bestehende Zertifikate signiert werden.

#Signieren eines CSR
openssl x509 -req -in ul-srv21.csr -CA ca-root.pem -CAkey ca_private_key.pem -CAcreateserial -out ul-srv21-pub-cert.pem -days 365 -sha512

Die Datei ul-srv21-pub-cert.pem ist nun das von der eigenen CA unterschriebene Zertifikat.
Um den Clients diese CA als vertrauenswürdige CA mitzuteilen, ist die Datei ca-root.pem den Clients hinzuzufügen. Dies kann entweder über Betriebssystemmittel gemacht werden, so dass es im Zertifikatsspeicher des Betriebssystem landet. Es kann unter Windows z.b. per GPO verteilt werden oder aber es wird dem Java Keystore hinzugefügt.

Es empfiehlt sich nicht diese root CA dem cacerts der JVM hinzuzufügen. Ein späteres Update der JVM würde eine neue cacerts mitbringen und somit die hinzugefügte root CA überschreiben.

JRE_HOME/bin/keytool  -import  -trustcacerts
                         -alias certAlias  -file ca-root.pem
                         -keystore trustStoreFile

Von nun an vertraut Java allen Zertifikaten welche von unserer zuvor erstellten root ca (ca-root.pem) signiert worden sind.

KeyTool

1. Keystore muss erstellt werden und muss am Ende den Private-key und das signierte Zertifikat enthalten
2. Nach der Erzeugung des Keystores muss ein Zertifizierungsanfrage an die Zertifizierungsstelle generiert werden (CSR request)
3. Das signierte Zertifikat muss in den Keystore eingespielt werden

Beispiel für die Keytool Befehle

1. keytool -genkey -keystore -deststoretype pkcs12 -dname “CN=, OU=, O=, L=, ST=, C=DE, EMAILADDRESS=” -keyalg RSA -alias -keysize 4096
2. keytool -certreq -file -keystore .jks -alias -ext SAN=DNS:,DNS: (es können beliebig viele DNS Einträge spezifiziert werden)
3. Der Request muss von der Zertifierungsstelle angenommen und ein Zertifikat-File ausgeliefert werden 
4. keytool -import -trustcacerts  -alias   -file -keystore

Ggf. kommt es beim Import des Zertifikates zur Meldung “is not trusted. Install reply anyway? [no]:”. Diese Warnung kann – je nach Anforderung des Kunden – mit “yes” bestätigt werden. Nachdem diese Anfrage mit “yes” bestätigt worden ist, wird auch in diesem Fall, genau wie im OpenSSL Beispiel vorher, dieser root CA vertraut, so dass die von ihr signierten Zertifikate als gültig anerkannt werden

Keystore-Explorer

Der Keystore-Explorer steht unter allen gängigen Betriebssystemen zur Verfügung und bietet eine grafische Benutzeroberfläche zur Erzeugung von Schlüsselpaaren sowie Zertifizierungsrequests und den daraus resultierenden Zertifikaten.

Die aus dem Keystore-Explorer erzeugten Keystores können direkt in die AE für den JCP eingebunden werden. Es bietet sicherlich die einfachste Möglichkeit, um sich (mal eben) Zertifikate zu erstellen und mit der AE zu verwenden.

Der Keystore-Explorer ist hier zu finden: https://keystore-explorer.org/

In diesem Beispiel wollen wir ein selbst signiertes Zertifikat erstellen und im Keystore speichern. Abschließend soll dieser Keystore dann in der ucsrv.ini eingebunden werden.

Erzeugung eines Schlüsselpaares

Nach dem Start des Keystore Explorers ist zunächst ein neuer Schlüsselspeicher (Keystore) zu erstellen

Das Format belassen wir dabei auf PKCS#12

Zunächst müssen wir genau wie bei OpenSSL als auch bei dem Keytool ein entsprechendes Schlüsselpaar erstellen. Dazu kann über Werkzeuge → “Schlüsselpaar erstellen” selbiger angelegt werden

Die RSA Schlüsselgröße bleibt hier auf dem Default Wert von 2048 stehen.

Der nächste Dialog bietet nun direkt die Möglichkeit aus diesem Schlüsselpaar auch ein entsprechendes Zertifikat zu erstellen. Hier ist der zwingend erforderliche Common Name anzugeben, welcher identisch zum Hostnamen sein muss

Nachdem die notwendigen Informationen ausgefüllt worden sind, wird mit einem Klick auf OK das entsprechende Zertifikat erstellt

 An dieser Stelle sei nochmal auf die Wichtigkeit des Eintrags “CN” hinzuweisen. Anhand dieses Eintrags verifiziert der Client nachher das entsprechende Zertifikat welches es vom Server (in diesem Fall ul-srv21) bekommen hat.

In vorherigen Automic-Versionen war der Alias zwingend auf “jetty” zu setzen, daher wählen wir den Alias auch für unser Beispiel und bestätigen diesen

Es wurden nun alle notwendigen Informationen angeben und der Keystore-Explorer beginnt nun, das Schlüsselpaar zu erstellen und wenig später auch das entsprechende Zertifikat. Es empfiehlt sich, sowohl das Schlüsselpaar als auch den Keystore mit entsprechenden (unterschiedlichen) Passwörtern zu verwenden. Diese Passwörter sollten gut aufbewahrt werden. Bei der Einbindung in die AE sind diese nämlich in der entsprechenden config anzugeben

Unser Keystore-Explorer hat nun erfolgreich ein Schlüsselpaar erstellt. 

Das entsprechende Zertifikat muss nun noch signiert werden. Wie bereits vorher (ausführlicher im Kapitel OpenSSL beschrieben) stehen hierfür 3 Möglichkeiten zur Verfügung.

1. Selbst signiertes Zertifikat
2. Eigene root CA (im Haus)
3. Public CA

Die entsprechenden Optionen sind bequem mit der rechten Taste im Kontextmenü auszuführen

Nachdem das Zertifikat mit einem der 3 genannten Verfahren unterschrieben worden ist, kann der Keystore gespeichert werden

Der Keystore selbst, welcher das Schlüsselpaar und auch das signierte Zertifikat enthält (sowie um weitere Schlüssel und Zertifikate erweitert werden kann), sollte ebenfalls mit einem Passwort versehen werden

Auch dieses Passwort ist wieder gut zu verwahren. Nachdem der Keystore gespeichert worden ist (in unserem Fall als ul-srv21) kann im finalen Schritt nun die AE mit dem keystore bestückt werden.

Passwörter verschlüsseln

Damit die Passwörter für den Keystore als auch das Schlüsselpaar von der AE akzeptiert werden, sind diese mit dem Automic Tool UCYBCRYP.exe entsprechend verschlüsselt. Dieses Programm steht unter der Windows-Version der AE im Verzeichnis Utiliy zur Verfügung.

Sollten Sie wie der Autor kein Windows haben, so können Sie auch einfach das best4Automic Modul util.PasswordCrypt verwenden. Sollten die noch kein b4A kennen, so schauen Sie gerne einmal auf www.best4automic.de vorbei

Es ist sowohl das Passwort des Schlüsselpaares als auch des zuvor erzeugten Keystores entsprechend zu verschlüsseln. Die daraus resultierende Passwort-String (beginnend mit –) ist in der ucsrv.ini zu verwenden welcher wir uns im nächsten Abschnitt widmen.

ucsrv.ini

Nachdem nun einiges an Fleißarbeit in das Thema Schlüssel und Zertifikate geflossen ist, stellt sich die Anbindung in die AE als relativ einfach dar. In der entsprechenden Server Config (ucsrv.ini) sind im Abschnitt TLS 4 Einstellungen vorzunehmen

TLS]
;
; keystore: Path and file where the keystore for TLS certificate is stored
;
keystore=/opt/AE/Certificates/ul-srv21
;
; keystorePassword: Password of the keystore File
;
keystorePassword=--1065E31B04EB6F5E6A
;
; keyPassword: Password for the Keys protection
;
keyPassword=--1065E31B04EB6F5E6A
;
; keyAlias: The name which the key is identified with.
;
keyAlias=jetty

Die Passwörter sind dabei die zuvor generierten verschlüsselten Strings. Wobei keystorePassword zum Öffnen des Keystores genutzt wird. keyPassword repräsentiert das Passwort des geheimen Schlüssels aus unserem Schlüsselpaar.
Der Keystore (die bereits erstellte Datei) welche unser Schlüsselpaar sowie das Zertifikat enthält. Hier ist der entsprechende Pfad zur Datei anzugeben
Abgeschlossen werden die Einstellungen mit dem Alias des Keystores, welcher zumindest in älteren AE Versionen zwingend jetty sein musste.

Sollten wir alles richtig gemacht haben, so kann jetzt der JCP über den ServiceManager gestartet werden und bietet ab sofort TLS Verschlüsselungen gegenüber seinen Clients an.

Die Agenten müssen übrigens nicht mit extra Zertifikaten ausgestattet werden. Hier agiert die AE bzw. der JCP entsprechend und teilt den Agenten entsprechende Zertifikate zu. Diese sind nämlich zwingend erforderlich, wenn sich Agenten untereinander unterhalten sollen. Dies ist bei Filetransfers der Fall. Wichtig ist allerdings anzumerken, dass die Agenten der entsprechenden CA vertrauen müssen. Sprich die CA muss den Agenten als vertrauenswürdig bekannt sein. Bei einer PublicCA ist dies in der Regel bereits der Fall. Sollte eine eigene CA im Hause genutzt werden, so ist diese ggf. noch den Agenten bzw. entsprechenden Betriebssystemen als vertrauenswürdig mitzuteilen

Besonderheit REST API https (AE12.3)

Die AE erwartet den Alias “jetty” und lässt nichts anderes zu (dies war zumindest bis zur AE12.3 noch der Fall, der Key und das Zertifikat müssen also zwingend mit dem Alias “jetty” erzeugt werden.

Beispielbefehle:

• keytool -genkey -keystore  ....... -alias jetty

• keytool -certreq -file  -keystore .jks -alias jetty ........

• keytool -import -trustcacerts  -alias jetty  .......