Zertifikate
In Lobster Integration können sie zur verschlüsselten Kommunikation an verschiedenen Stellen Zertifikate verwenden. Hier können Sie diese zentral verwalten.
Begriffe und Know-How
Die Begriffe in diesem Abschnitt beziehen sich auf eine sogenannte Public-Key-Infrastruktur, speziell auf den Standard X.509 der internationalen Fernmeldeunion (ITU-T), sowie verwandte Standards. Wir setzen die Begriffe asymmetrische Verschlüsselung, öffentlicher Schlüssel, privater Schlüssel, Zertifikat, Zertifizierungsstelle (Certificate Authority oder CA), Fingerprint, Signatur und themenverwandte Begriffe aus dem Bereich sicherer Datenübertragung als bekannt voraus. Das Ziel dieser Dokumentation ist es nicht, diese Begriffe und ihre Zusammenhänge im Detail zu erklären. Dazu gibt es viele frei zugängliche Dokumente.
Ein digitales Zertifikat bezieht sich immer auf ein asymmetrisches Schlüsselpaar mit privatem und öffentlichem Schlüssel. Es enthält strukturierte Daten, die eine Verbindung zwischen dem technischen Schlüssel und der Identität des rechtmäßigen Eigentümers (Person, Organisation, Firma, IT-System) dieses Schlüssels herstellen. Zertifikate enthalten immer einen Gültigkeitszeitraum und eine Adresse, die mehrere Bestandteile hat und die den Inhaber adressiert. Ein wichtiger Bestandteil dieser Adresse ist der Common Name (CN).
Als Zertifikatsobjekt oder Zertifikat bezeichnen wir hier die Kombination eines digitalen Zertifikats mit einem oder beiden Schlüsseln.
Partner-Zertifikate
Als Partner-Zertifikat bezeichnen wir hier ein Zertifikatsobjekt, das das digitale Zertifikat und nur den öffentlichen Schlüssel enthält, aber nicht den privaten Schlüssel. Die beiden Begriffe Partner-Zertifikat und öffentlicher Schlüssel werden oft gleich bedeutend verwendet.
Eigene Zertifikate
Als eigenes Zertifikat bezeichnen wir hier ein Zertifikatsobjekt, das das digitale Zertifikat und beide Schlüssel (öffentlich und privat) enthält.
Zertifikats-Seriennummer
Zu jedem eigenen Zertifikat (mit privatem und öffentlichem Schlüssel) muss üblicherweise auf dem Partnersystem, mit dem kommuniziert werden soll, ein Partner-Zertifikat (ohne privaten, nur mit öffentlichem Schlüssel) installiert werden. Um beide eindeutig zueinander zuordnen zu können, existiert eine Zertifikats-Seriennummer. In Lobster Integration wird die Seriennummer einheitlich als dezimale Ganzzahl dargestellt.
Falls das Zertifikat durch eine offizielle Zertifizierungsstelle signiert wurde, kann die Prüfung der Gültigkeit über das Netz erfolgen. Auch in diesen Fällen existiert ein privater und ein öffentlicher Schlüssel. Das Partner-Zertifikat (nicht das eigene mit dem privaten Schlüssel!) kann aber sorglos über das Netz ausgetauscht werden, weil es durch die Signierung gegen Manipulation geschützt ist. Wenn man dem Partner das Partner-Zertifikat zusendet, z. B. per E-Mail, kann er anhand des Fingerprints oder der Prüfsumme sicherstellen, dass es während des Transportes nicht verändert wurde.
Ziele der X.509-Technologie
Die X.509-Technologie erlaubt das Verschlüsseln der Daten, sowie die Signierung mit einer digitalen Unterschrift. Die Erzeugung des Schlüsselpaares und Zuordnung beschreibender Zertifikats-Informationen ist ein geschlossener einmaliger Vorgang. Eine nachträgliche Veränderung der Schlüssel oder der beschreibenden Informationen ist ausgeschlossen. Daten, die mit dem einen Schlüssel verschlüsselt wurden, können nur mit dem anderen Schlüssel wieder hergestellt (entschlüsselt) werden.
Der eine Schlüssel (privat) ist nur dem Inhaber des Zertifikats bekannt. Der andere Schlüssel (public) ist für die Weitergabe an die Kommunikationspartner bestimmt. Solange der Inhaber des Zertifikats sichert, dass sein privater Schlüssel nie in fremde Hände gerät, ist gesichert, dass die Daten in der verschlüsselten Phase nicht manipuliert werden können, denn das bricht die Integrität. Manipulierte Daten können nicht mehr entschlüsselt werden. Ein Abfangen der Daten, Entschlüsseln, Manipulieren und neu Verschlüsseln scheitert daran, dass niemand außer dem Zertifikatsinhaber beide Schlüssel hat. Das ist eine entscheidende Bedingung.
Damit ermöglichen digitale Zertifikate den Schutz der Vertraulichkeit, der Authentizität und Integrität der Daten, vor allem während des Transports über das Netz.
Verschlüsselung
Um Daten gesichert zu einem Partner zu übertragen, werden diese Daten mit dem öffentlichen Schlüssel dieses Partners (also mit dem Partner-Zertifikat) verschlüsselt.
Nur der Partner kann mit seinem privaten Schlüssel, den nur er besitzt, diese Daten wieder entschlüsseln. Wenn der Partner uns verschlüsselte Daten senden will, muss er sie mit unserem öffentlichen Schlüssel verschlüsseln, damit nur wir sie mit unserem privaten Schlüssel (also mit unserem eigenen Zertifikat) wieder lesen können.
Der Partner muss dazu im Besitz des öffentlichen Schlüssels unseres eigenen Zertifikates sein. Umgekehrt müssen wir seinen öffentlichen Schlüssel haben. Er kann unseren öffentlichen Schlüssel als exportiertes eigenes Zertifikat von uns erhalten haben, z. B. per E-Mail, oder er kann ihn während des Verbindungsaufbaus online von uns erhalten haben. Wir müssen also das Partner-Zertifikat, das wir vom Partner erhalten, importieren und die Partner müssen unser exportiertes eigenes Zertifikat auf ihrer Seite als Partner-Zertifikat installieren.
Bei einem sicheren Webserver erhalten die Clients (die der Server nicht vorher kennt) das Zertifikat und den öffentlichen Schlüssel beim Verbindungsaufbau während des SSL-Handshakes.
Signierung
Eine Signierung der Daten ist im Prinzip eine zusätzliche Verschlüsselung. Wenn man einem Partner die Daten signiert und verschlüsselt schickt, werden die Daten zuerst mit dem öffentlichen Schlüssel des Partners verschlüsselt (Verschlüsselung), dann wird über die Daten ein Hash (eine Art Prüfsumme) gebildet und dieser Hash dann mit dem privaten Schlüssel des eigenen Zertifikats nochmals verschlüsselt (Signierung).
Der Partner entschlüsselt dann zuerst mit dem öffentlichen Schlüssel unseres Zertifikats die Signatur, prüft die Prüfsumme und wenn sie richtig ist, werden mit dem privaten Schlüssel seines eigenen Zertifikats die Daten entschlüsselt.
Wenn wir die Daten nur signiert senden, gehen sie im Klartext über das Netz, denn die Signierung ist ja nur eine Verschlüsselung des Hashs mit dem eigenen (privaten) Schlüssel, aber keine Verschlüsselung der Daten. Über die Prüfung der Signierung kann festgestellt werden, dass nur wir die Daten gesendet haben können, denn nur wir als Inhaber des privaten Schlüssels können die Prüfsumme richtig verschlüsseln.
Austausch eines Partnerzertifikats
Sollen Zertifikate verwendet werden, tauschen Sie bitte nur den öffentlichen Teil mit dem jeweiligen Partner aus. Bitte geben Sie niemals(!!!) den privaten Teil außer Haus und bedenken Sie, dass Zertifikate meist eine zeitliche Begrenzung der Gültigkeit haben. Nach Ablauf des Gültigkeitszeitraumes wird das Zertifikat ungültig und damit ist keine Kommunikation mehr möglich.
Ein eigenes Zertifikat, das aus Lobster Integration für einen Ihrer Partner exportiert worden ist, ist eine gezippte CER-Datei und enthält nur den öffentlichen Schlüssel.
Wenn Ihnen ein Partner ein Zertifikat (nur mit seinem öffentlichen Schlüssel) schickt, unterstützt Lobster Integration die folgenden X.509-Zertifikats-Formate.
.CER - CER-kodiertes Zertifikat oder Zertifikatsfolgen.
.CRT - DER- oder Base64-kodiertes Zertifikat.
.DER - DER-kodiertes Zertifikat.
.PEM - Base64-kodiertes Zertifikat.
Die Formate .P12 und .PFX (PKCS#12) können als eigenes Zertifikat importiert werden, wenn sie fehlerfrei sind und den privaten Schlüssel enthalten. Achtung: Wenn das Passwort nicht stimmt, erscheint die (irreführende) Fehlermeldung, dass kein Zertifikat enthalten ist.
Das Format .P7B (PKCS#7) kann als Partner-Zertifikat importiert werden, wenn es fehlerfrei ist. Achtung: Wenn das Passwort nicht stimmt, erscheint die (irreführende) Fehlermeldung, dass kein Zertifikat enthalten ist.
Einzige Ausnahme: Wenn man aus einem eigenen Zertifikat einen CSR (Certificate Signing Request) erzeugt und von der Zertifizierungsstelle signieren lässt, kann es möglich sein, dass man die Zertifikatsantwort als .P7B oder .P7C zurück bekommt. Diese kann nicht als Zertifikatsantwort zu dem bisherigen Zertifikat hinzugefügt werden. Hier hilft es, wenn man die .P7B-Datei unter Windows mit der Krypto-Shellerweiterung öffnet und alle Komponenten der Zertifikatskette (üblicherweise 3, eigenes, intermediate und CA-Root) als Base64-codierte .PEM- oder .CER-Datei speichert und dann alle drei Datei-Inhalte in umgekehrter Reihenfolge (CA-Root zuletzt) in eine .CER-Datei kopiert. Diese Datei kann dann normal als Zertifikatsantwort zu dem vorhandenen Zertifikat, von dem der CSR erstellt wurde, hinzugefügt werden.
Hinweis zum PEM-Format
Das PEM-Format ist eine Base64-Zeichenkette zwischen
-----BEGIN CERTIFICATE----- und -----END CERTIFICATE-----.
Falls in dem PEM-Format zusätzlich ein Abschnitt von -----BEGIN RSA PRIVATE KEY----- bis -----END RSA PRIVATE KEY----- existiert, so wäre das der private Schlüssel, der niemals(!!!) weitergegeben werden darf.
Selbstsigniertes oder durch Zertifizierungsstelle beglaubigtes Zertifikat?
Um ein Zertifikat z. B. für eine Browseranwendung auf SSL-Basis verwenden zu können, bei der viele anonyme Clients mit dem Server kommunizieren, sollte das Zertifikat durch eine offizielle Zertifizierungsstelle (Certificate Authority oder CA) beglaubigt werden. Diese Beglaubigung ist eine "Bestätigung vor aller Welt" durch eine unabhängige, vertrauenswürdige Instanz, dass der Server dieses Zertifikat berechtigterweise verwendet.
In der B2B-Kommunikation ( business-to-business) können auch selbstsignierte Zertifikate verwendet werden, weil zwischen zwei Geschäftspartnern nicht eine dritte Instanz nötig ist, um die Echtheit zu beglaubigen.
Jedes hier in der Partnerverwaltung erzeugte eigene Zertifikat ist ein selbstsigniertes, das nicht von einer Zertifizierungsstelle beglaubigt ist. Es kann aber prinzipiell beglaubigt werden. Dazu ist es erforderlich, aus dem eigenen Zertifikat einen Certificate Signing Request (CSR) zu erzeugen und diese CSR-Datei an eine Zertifizierungsstelle zu senden. Öffnen Sie dazu das Zertifikat mit einem Doppelklick (1).
Anschließend drücken Sie Button "Erzeuge CSR" (2). In einem weiteren Dialog können Sie den CSR Request dann kopieren und anschließend an die Zertifizierungsstelle schicken.
Die Zertifikatsantwort der Zertifizierungsstelle (Certificate Signing Request Response) muss dann in das selbstsignierte Zertifikat importiert werden mit Button "Importiere CSR" (3). Eine solche Beglaubigung über eine öffentliche Zertifizierungsstelle ist üblicherweise kostenpflichtig und ist für die meisten Anwendungen mit Lobster Integration nicht erforderlich.
Die Reihenfolge der einzelnen Bestandteile des CSRs ist wie folgt:
CSR Response
Issuer
Root
Falls Sie die Dateien nur einzeln zur Hand haben, bitte im Editor in einer Datei in oben genannter Reihenfolge zusammenführen.
Java Cryptography Extension
Lobster Integration benötigt für die Verschlüsselung und Signierung Kryptographie unbegrenzter Stärke (also Schlüssel unbegrenzter Länge). Aufgrund geltender Exportbeschränkungen der USA müssen für die verwendete Java-Version gegebenenfalls Erweiterungen installiert werden, um mit unbegrenzter Schlüssellänge arbeiten zu können.
Für das Java JDK 1.6 ist dies die Java(TM) Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6. Bei fehlender JCE bricht der Start des Integration Servers ab mit der folgenden Fehlermeldung:
"The Java Virtual Machine can't handle strong cryptography".
Achtung: Laden Sie bitte die Datei, passend zu Ihrer Java-Version, nur original von Oracle herunter.
Hinweis: Nach einem Upgrade der Java-Version muss die passende Extension erneut heruntergeladen und installiert werden.
Eigene Zertifikate
Hier können eigene Zertifikate erstellt, importiert, exportiert, betrachtet und zurückgezogen werden. Außerdem kann ein Certificate Signing Request (CSR) erzeugt werden. Über das Kontextmenü kann zudem ein CSV-Report erstellt werden, der auflistet, in welchen Kanälen ein Zertifikat verwendet wird. Die ID des Zertifikats und den Common Name (CN) finden Sie über (1). Dabei ist die ID nicht mit der Seriennummer zu verwechseln.
(1) und (2): Zertifikate werden nach Ablauf ihrer Gültigkeit automatisch ungültig. Wenn man vor Ablauf der Gültigkeit Anlass zu der Annahme hat, dass dieses Zertifikat nicht mehr sicher ist, weil es kompromittiert wurde, kann es über (1) und (2) "Zertifikat zurückziehen" zurückgezogen werden (mit Admin-Rechten). Dabei wird es nicht gelöscht, weil sonst die mit diesem Zertifikat verschlüsselten oder signierten Daten nicht mehr lesbar wären. Hinweis: Das Zurückziehen hier ist lediglich ein lokales Deaktivieren des Zertifikats und ist nicht verbunden mit einem offiziellen Eintrag in der Zertifikatsperrliste (Certificate Revocation List, CRL) als widerrufen. Ein auf diese Art lokal deaktiviertes Zertifikat kann wieder aktiviert werden über (1) (Filter davor entsprechend einstellen).
(3) Verwendungszweck (Signierung, Verschlüsselung, TLS Client, TLS Server): Setzt die "usage flags", also wofür das Zertifikat verwendet werden kann.
(4) Verwendungszweck (Signierung/Verschl. Vorgabe muss unterstützt werden, TLS Vorgabe muss unterstützt werden): Mit diesen Checkboxen können für die Einstellungen in (3) sogenannte "critical flags" gesetzt werden. Damit kann eingefordert werden, dass der Kommunikationspartner beim Einspielen des Zertifikats bei sich überprüft, ob er die von Ihnen in (3) vorgenommenen Einstellungen unterstützt. Wenn er das nicht tut, sollte er das Zertifikat verwerfen. Wir empfehlen die hier zu sehenden Default-Einstellungen in (4) zu verwenden, um zu vermeiden, dass Ihr Zertifikat evtl. abgelehnt wird. Für nahezu alle Fälle sind diese so richtig. Ändern Sie sie nur, wenn Sie wirklich wissen, was Sie tun.
(5) Zertifikat/SSH Schlüssel importieren: Siehe Abschnitte "Eigenes Zertifikat importieren" und "Import eines SSH-Schlüsselpaares als lokales Zertifikat" unten.
Let's Encrypt
Siehe Abschnitt "Let's Encrypt/ACME/Certbot" unten (kostenfrei und automatisch Zertifikate von Certificate Authority erhalten und erneuern).
Eigenes Zertifikat erzeugen
Die folgende Abbildung zeigt den Dialog zur Erzeugung von selbstsignierten Zertifikaten im X.509 Standard, der nach Drücken des Plus-Buttons unten rechts (1) erscheint. Eine Beschreibung der Felder entnehmen Sie bitte dem X.509-Standard.
Bei Erzeugung eines eigenen Zertifikats für OFTP2, kann als Eigenschaft auch eine ODETTE-ID zugeordnet werden.
Eigenes Zertifikat exportieren
Ein eigenes Zertifikat kann über das Kontextmenü exportieren werden. Sie können hier in verschiedenen Formaten entweder nur das Zertifikat, nur den privaten Schlüssel oder das Zertifikat und den privaten Schlüssel herunterladen.
Wichtiger Hinweis: Wenn Sie einem Partner das Zertifikat z. B. in einer E-Mail schicken möchten, dann stellen Sie sicher, dass sie Niemals(!!!) den privaten Schlüssel mit exportieren und versenden! Andernfalls ist Ihr Zertifikat kompromittiert! Verwenden Sie wo möglich den automatischen Zertifikatsaustausch.
Wichtiger Hinweis: Es wird empfohlen, eine Sicherungskopie der eigenen Zertifikate zu erzeugen und sicher zu verwahren, um nach einem Systemausfall die eigenen Zertifikate wiederherstellen zu können. Das Anfertigen eines "Nachschlüssels", also das Herstellen des passenden privaten Schlüssels zu einem vorhandenen öffentlichen Schlüssel, nachdem der private Schlüssel verloren gegangen ist, ist prinzipiell nicht möglich!
Eigenes Zertifikat importieren
Ein eigenes Zertifikat kann man nur importieren, wenn es vorher mit einem vollständigen Export, einschließlich privatem Schlüssel, exportiert wurde. Mögliche Situationen sind die Übertragung des Zertifikats vom Test-System zum Produktiv-System oder zum Standby-System, die Wiederherstellung der eigenen Zertifikate nach einem Systemausfall oder der Import eines Schlüssels aus OpenSSH.
Wichtiger Hinweis: Ein eigenes Zertifikat erhalten Sie niemals von einem Kommunikationspartner. Falls doch, wäre es kompromittiert und darf nicht verwendet werden. Die folgende Abbildung zeigt den Dialog zum Importieren eines eigenen Zertifikats. Das Zertifikat wird entweder im PEM-Format in das Textfeld kopiert oder als CER-Datei direkt in den Dialog gezogen. Falls notwendig, kann beim Import auch ein Passwort angegeben werden.
Import eines SSH-Schlüsselpaares als lokales Zertifikat
Ein OpenSSH-Schlüssel ist kein vollständiges Zertifikat. Es fehlt die Zuordnung einer Adresse zum Schlüssel. Da die Partnerverwaltung nicht mit einzelnen Schlüsselpaaren umgehen kann, sondern nur mit Zertifikaten, die auch einen Namen bzw. eine Adresse enthalten, muss beim Import eines SSH-Schlüssels ein Name zugeordnet werden. Dieser Name muss in das Eingabefeld "SSH Common Name" (1) eingetragen werden. Dann wird zu dem SSH-Schlüssel ein Zertifikat erzeugt und der SSH Common Name wird als Common Name (CN=...) in dieses Zertifikat eingetragen.
Let's Encrypt/ACME/Certbot
Um das Ansprechen von Lobster Integration per HTTPS zu ermöglichen, benötigen Sie ein Zertifikat. Siehe Abschnitt Hinzufügen eines HTTPS-Listeners.
Let’s Encrypt (https://letsencrypt.org/docs/) ist eine kostenfreie Zertifizierungsstelle (CA, Certificate Authority), über die Lobster Integration automatisiert entsprechende Zertifikate erhalten kann. Diese werden dann auch automatisch erneuert, wenn sie abgelaufen sind.
Lobster Integration verwendet dazu intern das ACME-Protokoll und den Certbot Client. Die entsprechenden Komponenten sind im Standard enthalten und müssen lediglich konfiguriert werden, wie im folgenden beschrieben.
Voraussetzungen
Der CertificateExchangeService muss aktiv sein (./etc/factory.xml, siehe dort).
Die Konfigurationsdatei ./etc/cex.xml muss angepasst werden (siehe unten).
Lobster Integration muss öffentlich erreichbar sein (Port 80 und 443 müssen offen sein).
forceSSL darf nicht aktiv sein, da sonst kein Zertifikat generiert werden kann! Hierzu müssen zwei Dateien angepasst werden.
./etc/webdefault.xml - Diesen Part wie ersichtlich in Kommentar setzen.
./etc/startup.xml - Den Parameter auf false setzen.
Anpassen der Konfigurationsdatei ./etc/cex.xml
Bei einer Installation ab Lobster Integration 4.5 befindet sich bereits ein vorbereiteter Block für das Hinzufügen von Certbot Handlern in der Konfigurationsdatei. Ändern Sie dort zur "Aktivierung" die Tags NoCall zu Call (die identische Änderung beim schließenden Tag nicht vergessen, sonst endet der Start des Systems mit einem Fehler). Wichtiger Hinweis: Sie können die Vorlage unten kopieren, aber bitte achten Sie darauf, dass die unten genannten Zeilen angepasst wurden. Andernfalls könnte es Probleme mit der Authentifizierung geben!
Folgende Stellen müssen angepasst werden:
|
Parameter |
Zeile in Beispiel |
Beschreibung |
|
mailSenderAddress |
9 |
E-Mail-Sender-Adresse. |
|
handlerName |
22 |
Dieser wird später in den Notizen der Zertifikatsübersicht zu sehen sein. |
|
accountContact |
32 |
Kontakt-E-Mail-Adresse. Wird von Let's Encrypt benötigt und ist immer anzugeben. |
|
addDomain |
55 |
Die öffentliche Adresse von Lobster Integration. |
Optional:
|
Parameter |
Zeile in Beispiel |
Beschreibung |
|
certbotURL |
31 |
Hier kann auch die Staging Environment mit "acme://letsencrypt.org/staging" angegeben werden. Dies hat den Vorteil, dass es bei zu vielen fehlgeschlagenen Authorization Requests keine Wartezeit gibt. Mehr Informationen dazu finden Sie unter https://letsencrypt.org/docs/staging-environment/. |
<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE Configure PUBLIC "-//Lobster//DTD Configure 1.0//EN" "http://www.lobster.de/dtd/configure_1_3.dtd"><Configure class="com.ebd.hub.services.certexchange.CertificateExchangeService"> <!-- Name of the DB alias to be used for internal data --> <Set name="dBAlias">hub</Set> <Set name="mailSenderAddress">mail@example.com</Set> <!-- Certbot Handler configuration for the management of certificates that should be signed by an ACME supporting CA, e.g. Let's Encrypt --> <!-- Change NoCall to Call (don't forget the </NoCall> to enable this --> <Call name="addCertbotHandler"> <Arg><New class="com.ebd.hub.services.certexchange.CertbotHandler"> <!-- Name of the handler. Certificates handled by this handler will have the name in the keystore notes and can be used as search term in TLS-configurations --> <Set name="handlerName">example.com</Set> <!-- Used as contact for ACME-server account registrations --> <!-- The URL of the ACME endpoint. The URL in this sample is the staging server, the URL of the production server is acme://letsencrypt.org --> <Set name="certbotURL">acme://letsencrypt.org/</Set> <Set name="accountContact">mailto:mail@example.com</Set> <!-- Adds a certificate algorithm to be handled. This will lead to the creation of a keypair and finally a CA-signed certificate. --> <Call name="addCertificateAlgorithm"> <!-- the non-EC algorithm --> <Arg>RSA</Arg> <!-- key size in bits --> <Arg type="int">2048</Arg> </Call> <Call name="addCertificateAlgorithm"> <!-- the EC algorithm --> <Arg>ECDSA</Arg> <!-- the curve name --> <Arg type="String">secp256r1</Arg> </Call> <!-- Adds a domain the certificate should contain as common name or alternate subject name. --> <Call name="addDomain"> <Arg>example.com</Arg> </Call> <!-- Number of days a certificate should be valid. This is part of the request to the CA and its support is CA-dependent. It might be ignored or denied, leading to an error. In that case setting it to 0 will omit adding it to the request --> <Set name="requestedCertificateValidityDays">0</Set> <!-- (change NoSet to Set to activate this setting) Number of days before expiry a renewal request should be sent to the CA --> <Set name="daysBeforeExpireRefresh">10</Set> </New></Arg> </Call> </Configure>HTTPS Listener aktivieren/Zertifikat angeben
Wurde der Integration Server neu gestartet, werden nach ein paar Minuten die neu generierten Zertifikate in der Zertifikatsübersicht (eigene Zertifikate) angezeigt. Diese sind mit einer Notiz, dem Handler Name, gekennzeichnet.
Um letztendlich das neue Let's-Encrypt-Zertifikat zu verwenden, müssen Sie den HTTPS-Listener aktivieren und die Konfigurationsdatei ./etc/hub.xml anpassen, siehe folgendes Beispiel:
Wichtiger Hinweis: Es kann sowohl der CN (Common Name), als auch das ksnote-Kürzel verwendet werden. Letzteres fungiert als eine Art Alias und verwendet die Zertifikats-Notiz für eine eindeutige Zuordnung.
Verwendung auf DMZ-Server
Da ein DMZ-Server in den meisten Fällen die Schnittstelle nach außen bzw. von außen nach innen ist, muss der Certbot dort installiert werden. Zusätzlich zu den Standard-Änderungen der Konfigurationsdateien ./etc/factory.xml, ./etc/cex.xml und ./etc/hub.xml (wie oben beschrieben), muss folgendes angepasst werden.
./etc/cex.xml: Hier muss für den Parameter dbAlias der Wert dmzcommauth eingetragen werden.
./etc/auth_dmz.xml: Der Parameter <Set name="localDbFile">dmz/hsql/cacheHsql</Set> darf nicht aktiv und muss auskommentiert sein.
Error Handling
Treten Fehler auf, findet man diese in den folgenden Logs.
./logs/console.txt
Startet Lobster Integration nicht mehr, liegt dies meist an fehlerhaften Konfigurationsdateien. Bitte die Konfigurationsdateien ./etc/cex.xml, ./etc/hub.xml und ./etc/factory.xml überprüfen../logs/services/message.log
Um die Ergebnisse einzugrenzen, kann nach CERTBOTHANDLER gesucht werden. Das liefert Ihnen eine grobe Übersicht, ob ein CSR (Certificate Signing Request) erfolgreich war../logs/services/error.log
Schlägt die Authentifizierung fehl, ist dies hier zu erkennen.
Partner-Zertifikate
Die ID des Zertifikats und den Common Name (CN) finden Sie über einen Doppelklick auf das Zertifikat. Dabei ist die ID nicht mit der Seriennummer zu verwechseln.
Ein Partner-Zertifikat enthält nur den öffentlichen Schlüssel des Kommunikationspartners und das Zertifikat, dass zu dem technischen Schlüssel die Informationen über den Gültigkeitszeitraum und den Inhaber zuordnet. Üblicherweise erhalten Sie ein Partner-Zertifikat vom Partner, z. B per E-Mail entweder im .pem-Format oder als Datei.
Hier können Partner-Zertifikate verwaltet (importiert, betrachtet und zurückgezogen) werden. Hinweis: Partner-Zertifikate können nicht erzeugt werden, sondern der Partner muss sein Zertifikat zusammen mit seinem öffentlichen Schlüssel exportieren und Ihnen zur Verfügung stellen. Jedes Partner-Zertifikat ist einem konkreten Partner zugeordnet und kann auch nur für dessen Kanäle verwendet werden. Da Partner-Zertifikate nur den öffentlichen Schlüssel enthalten, aber keinen privaten Schlüssel, können sie bedenkenlos weitergegeben werden. Es ist aber nicht möglich, ein Partner-Zertifikat als eigenes Zertifikat zu importieren.
Partner-Zertifikat importieren
Um ein Partner-Zertifikat zu importieren, drücken Sie zuerst auf Button Zertifikat importieren (1). Danach können Sie entweder den Inhalt einer Zertifikats-Datei im .pem-Format direkt in das Fenster kopieren (wie im Screenshot gezeigt) oder alternativ eine Datei im .cer-Format in das Fenster ziehen.
Authentifizierung durch Client-Zertifikat
Als Voraussetzung muss in der Konfigurationsdatei ./etc/hub.xml ein HTTPS Listener definiert sein.
Die Protokolle HTTPS, AS2 über HTTPS und OFTP2.0 über TLS verwenden auf der Transportschicht das SSL- bzw. TLS-Protokoll, um durch Verschlüsselung einen sicheren Kanal aufzubauen. Benutzernamen und Passwörter, die innerhalb dieses Kanals gesendet werden, sind vor einer Kompromittierung wesentlich besser geschützt, als bei einem "Klartext-Kanal" (z. B. HTTP). Es kann aber vorkommen, dass einem Kommunikationspartner diese Sicherheit nicht ausreicht und dass er daher entweder zusätzlich oder anstelle des Passwortes fordert, dass sich der Client mit einem Zertifikat ausweist. Dieses Zertifikat wird Client-Zertifikat genannt, weil es die Identität des Clients beweist, nicht des Servers oder Dienstes. Es ist auf Client-Seite ein eigenes Zertifikat. Das bedeutet, nur der Client kann auf den privaten Schlüssel zugreifen.
Lobster Integration unterstützt Client-Zertifikate für HTTPS, AS2 und OFTP, wenn der Kommunikationspartner die Authentifikation mit einem Client-Zertifikat fordert. Es kann auch gefordert werden, dass der Partner sich mit seinem Client-Zertifikat anmeldet. Siehe Abschnitt "Eigene Zertifikate".
Ein Sonderfall ist OFTP via TLS. Hier schreibt die Spezifikation eine gegenseitige Identifizierung der Partner über ein Zertifikat vor. Dieses Zertifikat ist auf einer Seite also Server- und Client-Zertifikat gleichzeitig, abhängig von der Richtung des Verbindungsaufbaus. Bei ausgehenden Verbindungen ist es das Client-Zertifikat.
Bei allen ausgehenden Verbindungen der Protokolle AS2 über HTTPS, OFTP über TLS und HTTPS wird als Client-Zertifikat das eigene Zertifikat verwendet, das dem Partnerkanal zugeordnet ist. Damit ist es dasselbe Zertifikat, das auch zur Signierung von Nachrichten/Dateien verwendet wird. Bei AS2 kann für Verschlüsselung und Signierung jeweils ein unterschiedliches eigenes Zertifikat verwendet werden.
Eine Authentifizierung durch Client-Zertifikat ist nur über einen Partner-Kanal möglich und nicht über einen Antwortweg allein.
Siehe auch Abschnitt Lobster Integration als HTTPS-Client.