AS2 (Kanal-Einstellungen)

Einführung: Eine allgemeine Einführung zu AS2 finden Sie im Abschnitt AS2 mit Lobster_data. Dort ist auch beschrieben, wie die URL des AS2-Services von Lobster_data aufgebaut ist.

Siehe auch: Kanal-Einstellungen allgemein, AS2 (Eingangsagent) und Antwortweg AS2.

Für einen AS2-Kanal muss als Partner-Adresse die URL zum Partner-AS2-Service eingetragen werden, falls ausgehende Daten erlaubt sind. Das Protokoll kann dabei HTTP oder HTTPS sein, denn das AS2-Protokoll wird innerhalb eines HTTP Envelopes transportiert.

Hinweis: Zum Thema Verschlüsselung und Signierung allgemein, sehen Sie sich bitte den Abschnitt Zertifikate an.

(1) Hier kann dem Kanal ein eigenes Zertifikat (mit privatem Schlüssel) zugewiesen werden. Dieses Zertifikat dient dem Entschlüsseln der vom Partner verschlüsselten eingehenden Daten. Wenn unter (3) kein eigenes Zertifikat zugeordnet wurde, dient es zudem dem Signieren ausgehender Daten.

Hinweis: Es kann bei AS2 über HTTPS zusätzlich für die ausgehende HTTPS-Verbindung ein Client-Zertifikat erforderlich sein. Dazu wird ebenfalls das eigene Zertifikat (1) verwendet. Siehe auch Abschnitt Authentifizierung durch Client-Zertifikat. Der externe Server darf für HTTPS ein selbstsigniertes Zertifikat verwenden. Der Import des Server-Zertifikats als Partner-Zertifikat ist nicht erforderlich.

(2) Hier kann dem Kanal ein Partner-Zertifikat, d. h. der öffentliche Teil eines Zertifikats des Kommunikationspartners zugewiesen werden. Dieses Zertifikat dient zum Verschlüsseln der zu sendenden Daten. Wenn unter (3) kein Partner-Zertifikat zugeordnet wurde, dient es zudem der Prüfung der Signatur empfangener Daten.

(3) Siehe (1) und (2).

(4) Gibt an, ob Daten von Lobster_data signiert und/oder verschlüsselt an das Partnersystem gesendet werden. Signiert werden die Daten mit dem in (6) eingestellten Signaturalgorithmus. Verschlüsselt werden die Daten mit dem in (9) eingestellten Verschlüsselungsalgorithmus.

(5) Falls gesetzt, wird der Empfang von nicht signierten bzw. verschlüsselten Daten zurückgewiesen. Achtung: Wenn der Partner verschlüsselt oder signiert sendet, muss ein eigenes Zertifikat zum Entschlüsseln der Daten bzw. ein Partner-Zertifikat zur Prüfung der Signierung trotzdem eingetragen werden, auch wenn die Optionen hier in (5) nicht gesetzt sind. Andernfalls wäre die Nachricht nicht entschlüsselbar bzw. die Signatur nicht prüfbar. Abgelehnt wird die Nachricht dann aber nicht.

(6) Entfernt ein Sicherheits-Attribut der Signatur. Hinweis: Wird nur in seltenen Fällen für alte AS2-Konnektoren benötigt. Hinweis: Siehe auch https://datatracker.ietf.org/doc/html/rfc6211.

(7) Nachrichten in Blöcke unterteilen (CTE). Hinweis: Wird nur in seltenen Fällen für alte AS2-Konnektoren benötigt.

(8) Legt fest, mit welchem Algorithmus von Lobster_data gesendete Daten signiert werden. Die Einstellung wirkt sich nur aus, wenn die Checkbox Signiert senden (4) gesetzt ist.

(9) Legt fest, mit welchem Algorithmus von Lobster_data gesendete Daten verschlüsselt werden. Die Einstellung wirkt sich nur aus, wenn die Checkbox Verschlüsselt senden (4) gesetzt ist.

(10) Hier kann für den Kanal festgelegt werden, wie die Übermittlung der MDN an den Kommunikationspartner erfolgen soll. Lobster_data bietet die folgenden Möglichkeiten.

• Systemeinstellung. Die in der Konfigurationsdatei ./etc/as2.xmlfestgelegte Übermittlung der MDN wird übernommen.

• Synchron. Es wird eine synchrone Übermittlung der MDN verwendet.

• Asynchron. Es wird eine asynchrone Übermittlung der MDN verwendet. Ist in der Konfigurationsdatei ./etc/as2.xml keine URL definiert, muss diese hier im Feld MDN-URL angegeben werden. Ein Eintrag in der Konfigurationsdatei würde folgendermaßen aussehen.

  <Set name="defaultMDNAsynchronousURL">http://100.1.20.45:8080/partner/AS2Retrieve</Set>

(11) Der Algorithmus, mit dem der sogenannte Digest der MDN berechnet wird. Ein Digest ist ein Hash-Wert über die versendete Nachricht. Mit dem Digest kann sichergestellt werden, dass sich die MDN auch wirklich auf die versendete Nachricht bezieht.

(12) Öffnet einen weiteren Dialog, in dem festgelegt werden kann, wie auf diverse Fehler reagiert werden soll. Siehe folgender Screenshot. Die dort voreingestellten Werte sollten nur in begründeten Ausnahmefällen geändert werden.

(1) Die Daten werden entgegengenommen und zur weiteren Verarbeitung übergeben (Response Code processed).

(2) Die Daten werden zwar entgegengenommen, aber nicht zur weiteren Verarbeitung übergeben (Response Code processed/error).

(3) Die Daten werden entgegengenommen und zur weiteren Verarbeitung übergeben, obwohl etwas Unvorhergesehenes passiert ist. Eine solche Antwort kann z. B. dann gegeben werden, wenn der Absender der Daten nicht authentifiziert werden konnte, die Daten aber trotzdem verarbeitet werden sollen. (Response Code processed/warning)

(4) Die Daten werden nicht entgegengenommen (Response Code processed/failure).

Hinweis: Zu den Response Codes siehe auch den Eingangsagenten CommLog.