TLS Verschlüsselung mit einem Automic JCP ab V21

Ein Überblick

TLS Verschlüsselung mit einem Automic JCP ab V21

In diesem Blog-Artikel sollen erstmal (vereinfachte) Informationen zum besseren Verständnis von TLS und Zertifizierungsstellen gegeben werden. Diese sind aber nicht zwingend erforderlich, um ein Automic System mit TLS zu bestücken. Von daher richtet sich der zweite Teil dieses Artikels direkt an die Erstellung von Schlüsselpaaren, die Generierung von Zertifikaten, die Signierung dieser Zertifikate und dem Import in den Java KeyStore. Die Beispiele zur Erzeugung von Zertifikaten werden anhand von Keystore Explorer, keytool (java) und OpenSSL gezeigt. Das Vorgehen ist bei allen nahezu identisch und liefert das gleiche Ergebnis. 

Abschließend wird ein zu startender JCP mit einem signierten Zertifikat versehen, so dass sich z.B. ein TLS Gateway, ein Agent oder die REST-API mit diesem verbinden kann. 

Zum Thema TLS Gateway gibt es einen Vortrag von mir, um die Architektur eines Automic V21 Systems in dem Zusammenhang aufzuzeigen. Das Thema TLS Gateway wird somit in diesem Artikel nicht weiter behandelt.

Verschlüsselung

Um über unsichere Kanäle wie das Internet sicher kommunizieren zu können, bietet sich die Verschlüsselung des Datenverkehrs an. Ein weit verbreiteter Standard ist die TLS Verschlüsselung. Bei TLS handelt es sich um eine Verschlüsselung auf dem Transport Layer. TLS steht dabei für Transport Layer Security, auch bekannt unter der Vorgängerbezeichnung Secure Sockets Layer (SSL).

Wie funktioniert TLS

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

Wichtig hierbei ist der sog. Common Name (CN) welcher den Systemnamen beinhaltet. Dies ist bei einer späteren Prüfung des Zertifikats wichtig und notwendig. Dieses Zertifikat wurde mit einem privaten Schlüssel erstellt und kann mit dem öffentlichen Schlüssel verifiziert werden. Die Erstellung eines solchen Zertifikats und den dafür notwendigen Schlüsselpaaren widmen wir uns im späteren Verlauf dieses Artikels.

Eine Ergänzung zum Common Name: Sollte ein Zertifikat mehr als einen Hostnamen beinhalten so wird ein weiteres Attribut namens DNS Subject Alternative Name (SAN) verwendet. Sobald dieses Attribut gesetzt wird, prüft der Client dieses Attribute stattdessen (siehe https://datatracker.ietf.org/doc/html/rfc2818#section-2)

TLS Verschlüsselung

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error.

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.

Aufbau einer Verbindung

Eine sichere Verbindung wird anhand eines “ssl/tls handshakes” erstellt.

TLS Verschlüsselung

Hierbei soll der Verbindungsaufbau einmal sehr einfach dargestellt werden. Zunächst stellt der Client eine Verbindung zum Server her. Diese beantwortet der Server und sendet auch gleich sein Zertifikat mit. Wir erinnern uns, ein Zertifikat beinhaltet den Systemnamen oder in diesem Fall den Full Qualified Domain Name (FQDN). 

Mit diesem Zertifikat führt der Client nun eine Prüfung durch. Genauer gesagt zwei Prüfungen. Zum einen wird der FQDN überprüft, ob dieser aus dem Zertifikat identisch zu dem System ist, welches der Client kontaktiert hat. Zum anderen braucht der Client jemanden der ihm bestätigt, dass das Zertifikat auch echt ist. Dies behalten wir einmal im Hinterkopf und behandeln es später noch beim Signieren von Zertifikaten.

Nachdem der Client die Echtheit sowie den Inhalt des Zertifikats erfolgreich überprüft hat, nutzt er den öffentlichen Schlüssel des Servers, um eine erste verschlüsselte Nachricht an diesen zu schicken. Diese beinhaltet den Sitzungsschlüssel, mit dem die spätere Verbindung aufgebaut und durchgeführt wird. Der zuvor erstellte private und öffentliche Schlüssel dienen also nicht dazu, die spätere Verschlüsselung durchzuführen, sondern nur um einen geheimen Sitzungsschlüssel auszutauschen.

An dieser Stelle sollten wir alle notwendigen Informationen zum Thema privater/öffentlicher Schlüssel und Zertifikat haben, so dass diese sehr vereinfachte Beschreibung einer TLS Verbindung damit abgeschlossen ist.

Zertifikate und deren spätere Validierung

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.

Der Client muss also der CA vertrauen und vertraut automatisch auch allen Zertifikaten, welche diese CA ausgestellt hat. Die Webbrowser, Betriebssysteme, Java und ggf. weitere Applikationen pflegen bereits eine Liste von vielen vertrauenswürdigen CAs.

TLS Verschlüsselung

Somit ist es heutzutage zum Beispiel auch möglich, die Webseite https://www.best4automic.de aufzurufen und eine sichere Verbindung herstellen zu können, ohne dass jemals zuvor das Zertifikat vom Benutzer importiert worden ist. Unser System vertraut der Zertifizierungsstelle, welche letztendlich das Zertifikat signiert hat. In diesem Fall spricht man von einer PublicCA.

TLS Verschlüsselung

Es steht aber jedem frei, auch eine eigene CA zu erstellen und damit Zertifikate zu signieren. Den Clients muss dann diese root CA als vertrauenswürdige CA mitgeteilt werden. Vertraut der Client der Ca nicht, so gibt es einen Fehler bzw. je nach Client/Anwendung wird die Verbindung komplett ablehnt.

TLS Verschlüsselung

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.

Einrichten von TLS Zertifikaten

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.

Erzeugen eines Zertifikats

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

Open SSL

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.

Eigene root CA erstellen

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

TLS Verschlüsselung

Das Format belassen wir dabei auf PKCS#12

TLS Verschlüsselung

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

TLS Verschlüsselung

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

TLS Verschlüsselung

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

TLS Verschlüsselung

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

TLS Verschlüsselung

 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

TLS Verschlüsselung

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

TLS Verschlüsselung

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

TLS Verschlüsselung

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

TLS Verschlüsselung

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

TLS Verschlüsselung

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

TLS Verschlüsselung

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.

Automic JCP und der Keystore
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

Linux, Pinguin
best4Automic, Logo

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

Good to know
CSR Checker (ssl.de)  kann einen certificate signing request auf Gültigkeit prüfen bzw. graphisch darstellen. 

Import private key and certificate into java keystore (Example) (coderwall.com)

Wenn der PrivateKey nicht direkt beim erzeugen des java Keystores erstellt wurde, muss der mit openssl extrahiert und konvertiert werden, bevor das java keystore den annimmt 
Jetty11 Operations Guide | The Eclipse Foundation Jetty Anleitung (Hilfreich für die REST API SSL)
Java SSLPoke direkt mit java prüfen ob eine SSL Verbindung aufgebaut werden kann (die Java class SSLPoke runterladen und danach einfach  “java SSLPoke www.example.com ” ausführen)
mmc Windows management console (kann ein Zertifikatanfrage -> csr erstellen und auch ein Private Key exportieren)
https geht über Web aber über die Anwendung nicht

Wenn https über Web geht, aber nicht über java, kann im Webbrowser das Zertifikat angeklickt werden -> „Details“ -> copy file -> base64 (.cer) und danach Import mit keytool (cacerts)

Apache Tomcat 9 Configuration Reference (9.0.45) – The HTTP Connector

Parameter für den Tomcat Connector
Keystore Ablauffrist verlängern per Powershell (Windows) New-SelfSignedCertificate -DnsName automic -CertStoreLocation Cert:\LocalMachine\My -NotAfter (Get-Date).AddYears(2)
CSR-Datei die ursprüngliche Zertifikatsignieranforderungsdatei. Sie ist nicht erforderlich im keystore (cacerts etc.)
CRT-Datei enthält das SSL-Zertifikat, das von der Zertifizierungsstelle zurückgegegeben wurde
KEY-Datei enthält den privaten Schlüssel
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  .......

Michael Basse

Senior Consultant Automic

Michael Basse besitzt langjährige Erfahrungen in den Bereichen Linux und Business Process Automation mit Automic Automation. Lange Zeit war er für ein Unternehmen tätig, welches eine eigene GNU/Linux Distribution im Enterprise Umfeld einsetzte. Im Rahmen der Projekte hat er tiefgreifende Linux Erfahrungen in Enterprise-Umgebungen sammeln können. Er entwickelt heute noch an GNU/Linux-Systemen mit, hier in erster Linie an leichtgewichtigen Ubuntu-Systemen.