Zertifikate

Lobster Integration nutzt Zertifikate an verschiedenen Stellen für die verschlüsselte Kommunikation. Diese verwalten Sie hier zentral.

Navigieren Sie zu Verwaltung > Partner > Zertifikate.

Hinweis zum Aufbau dieses Artikels

Die Abschnitte Begriffe und Konzepte bis Signierung enthalten Hintergrundwissen zu PKI und X.509. Wenn Sie diese Konzepte kennen, springen Sie direkt zu Eigene Zertifikate.

Begriffe und Konzepte

Die Begriffe in diesem Abschnitt beziehen sich auf die Public-Key-Infrastruktur (PKI). PKI basiert auf dem Standard X.509 der internationalen Fernmeldeunion (ITU-T). Dieser Abschnitt setzt folgende Grundbegriffe als bekannt voraus:

• asymmetrische Verschlüsselung

• öffentlicher Schlüssel, privater Schlüssel

• Zertifikat, Zertifizierungsstelle (Certificate Authority, CA)

• Fingerprint, Signatur

• Für eine Einführung in diese Themen gibt es viele frei zugängliche Dokumente im Internet.

Digitales Zertifikat

Ein digitales Zertifikat bezieht sich auf ein asymmetrisches Schlüsselpaar. Es enthält strukturierte Daten. Diese Daten verbinden den technischen Schlüssel mit der Identität des Eigentümers. Der Eigentümer kann eine Person, Organisation, Firma oder ein IT-System sein. Jedes Zertifikat enthält einen Gültigkeitszeitraum und eine Adresse mit dem Inhaber. Ein wichtiger Bestandteil dieser Adresse ist der Common Name (CN).

Ein Zertifikatsobjekt umfasst ein digitales Zertifikat und einen oder beide Schlüssel.

Partnerzertifikat

Ein Partnerzertifikat enthält das digitale Zertifikat und nur den öffentlichen Schlüssel. Den privaten Schlüssel enthält es nicht. Die Begriffe Partnerzertifikat und öffentlicher Schlüssel werden oft gleichbedeutend verwendet.

Eigenes Zertifikat

Ein eigenes Zertifikat enthält das digitale Zertifikat sowie beide Schlüssel: den öffentlichen und den privaten.

Zertifikats-Seriennummer

Üblicherweise installieren Sie auf dem Partnersystem ein Partnerzertifikat. Dieses enthält nur den öffentlichen Schlüssel. So ordnen Sie das Partnerzertifikat eindeutig Ihrem eigenen Zertifikat zu. Dafür dient die Zertifikats-Seriennummer. Lobster Integration stellt diese Seriennummer einheitlich als dezimale Ganzzahl dar.

Signiert eine offizielle Zertifizierungsstelle das Zertifikat, prüfen Systeme die Gültigkeit online. Auch dann existieren privater und öffentlicher Schlüssel. Das Partnerzertifikat tauschen Sie sicher über das Netz aus. Den privaten Schlüssel dürfen Sie dabei nicht mitschicken. Die Signierung schützt das Partnerzertifikat vor Manipulation. Senden Sie dem Partner das Partnerzertifikat, zum Beispiel per E-Mail. Er prüft dann anhand des Fingerprints oder der Prüfsumme, ob das Zertifikat unverändert angekommen ist.

Ziele der X.509-Technologie

X.509 ermöglicht zwei Sicherheitsfunktionen: Datenverschlüsselung und digitale Signierung.

Jedes Schlüsselpaar entsteht genau einmal. Die Zertifikatsinformationen sind fest damit verknüpft. Nachträglich lassen sich weder Schlüssel noch Beschreibungen ändern. Daten, die Sie mit einem Schlüssel verschlüsseln, entschlüsseln Sie nur mit dem anderen Schlüssel.

Den privaten Schlüssel kennt nur der Zertifikatsinhaber. Den öffentlichen Schlüssel gibt er an Kommunikationspartner weiter.

Gerät der private Schlüssel in fremde Hände, ist die Integrität gebrochen. Manipulierte Daten lassen sich nicht mehr entschlüsseln. Ein Angreifer kann Daten zwar abfangen. Er kann sie aber nicht entschlüsseln, manipulieren und neu verschlüsseln. Dazu bräuchte er beide Schlüssel. Nur der Zertifikatsinhaber besitzt beide.

Digitale Zertifikate schützen damit Vertraulichkeit, Authentizität und Integrität der Daten. Das gilt besonders während der Übertragung über das Netz.

Verschlüsselung

Für eine sichere Übertragung verschlüsseln Sie die Daten mit dem öffentlichen Schlüssel des Partners. Das entspricht dem Partnerzertifikat.

Nur der Partner entschlüsselt die Daten. Er nutzt dafür seinen privaten Schlüssel.

Soll der Partner Ihnen verschlüsselte Daten senden, muss er sie mit Ihrem öffentlichen Schlüssel verschlüsseln. Nur Sie können diese Daten dann mit Ihrem privaten Schlüssel entschlüsseln.

Der Partner benötigt dazu Ihren öffentlichen Schlüssel. Sie können ihn auf zwei Wegen übertragen: als exportiertes eigenes Zertifikat per E-Mail oder beim Verbindungsaufbau online. Importieren Sie das Partnerzertifikat, das Sie vom Partner erhalten. Der Partner installiert Ihr exportiertes Zertifikat bei sich als Partnerzertifikat.

Bei einem sicheren Webserver erhalten Clients das Zertifikat und den öffentlichen Schlüssel automatisch. Das geschieht beim Verbindungsaufbau im TLS-Handshake. Der Server kennt die Clients dabei nicht vorab.

Signierung

Eine Signierung ist eine zusätzliche Verschlüsselung. Senden Sie Daten signiert und verschlüsselt, läuft der Prozess in zwei Schritten ab:

1. Verschlüsseln Sie die Daten mit dem öffentlichen Schlüssel des Partners.

2. Bilden Sie über die Daten einen Hash (eine Prüfsumme). Verschlüsseln Sie diesen Hash mit Ihrem privaten Schlüssel. Das ist die Signierung.

Der Partner entschlüsselt zuerst die Signatur. Dafür nutzt er Ihren öffentlichen Schlüssel. Er prüft die Prüfsumme. Stimmt sie, entschlüsselt er die Daten mit seinem privaten Schlüssel.

Senden Sie die Daten nur signiert, gehen sie im Klartext über das Netz. Die Signierung verschlüsselt nur den Hash. Sie verschlüsselt nicht die Daten selbst. Die Prüfung der Signatur bestätigt aber die Echtheit des Absenders. Denn nur der Inhaber des privaten Schlüssels kann die Prüfsumme korrekt verschlüsseln.

Selbstsigniertes oder CA-beglaubigtes Zertifikat?

Wann ein CA-Zertifikat erforderlich ist

Bei Browser-Anwendungen kommunizieren viele anonyme Clients mit dem Server. Für diese Anwendungen beglaubigt eine offizielle Zertifizierungsstelle (Certificate Authority, CA) das Zertifikat. Sie bestätigt damit, dass der Server es berechtigt verwendet.

Vertrauenswürdigkeit und Validierung

Ein Zertifikat gilt als vertrauenswürdig, wenn eine anerkannte CA wie Let's Encrypt oder DigiCert es signiert hat. Der Client prüft dabei die Zertifikatskette. Je nach CA prüft er nur das Zertifikat selbst. Ziel der Prüfung: Die Kette muss zu einer Root-CA führen, die im Trust-Store des Clients hinterlegt ist.

Ein selbstsigniertes Zertifikat oder eine unvollständige Zertifikatskette schränkt die Prüfung ein. Der Client kann die Identität des Servers dann nicht sicher verifizieren. Je nach System führt das zu Warnungen oder abgelehnten Verbindungen. Für den Client besteht das Risiko, eine Verbindung zu einem falschen oder manipulierten System aufzubauen.

Prüfen Sie außerdem, ob der Hostname, den der Client aufruft, im Zertifikat hinterlegt ist. Der Hostname muss im Feld Subject Alternative Name (SAN) stehen oder durch Wildcards korrekt abgebildet sein. Passt der Hostname nicht, schlägt die TLS-Prüfung fehl. Dann ist nicht sichergestellt, dass das Zertifikat zu genau diesem Zielsystem gehört.

Selbstsignierte Zertifikate in der B2B-Kommunikation

In der B2B-Kommunikation (Business-to-Business) sind selbstsignierte Zertifikate zulässig. Zwischen zwei Geschäftspartnern ist keine dritte Instanz zur Beglaubigung nötig.

Jedes in der Partnerverwaltung erzeugte eigene Zertifikat ist selbstsigniert. Es kann aber beglaubigt werden. Dazu erzeugen Sie aus dem eigenen Zertifikat einen Certificate Signing Request (CSR). Diese CSR-Datei senden Sie an eine Zertifizierungsstelle. Öffnen Sie dazu das Zertifikat mit einem Doppelklick (1).

Klicken Sie auf Erzeuge CSR (2). In einem weiteren Dialog kopieren Sie den CSR. Senden Sie ihn dann an die Zertifizierungs-Stelle.

Importieren Sie die Antwort der Zertifizierungsstelle (Certificate Signing Request Response) mit Importiere CSR (3). Eine Beglaubigung über eine öffentliche Zertifizierungsstelle ist kostenpflichtig. Für die meisten Anwendungen mit Lobster Integration ist sie nicht erforderlich.

Die Reihenfolge der einzelnen Bestandteile des CSRs:

• CSR Response

• Issuer

• Root

Haben Sie die Dateien nur einzeln, führen Sie sie im Editor in dieser Reihenfolge in einer Datei zusammen.

Austausch eines Partnerzertifikats

Wichtig

Tauschen Sie mit Partnern ausschließlich den öffentlichen Schlüssel aus, und niemals den privaten. Zertifikate haben eine begrenzte Gültigkeitsdauer; nach Ablauf ist keine Kommunikation mehr möglich.

Hinweis zum PEM-Format

Das PEM-Format ist eine Base64-Zeichenkette zwischen -----BEGIN CERTIFICATE----- und -----END CERTIFICATE-----.

Warnung

Enthält die PEM-Datei zusätzlich einen Abschnitt von -----BEGIN RSA PRIVATE KEY----- bis -----END RSA PRIVATE KEY-----, ist das der private Schlüssel. Geben Sie diesen niemals weiter.

Java Cryptography Extension (JCE)

Lobster Integration erfordert Kryptografie mit unbegrenzter Schlüssellänge. Diese Richtlinie ist ab Java 8 Update 161 sowie allen neueren Java-Versionen standardmäßig aktiviert, sodass eine manuelle Installation zusätzlicher Erweiterungen nicht mehr notwendig ist.

Fehlt die erforderliche Kryptografie-Konfiguration, startet der Integration Server nicht. Die Fehlermeldung lautet:

The Java Virtual Machine can't handle strong cryptography

Eigene Zertifikate

Hier erstellen, importieren, exportieren, betrachten und ziehen Sie eigene Zertifikate zurück. Außerdem erzeugen Sie einen Certificate Signing Request (CSR). Über das Kontextmenü erstellen Sie einen CSV-Report. Dieser zeigt, in welchen Kanälen ein Zertifikat verwendet wird.

Die ID des Zertifikats und den Common Name (CN) finden Sie über (1). Verwechseln Sie die ID nicht mit der Seriennummer.

(1) und (2) Zertifikat zurückziehen: Zertifikate werden nach Ablauf ihrer Gültigkeit automatisch ungültig. Besteht vor Ablauf der Verdacht, dass ein Zertifikat kompromittiert ist, deaktivieren Sie es lokal über (1) und (2) mit Zertifikat zurückziehen. Dazu benötigen Sie Admin-Rechte. Das Zertifikat wird dabei nicht gelöscht. Andernfalls wären verschlüsselte oder signierte Daten nicht mehr lesbar.

Wichtig

Das Zurückziehen in Lobster Integration ist nur ein lokales Deaktivieren des Zertifikats innerhalb der Plattform. Es erfolgt kein offizieller Eintrag in einer Zertifikats-Sperrliste (Certificate Revocation List, CRL). Das bedeutet:

• Ein lokal deaktiviertes Zertifikat aktivieren Sie jederzeit über (1) wieder. Lokal deaktivierte Zertifikate sind in der Übersicht standardmäßig ausgeblendet. Passen Sie den Filter an, um sie anzuzeigen.

• Steht das Zertifikat zusätzlich auf der offiziellen CRL einer Zertifizierungs-Stelle, ist eine lokale Reaktivierung technisch möglich. Kommunikationspartner, die die CRL prüfen, lehnen das Zertifikat aber weiterhin ab.

(3) Verwendungszweck (Signierung, Verschlüsselung, TLS Client, TLS Server): Setzt die "usage flags". Sie legen fest, wofür das Zertifikat verwendet werden kann.

(4) Verwendungszweck (Vorgabe muss unterstützt werden): Diese Checkboxen setzen für die Einstellungen aus (3) sogenannte "critical flags". Damit fordern Sie, dass der Kommunikationspartner beim Einspielen des Zertifikats prüft, ob er die Einstellungen aus (3) unterstützt. Unterstützt er sie nicht, verwirft er das Zertifikat. Verwenden Sie die hier gezeigten Default-Einstellungen in (4). Das verhindert, dass Ihr Zertifikat abgelehnt wird. Diese Einstellungen sind für nahezu alle Fälle korrekt. Ändern Sie sie nur, wenn Sie den Grund kennen.

(5) Zertifikat/SSH-Schlüssel importieren: Siehe Eigenes Zertifikat importieren und Import eines SSH-Schlüsselpaares als lokales Zertifikat.

Let's Encrypt

Siehe Abschnitt Let's Encrypt/ACME/Certbot (kostenfreie und automatische Zertifikate von einer Certificate Authority erhalten und erneuern).

Eigenes Zertifikat erzeugen

Der folgende Dialog erscheint nach Klick auf den Plus-Button unten rechts (1). Er zeigt die Erzeugung von selbstsignierten Zertifikaten im X.509-Standard. Eine Beschreibung der Felder entnehmen Sie dem X.509-Standard.

Bei der Erzeugung eines eigenen Zertifikats für OFTP2 ordnen Sie dem Zertifikat als Eigenschaft auch eine ODETTE-ID zu.

Hinweis

Wählen Sie für die Option Schlüsselmaterial den Wert Internal. Das bedeutet, dass es sich um ein Plattformzertifikat handelt, nicht um ein Zertifikat aus einem Vault.

Ein eigenes Zertifikat exportieren Sie über das Kontextmenü. Dabei wählen Sie unter verschiedenen Formaten:

• nur das Zertifikat

• nur den privaten Schlüssel

• Zertifikat und privater Schlüssel

Wichtige Hinweise

• Exportieren und versenden Sie ein Zertifikat per E-Mail, schließen Sie den privaten Schlüssel niemals ein. Andernfalls ist das Zertifikat kompromittiert. Verwenden Sie, wo möglich, den automatischen Zertifikatsaustausch.

• Erstellen Sie eine Sicherungskopie Ihrer eigenen Zertifikate und verwahren Sie sie sicher. Nach einem Systemausfall stellen Sie so die Zertifikate wieder her. Das Erzeugen eines passenden privaten Schlüssels zu einem vorhandenen öffentlichen Schlüssel ist prinzipiell nicht möglich.

Eigenes Zertifikat importieren

Ein eigenes Zertifikat importieren Sie nur, wenn es vorher mit einem vollständigen Export (einschließlich privatem Schlüssel) exportiert wurde. Typische Situationen:

• Übertragung vom Testsystem zum Produktivsystem oder Stand-by-System

• Wiederherstellung nach einem Systemausfall

• Import eines Schlüssels aus OpenSSH

Wichtig

Ein eigenes Zertifikat erhalten Sie niemals von einem Kommunikationspartner. Trifft das doch ein, ist das Zertifikat kompromittiert und darf nicht verwendet werden.

Der folgende Dialog zeigt den Import-Dialog. Kopieren Sie das Zertifikat im PEM-Format in das Textfeld oder ziehen Sie eine CER-Datei direkt in den Dialog. Bei Bedarf geben Sie beim Import ein Passwort an.

Import eines SSH-Schlüsselpaares als lokales Zertifikat

Ein OpenSSH-Schlüssel ist kein vollständiges Zertifikat. Ihm fehlt die Zuordnung einer Adresse. Die Partnerverwaltung verarbeitet nur Zertifikate mit Name und Adresse. Beim Import eines SSH-Schlüssels ordnen Sie daher einen Namen zu. Tragen Sie diesen Namen in das Feld SSH Common Name (1) ein. Lobster Integration erzeugt daraus ein Zertifikat. Der SSH Common Name wird als Common Name (CN=...) in dieses Zertifikat eingetragen.

Let's Encrypt/ACME/Certbot

Um Lobster Integration per HTTPS anzusprechen, benötigen Sie ein Zertifikat. Siehe Hinzufügen eines HTTPS-Listeners.

Let's Encrypt (https://letsencrypt.org/docs/) ist eine kostenfreie Zertifizierungsstelle (CA). Über Let's Encrypt erhält Lobster Integration automatisch Zertifikate. Diese werden auch automatisch erneuert, wenn sie abgelaufen sind.

Lobster Integration nutzt dazu intern das ACME-Protokoll und den Certbot-Client. Die Komponenten sind im Standard enthalten. Sie müssen sie nur konfigurieren.

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. Andernfalls lässt sich kein Zertifikat generieren. Passen Sie dazu zwei Dateien an:

  • ./etc/webdefault.xml – Setzen Sie diesen Part wie ersichtlich in Kommentar.

    

  • ./etc/startup.xml – Setzen Sie den Parameter auf false.

    

Anpassen der Konfigurationsdatei ./etc/cex.xml

Ab Lobster Integration 4.5 enthält die Konfigurationsdatei bereits einen vorbereiteten Block für Certbot-Handler. Ändern Sie zur Aktivierung die Tags NoCall zu Call. Vergessen Sie dabei nicht das schließende Tag. Sonst startet das System nicht.

Wichtiger Hinweis

Kopieren Sie die Vorlage unten, passen Sie aber alle in der Tabelle aufgeführten Zeilen an. Andernfalls kann es Probleme mit der Authentifizierung geben.

Passen Sie folgende Stellen an:

Optional:

<?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">
    <Set name="dBAlias">hub</Set>
    <Set name="mailSenderAddress">mail@example.com</Set>
    <Call name="addCertbotHandler">
        <Arg><New class="com.ebd.hub.services.certexchange.CertbotHandler">
            <Set name="handlerName">example.com</Set>
            <Set name="certbotURL">acme://letsencrypt.org/</Set>
            <Set name="accountContact">mailto:mail@example.com</Set>
            <Call name="addCertificateAlgorithm">
                <Arg>RSA</Arg>
                <Arg type="int">2048</Arg>
            </Call>
            <Call name="addCertificateAlgorithm">
                <Arg>ECDSA</Arg>
                <Arg type="String">secp256r1</Arg>
            </Call>
            <Call name="addDomain">
                <Arg>example.com</Arg>
            </Call>
            <Set name="requestedCertificateValidityDays">0</Set>
            <Set name="daysBeforeExpireRefresh">10</Set>
        </New></Arg>
    </Call>
</Configure>

HTTPS-Listener aktivieren und Zertifikat angeben

Nach einem Neustart des Integration Servers erscheinen die neu generierten Zertifikate nach wenigen Minuten in der Zertifikatsübersicht (eigene Zertifikate). Sie sind mit einer Notiz (dem Handler-Namen) gekennzeichnet.

Um das neue Let's-Encrypt-Zertifikat zu verwenden, aktivieren Sie den HTTPS-Listener. Passen Sie die Konfigurationsdatei ./etc/hub.xml an (siehe folgendes Beispiel):

Wichtig

Verwenden Sie entweder den CN (Common Name) oder das ksnote-Kürzel. Das Kürzel fungiert als Alias. Es nutzt die Zertifikats-Notiz für eine eindeutige Zuordnung.

Verwendung auf DMZ-Server

Ein DMZ-Server ist in den meisten Fällen die Schnittstelle nach außen. Installieren Sie den Certbot dort. Zusätzlich zu den Standardänderungen der Konfigurationsdateien ./etc/factory.xml, ./etc/cex.xml und ./etc/hub.xml passen Sie Folgendes an:

• ./etc/cex.xml: Tragen Sie für den Parameter dbAlias den Wert dmzcommauth ein.

  

• ./etc/auth_dmz.xml: Der Parameter <Set name="localDbFile">dmz/hsql/cacheHsql</Set> darf nicht aktiv sein. Kommentieren Sie ihn aus.

Fehlerbehandlung

Treten Fehler auf, finden Sie diese in folgenden Logs:

• ./logs/console.txt – Startet Lobster Integration nicht mehr, liegt das meist an fehlerhaften Konfigurationsdateien. Prüfen Sie ./etc/cex.xml, ./etc/hub.xml und ./etc/factory.xml.

• ./logs/services/message.log – Suchen Sie nach CERTBOTHANDLER. Das liefert eine Übersicht, ob ein CSR erfolgreich war.

• ./logs/services/error.log – Hier erkennen Sie fehlgeschlagene Authentifizierungen.

Partnerzertifikate

Die ID des Zertifikats und den Common Name (CN) finden Sie per Doppelklick auf das Zertifikat. Verwechseln Sie die ID nicht mit der Seriennummer.

Ein Partnerzertifikat enthält nur den öffentlichen Schlüssel des Kommunikationspartners. Es enthält auch das Zertifikat, das dem Schlüssel Informationen über den Gültigkeitszeitraum und den Inhaber zuordnet. Üblicherweise erhalten Sie ein Partnerzertifikat vom Partner per E-Mail, im .pem-Format oder als Datei.

Hier verwalten Sie Partnerzertifikate: importieren, betrachten und zurückziehen.

Hinweis

Partnerzertifikate erzeugen Sie nicht selbst. Der Partner exportiert sein Zertifikat mit dem öffentlichen Schlüssel und stellt es Ihnen bereit. Jedes Partnerzertifikat ist einem konkreten Partner zugeordnet. Es ist nur für dessen Kanäle verwendbar. Da Partnerzertifikate nur den öffentlichen Schlüssel enthalten, geben Sie sie bedenkenlos weiter. Ein Partnerzertifikat als eigenes Zertifikat importieren ist nicht möglich.

Partnerzertifikat importieren

Klicken Sie auf Zertifikat importieren (1). Danach kopieren Sie entweder den Inhalt einer Zertifikatsdatei im .pem-Format direkt in das Fenster. Alternativ ziehen Sie eine Datei im .cer-Format in das Fenster.

Authentifizierung durch Client-Zertifikat

Zunächst konfigurieren Sie in der Konfigurationsdatei ./etc/hub.xml einen HTTPS-Listener.

Die Protokolle HTTPS, AS2 über HTTPS und OFTP2.0 über TLS nutzen auf der Transportschicht das TLS-Protokoll. Das TLS-Protokoll baut einen sicheren Kanal durch Verschlüsselung auf. Benutzernamen und Passwörter innerhalb dieses Kanals sind deutlich besser geschützt als bei einem unverschlüsselten Kanal (zum Beispiel HTTP). Manche Kommunikationspartner fordern aber zusätzliche Sicherheit. Sie fordern, dass sich der Client mit einem Zertifikat ausweist. Dieses Zertifikat heißt Client-Zertifikat, weil es die Identität des Clients beweist, nicht die des Servers. Auf Client-Seite ist es ein eigenes Zertifikat. Nur der Client hat Zugriff auf den privaten Schlüssel.

Lobster Integration unterstützt Client-Zertifikate für HTTPS, AS2 und OFTP, wenn der Kommunikationspartner die Authentifizierung per Client-Zertifikat fordert. Sie können auch fordern, dass sich der Partner mit seinem Client-Zertifikat anmeldet. Siehe Abschnitt Eigene Zertifikate.

Ein Sonderfall ist OFTP via TLS. Die Spezifikation schreibt hier eine gegenseitige Identifizierung per Zertifikat vor. Das Zertifikat ist auf einer Seite gleichzeitig Server- und Client-Zertifikat, abhängig von der Verbindungsrichtung. Bei ausgehenden Verbindungen ist es das Client-Zertifikat.

Bei allen ausgehenden Verbindungen über AS2 über HTTPS, OFTP über TLS und HTTPS wird das eigene Zertifikat des Partnerkanals als Client-Zertifikat verwendet. Es ist dasselbe Zertifikat wie das zur Signierung von Nachrichten und Dateien. Bei AS2 verwenden Sie für Verschlüsselung und Signierung je ein unterschiedliches eigenes Zertifikat.

Eine Authentifizierung durch Client-Zertifikat ist nur über einen Partnerkanal möglich, nicht über einen Antwortweg allein.

Siehe auch: Lobster Integration als HTTPS-Client.

Vault-Zertifikate

Sie können einen Vault-Anbieter nutzen, um Ihre Zertifikate zu speichern und in der Lobster Data Platform zu verwenden.

Azure

(1) Wählen Sie den Wert External. Hinweis: Das bedeutet, dass es sich um ein Vault-Zertifikat handelt, nicht um ein Plattformzertifikat.

(2) Wählen Sie Ihren Vault-Anbieter-Alias.

(3) Wählen Sie den Zertifikats-Alias.

(4) Diese Felder sind schreibgeschützt. Sie werden automatisch ausgefüllt.

HashiCorp

HashiCorp funktioniert auf dieselbe Weise. Sie legen aber zwei zusätzliche Felder fest. Mount (1) ist der Pfad, unter dem eine Secrets-Engine aktiviert ist. Stellen Sie sich diesen als Stamm-Namespace oder Laufwerksbuchstaben für eine Kategorie von Secrets vor. Name (2) ist die spezifische Kennung für ein einzelnes Secret innerhalb des Mounts, manchmal auch als Pfad innerhalb eines Mounts bezeichnet. Weitere Informationen finden Sie in der Dokumentation des Herstellers HashiCorp.