AS2-Zertifikat abgelaufen: Aufträge werden abgelehnt –wie Sie den EDI-Fluss sicher wiederherstellen

Direkte Antwort: Wenn nach Ablauf eines AS2-Zertifikats Aufträge abgelehnt werden, sollten Sie diese nicht sofort erneut senden. Ermitteln Sie zunächst den letzten bestätigten Prüfpunkt: TLS/HTTP, AS2-Identität, Signatur, Entschlüsselung, MDN, EDI-Verarbeitung oder ERP-Übergabe. Ein kontrollierter Neustart ist erst dann sinnvoll, wenn Sie nachweisen können, ob der konkrete Auftrag den Handelspartner erreicht hat oder bereits verarbeitet wurde.

Für Unternehmen, die Lobster_data oder die Lobster Data Platform einsetzen, kann die nubibase GmbH bei der technischen Einordnung, bei der Prüfung von Partnerprofilen und Kommunikationswegen sowie bei der Gestaltung wiederholbarer Betriebsabläufe unterstützen. Welche Aufgaben nubibase konkret übernehmen kann, hängt von Zugriff, Verantwortlichkeiten und dem vereinbarten Leistungsumfang ab.

Was bedeutet der Fehler – und was beweist er nicht?

Der Sollzustand ist klar definiert: Ein Auftrag wird per AS2 übertragen, technisch bestätigt, im EDI-Fluss verarbeitet und an das ERP-System übergeben. Im Störungsfall sind jedoch häufig nur folgende Fakten sichtbar: Aufträge fehlen oder werden abgelehnt, während gleichzeitig ein Zertifikatsfehler, ein HTTP-Fehler oder eine ausstehende MDN auftritt.

Je nach Rolle und Konfiguration kann ein abgelaufenes Zertifikat den Aufbau der HTTPS/TLS-Verbindung verhindern, eine AS2-Signatur ungültig machen, die Entschlüsselung blockieren oder die Prüfung einer signierten MDN beeinträchtigen. Zertifikate haben eine festgelegte Gültigkeitsdauer; deren Ende wird in einem X.509-Zertifikat durch das Feld notAfter beschrieben (Quelle 2).

Wichtig ist die Trennung zwischen Transporterfolg und fachlichem Erfolg. Eine positive AS2-MDN bestätigt die AS2-seitige Verarbeitung des übertragenen Pakets, garantiert aber nicht, dass der EDI-Inhalt syntaktisch korrekt war oder im Zielsystem verarbeitet wurde – denn die MDN ist in RFC 4130 als transportseitige Empfangsbestätigung definiert, nicht als fachliche Verarbeitungsbestätigung (Quelle 1). Umgekehrt bedeutet eine fehlende MDN nicht automatisch, dass der Auftrag nie angekommen ist.

Sicherheitsregel: Eine ausstehende MDN ist ein ungeklärter Zustand. Stoppen oder begrenzen Sie automatische Wiederholungsversuche, bis für jede betroffene Geschäfts-ID die partner- oder ERP-seitige Verarbeitung geprüft wurde.

Wo liegt die erste fehlgeschlagene oder unbestätigte Übergabe?

Diagnostizieren Sie entlang einer konkreten Nachricht, nicht entlang von Teamgrenzen. Der letzte Punkt mit belastbarem Nachweis und der erste fehlende oder negative Nachweis grenzen den Fehlerbereich ein.

Orientierungsmodell; die tatsächliche Zuständigkeit hängt von Architektur, Vertrag und Zugriffsrechten ab.

Welche Nachweise benötigen Sie zuerst?

Beginnen Sie mit einem konkreten Auftrag, nicht mit einer breiten Log-Suche. Ein minimales Nachweispaket verhindert, dass Partner und interne Teams über unterschiedliche Nachrichten sprechen:

• Geschäfts-ID: Auftrags- oder Bestellnummer, Belegart, Partner, Richtung sowie Test- oder Produktivumgebung.
• Zeit und Identität: Zeitstempel mit Zeitzone, AS2-Message-ID, AS2-From, AS2-To und Endpunkt-URL.
• Transport: TLS-Ergebnis, HTTP-Status und, sofern relevant, mTLS-Zertifikat.
• Zertifikat: Rolle, Subject, Aussteller, Seriennummer, notAfter, SHA-256-Fingerabdruck, aktiver Alias sowie Keystore oder Truststore.
• Empfangsbestätigung: MDN-Modus, Disposition, MIC-Wert und Algorithmus, MDN-Signatur sowie Verweis auf die ursprüngliche Message-ID.
• Nachgelagert: CONTRL/997/999, Lobster-Nachrichten- oder Workflow-ID, erzeugtes Ausgabeobjekt, ERP-Importnummer oder SAP-IDoc-Nummer, sofern verfügbar.

Geben Sie keine privaten Schlüssel weiter. Für die Abstimmung mit dem Partner genügen öffentliche Zertifikatsdaten, Fingerabdrücke, Message-IDs, Zeitstempel und die genaue Fehlermeldung.

Wie stellen Sie den EDI-Fluss sicher wieder her?

Wiederholungsversuche kontrollieren. Stoppen oder begrenzen Sie automatische Wiederholungsversuche und sichern Sie alle Nachrichten mit ungeklärtem Status in einer Kontrollliste.

Zertifikatsrolle bestimmen. Prüfen Sie das TLS-Server-Zertifikat, ein mögliches mTLS-Client-Zertifikat, Ihr eigenes Signatur-Zertifikat, Ihr eigenes Entschlüsselungs-Zertifikat sowie die öffentlichen Signatur- und Verschlüsselungszertifikate des Partners jeweils getrennt. Lobster dokumentiert AS2-IDs sowie die getrennte Aktivierung von Signatur und Verschlüsselung im Partnerkontext (Quelle 3).

Konfiguration korrigieren. Das Importieren eines Zertifikats allein genügt nicht: Das aktive Produktivprofil muss auf den korrekten Alias und Fingerabdruck verweisen. Prüfen Sie zudem die Zertifikatskette, den privaten Schlüssel, die Schlüsselverwendung, die Trennung von Test und Produktion sowie alle beteiligten Knoten oder Gateways.

Technische Testnachricht senden. Prüfen Sie TLS, HTTP-Status, Signatur, Entschlüsselung, MDN-Disposition und MIC. Bei asynchronen MDNs muss zusätzlich der Rückkanal über URL, DNS, Firewall und TLS funktionieren.

Eine fachliche Nachricht kontrolliert freigeben. Verwenden Sie einen eindeutig identifizierbaren Auftrag, bitten Sie den Partner um Bestätigung von Empfang und Verarbeitungsstatus, und prüfen Sie die nachgelagerte Verarbeitung bis ins ERP.

Rückstau in kleinen Chargen öffnen. Geben Sie die Warteschlange erst nach einer erfolgreichen End-to-End-Prüfung frei. Gleichen Sie technische Nachrichten, manuelle Ersatzaufträge und bereits angelegte ERP-Belege ab.

Wann ist ein erneutes Senden vertretbar?

Wie beugen Sie dem nächsten Zertifikatsausfall vor?

Zertifikatsinventar pflegen. Dokumentieren Sie für jeden Partner AS2-IDs, Endpunkt, Zertifikatsrolle, Seriennummer, Fingerabdruck, Alias, Ablaufdatum, Speicherort, Ansprechpartner, letzten Test und geplantes Änderungsdatum.

Frühwarnungen einrichten. Überwachen Sie nicht nur Webserver-Zertifikate, sondern auch mTLS-, Signatur-, Verschlüsselungs- und MDN-Zertifikate. Warnstufen und Eskalationen sollten dem Vorlauf entsprechen, der für die Partnerabstimmung benötigt wird.

Überlappung einplanen. Importieren und testen Sie das neue Zertifikat vor Ablauf. Akzeptieren Sie altes und neues Zertifikat nur für einen definierten Übergangszeitraum, sofern Plattform, Sicherheitsanforderungen und Partnerprozess dies zulassen.

Änderung kontrollieren. Dokumentieren Sie Freigabe, Rollback, Test/Produktion, Fingerabdruck-Bestätigung, Signatur-/Verschlüsselungstest, MDN-Test sowie die spätere Entfernung des alten Zertifikats.

Nachrichtenstatus überwachen. Das Alerting sollte fehlende oder negative MDNs, MIC- oder Signaturfehler, Alter der Warteschlange und nachgelagerte Fehler sichtbar machen. Ein Runbook muss festlegen, wer ein erneutes Senden freigibt und wie Duplikate ausgeschlossen werden.

Wie kann nubibase unterstützen?

nubibase ist besonders dann relevant, wenn Lobster_data oder die Lobster Data Platform die bestehende Integrationsebene bleiben soll und der operative Umgang mit AS2-Zertifikaten, Partnerprofilen und Nachrichtenstatus verbessert werden muss. nubibase beschreibt sich selbst als Lobster Gold-Partner und Managed Service Provider mit Leistungen von Implementierung und Schulung bis zu Betrieb und Monitoring; Lobster führt nubibase als VAR Gold-Partner und Managed Service Provider (Quelle 6).

Im vereinbarten Rahmen kann nubibase bei der Lobster-bezogenen Nachrichtenverfolgung, bei Kommunikations- und Partnerprofil-Prüfungen, bei Mapping- und Workflow-Analysen, bei Monitoring, Störungsklassifizierung, Nachweispaketen, Neustartverfahren, Runbooks und der Partnerkoordination unterstützen. Dazu kann auch die Koordination an der Schnittstelle zwischen Integration und ERP gehören.

Die Verantwortung kann bei anderen Parteien verbleiben: TLS-Infrastruktur und zentrale PKI beim Infrastruktur- oder Sicherheitsteam, SAP-/ERP-Korrekturen und Stammdaten beim Anwendungsteam, die fachliche Freigabe eines erneuten Sendens beim Prozessverantwortlichen und Änderungen in Partnersystemen beim jeweiligen Handelspartner. Konkreter Zugriff, Supportzeiten, SLAs und Freigaberechte müssen vertraglich festgelegt werden.

Wo nubibase im Vergleich zu anderen AS2-/EDI-Unterstützungsoptionen steht

Wenn ein Zertifikatsausfall eine Lücke im Umgang mit AS2- und EDI-Betrieb offenlegt, stehen Unternehmen in der Regel drei grundsätzliche Optionen zur Verfügung, jede mit einem eigenen Abwägungspunkt:

Nächster sinnvoller Schritt: Prüfen Sie gemeinsam einen konkreten abgelehnten Auftrag, das aktive Zertifikat und die zugehörige MDN-Kette. Daraus lässt sich ableiten, ob eine gezielte Korrektur ausreicht oder ob Zertifikatsinventar, Monitoring und operative Verantwortung strukturell verbessert werden sollten.

Häufig gestellte Fragen

Ist ein AS2-Zertifikat dasselbe wie ein TLS-Zertifikat?

Nein. TLS schützt die HTTPS-Verbindung. AS2 kann zusätzliche Zertifikate zur Signatur und Verschlüsselung der Nachricht nutzen. In manchen Umgebungen sind die Rollen kombiniert, müssen bei der Diagnose aber trotzdem getrennt betrachtet werden.

Was bedeutet „Signaturprüfung fehlgeschlagen“?

Der Empfänger konnte die Signatur mit dem erwarteten öffentlichen Zertifikat nicht verifizieren. Prüfen Sie das verwendete Absenderzertifikat, den Fingerabdruck, die Gültigkeit, das Vertrauen, den Algorithmus sowie die Zuordnung zum aktiven AS2-Partnerprofil.

Warum bleibt die MDN nach einem Zertifikatswechsel ausstehend?

Die Nachricht ist möglicherweise nicht angekommen, die AS2-Verarbeitung ist fehlgeschlagen, oder die MDN hängt auf dem Rückweg bzw. bei der Signatur- oder MIC-Prüfung fest. Deshalb ist „ausstehend“ kein Nachweis für Nichtzustellung.

Kann der Auftrag nach dem Zertifikatswechsel einfach erneut gesendet werden?

Nur, wenn der Nachrichtenstatus hinreichend geklärt wurde. Fehlt die MDN, wurde nur HTTP 200 empfangen, gab es eine manuelle Ersatzverarbeitung, oder existiert bereits ein ERP-Beleg, besteht das Risiko doppelter Aufträge.

Welche Daten sollte der Partner erhalten?

AS2-Message-ID, Zeitstempel, AS2-From/AS2-To, HTTP- und MDN-Status, MIC, SHA-256-Fingerabdruck sowie die Geschäfts-ID. Private Schlüssel dürfen nicht weitergegeben werden.