Einstellungen

(1) Eigenes Zertifikat (Verschlüsselung): 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) Partner Zertifikat (Verschlüsselung): 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) Eigenes Zertifikat (Signierung) , Partner Zertifikat (Signierung) : Siehe (1) und (2).

(4) Signiert senden , Verschlüsselt senden: Gibt an, ob Daten 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) Signiert empfangen , Verschlüsselt empfangen: 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) Sicherheitseinstellung der Signatur entfernen: 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) Sending chunked data: Nachrichten in Blöcke unterteilen (CTE). Hinweis: Wird nur in seltenen Fällen für alte AS2-Konnektoren benötigt.

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

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

(10) MDN-Typ , MDN-URL: Hier kann für den Kanal festgelegt werden, wie die Übermittlung der MDN an den Kommunikationspartner erfolgen soll. Folgende Möglichkeiten sind vorhanden.

• 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) MDN-Digest Alg: 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) Fehlerbehandlung: Öffnet einen weiteren Dialog, in dem festgelegt werden kann, wie auf diverse Fehler reagiert werden soll. Die dort voreingestellten Werte sollten nur in begründeten Ausnahmefällen geändert werden.

(12.1) OK, so akzeptieren: Die Daten werden entgegengenommen und zur weiteren Verarbeitung übergeben (Response Code "processed").

(12.2) Bearbeite Fehler: Die Daten werden zwar entgegengenommen, aber nicht zur weiteren Verarbeitung übergeben (Response Code "processed/error").

(12.3) Bearbeite Warnung: 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")

(12.4) Gescheitert: Die Daten werden nicht entgegengenommen (Response Code "processed/failure").

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