By Yair Knijn · March 17, 2025
The expired AS2 certificate that stopped a supply chain for a weekend
Onboard a trading partner, watch the first signed payload round-trip cleanly, see a green 200 and a valid MDN, and you mark AS2 as done. That is the trap. An AS2 certificate carries an expiry date, and when it passes, nobody gets a warning worth reading until live traffic stops.
Here is the weekend version. A self-signed signing certificate lapses at 00:00 on a Friday, and your retail partner's gateway validates signatures against that exact cert. From the first message after midnight, every inbound payload either fails to decrypt or returns an MDN the partner can no longer verify. By Monday someone is explaining to a buyer why three days of ASNs never arrived.
What actually breaks: encryption and MDN signatures
AS2 (RFC 4130) leans on two certificate operations that fail independently. Your partner encrypts the payload to your public certificate, so if that cert has rotated and they still hold the old one, you cannot decrypt what they send. Separately, you sign your outbound message and the returning MDN, and they verify those signatures against the certificate you handed over at onboarding. When yours lapses, the classic error appears: the receipt signature could not be verified because the certificate was not found in the specified store. One root cause, two symptoms, landing at different moments depending on who sends first.
The cruel detail is that the non-repudiation guarantee you bought AS2 for is what turns against you. A signed MDN is proof of receipt. One that fails verification is not a soft warning, it is a hard "I cannot trust this," and a well-built partner gateway treats the transfer as incomplete and stops.
Renewal is a two-party problem, not a one-click job
You cannot rotate an AS2 certificate on your own. Install a new cert on your side and your partner has to load the matching public key on theirs, or you have only moved the outage from "expired" to "mismatched." Both ends need the same material at the same instant, so serious partners schedule a cutover instead of swapping in silence.
Watch how the mature operators handle it. When a large product-data network like 1WorldSync rotates AS2 certificates, it does not push a cert and hope. It announces the change ahead of time, halts AS2 traffic at a stated hour, applies the new certificate during a declared outage, and resumes inside the published window. Set that against a cert quietly dying on a Friday night, nobody watching. Same mechanism, opposite outcome.
The renewal calendar every partner relationship needs
"Set and forget" fails because no single person owns the expiry dates. Build a calendar keyed to each partner connection, not to your gateway as a whole. For every live relationship, track:
- Your signing and encryption cert expiry, and the partner's, as two separate dates.
- The lead time that partner needs to load a new public key. Some retailers ask for weeks.
- A named owner on each side who confirms the new cert is installed before cutover.
- A pre-agreed renewal window, never a silent swap.
A self-signed certificate makes this harder than a CA-issued one. No chain to lean on, no external authority reminding anyone. The date lives in your records or it lives nowhere, and "nowhere" is what produces the Friday-midnight failure.
Alert on expiry before the partner does
The line you never want to cross is the one where your trading partner tells you that your certificate expired. Cross it and you are no longer running an integration, you are running an incident with your largest customer watching. The fix is unglamorous: parse the notAfter field on every configured certificate, yours and the partner's, and alert at 60, 30, and 7 days out.
xEvolve tracks the expiry of every AS2 certificate in an Environment, surfaces them on one renewal calendar, and warns you before notAfter turns into a stopped supply chain. See how the certificate lifecycle is handled in our AS2 and SFTP support.