Your AS2 certificate expired

What actually breaks

An AS2 relationship usually involves three kinds of certificate. Which one expired decides what you're seeing:

• Signing certificate — your partner can no longer verify your signature, so they reject inbound messages (or their MDN turns negative).
• Encryption certificate — the partner encrypts to a key they believe is valid; an expired one causes decryption failed or outright refusal.
• Endpoint TLS certificate — the HTTPS connection to your AS2 endpoint fails to establish at all, before any AS2 logic runs.

In every case the visible symptom is the same: documents stop moving, and it's usually a person — not a monitor — who notices.

Recover in the right order

1. Identify the expired certificate and its role. Confirm subject, fingerprint and notAfter so you replace the correct one.
2. Issue the replacement with the same key usage. Keep the private key on your own AS2 system — it never needs to leave it.
3. Send the new public certificate to every affected partner. Include the fingerprint so they can confirm they imported the right file.
4. Have each partner import and activate it. This is the slow, human step — different portals, contacts and lead times.
5. Send a test message and confirm a positive MDN before declaring it resolved.

Why it happened — and how to prevent the next one

Expiries are rarely a surprise in principle; the date is printed on the certificate. They surprise people because no single place tracks every certificate across every partner, and because the rollover has to start weeks early to give partners time to import the new certificate.

Two habits prevent almost every recurrence:

• Track every AS2 certificate's expiry in one inventory, not per-partner spreadsheets.
• Start each rollover during an overlap window — both old and new certificates active — so no partner is ever forced to cut over on the exact expiry day. See how to roll over without an outage.