AS2 Certificate Renewal, Step by Step

An AS2 certificate expiring at 2am on a Sunday doesn't send you a warning email the way a failing disk or a crashed server does. It just stops working. One moment Walmart's GEM mailbox is accepting your 856 ship notices, the next every outbound message bounces with a signature failure, and nobody notices until a buyer calls asking where last night's invoices went. This runbook walks through an AS2 certificate renewal that doesn't take down a live trading partner connection, whether that partner is a retailer, a 3PL, or a carrier feeding your TMS.

Why an AS2 certificate expiry takes down EDI without warning

AS2 certificate expiry is silent because the protocol has no concept of automatic trust renewal. Unlike a website certificate, where the server swaps the certificate and every browser adjusts automatically, your AS2 trading partner's software holds a static copy of your exact certificate and won't accept a replacement until a human on their side loads it. That's the core mechanic behind every "it just stopped working" ticket this protocol generates.

Each AS2 partnership typically runs on four certificates: your signing certificate, your encryption certificate, and the matching pair on your partner's side. Any one of those four expiring breaks that specific partner's flow, and only that one. Walmart suppliers run into this constantly. The email can indicate that the Supplier Certificate would be expiring, or that the Walmart AS2 Certificate would be expiring, or both, and each scenario requires a different fix on your side. You won't see this coming in a dashboard unless you've built one yourself, because expired certificates silently break AS2 connections. The first sign is usually a string of negative MDNs or a partner's EDI team calling to ask why their inbound mailbox has gone quiet.

What you need before you start

Before touching anything in production, pull a current certificate inventory: AS2 ID, AS2 URL, expiry date, and serial number for every partner connection in your AS2 station, whether that's IBM Sterling B2B Integrator, Cleo Harmony, Mendelson AS2, OpenAS2, or a VAN-hosted gateway. You also need admin rights to generate a new keypair or CSR, a named contact at each partner who can actually load a new public certificate on their end (not a generic support inbox), and a scheduled maintenance window. Keep the old certificate active rather than deleting it the moment you generate a new one. Most AS2 platforms support overlapping certificates, and this is exactly why that feature exists: a working rollback costs you nothing until the cutover is confirmed clean.

One more thing worth checking before you start: how your retailer validates certificate lifetimes. Walmart, for example, enforces an upper bound as well as a lower one. Attempting to upload a certificate with validity beyond their accepted window will get rejected outright, so don't assume "longer is safer" when generating the new keypair.

Step-by-step renewal process

1. Audit expiry dates across every partner. Flag anything inside 60 days. Aayu Technologies recommends exactly this threshold, suggesting you set up automatic reminders after 30, 60, and 90 days before expiration. Don't rely on the partner's reminder email as your only trigger, Walmart's GEM notifications are useful but not guaranteed to reach the right inbox every time.
2. Generate a new key pair and CSR. Use your AS2 platform's built-in certificate manager (most, including Sterling and Cleo, have one) or openssl directly. Decide self-signed versus CA-issued per partner requirement. It's worth knowing that self-signed certificates are completely normal in AS2 because trust is established by direct exchange between partners, not by a certificate authority, unlike the browser trust model most engineers are used to.
3. Notify each trading partner in writing. Include the AS2 ID, AS2 URL, old and new certificate serial numbers, and a proposed cutover date. This is the step people skip under deadline pressure and regret the most. Coordination here isn't optional because AS2 needs a human hand to synchronize the switch, unlike a browser trust store that updates itself.
4. Load the new certificate while keeping the old one live. Your AS2 software should let both certificates validate simultaneously during the transition window. This is the single biggest difference between a clean renewal and a 2am outage call.
5. Agree a cutover time and send a test transmission both directions. A sample 850 or even a plain test file works. Confirm the MDN comes back positive before you send anything that matters.
6. Monitor the first production cycle after cutover. Watch specifically for "authentication failed" or "signature verification failed" dispositions in the returned MDNs, not just a generic send failure.
7. Retire the old certificate only after a full clean business cycle. Don't delete it the same day. Give it at least one full order-to-invoice cycle with that partner before you remove the fallback.

How you execute step 4 depends heavily on your platform. Self-hosted engines like Sterling B2B Integrator or Cleo Harmony give you direct control over dual-certificate validity windows but put the coordination burden entirely on your team. Managed gateways from SPS Commerce or TrueCommerce often handle the partner-side synchronization for you on retailer connections they already manage, though you'll still need to drive the process for direct partners outside their network. Newer platforms like Orderful and Stedi lean toward API-first onboarding and tend to abstract away raw certificate handling, which helps until you have a legacy partner who insists on classic AS2 and nothing else.

How you know it worked

Success looks boring, which is the point. You should see clean positive MDNs with no authentication-failed disposition on either side of the exchange. For X12 partners, 997 functional acknowledgments should keep flowing on the same schedule they always have; EDIFACT partners should show equivalent CONTRL messages. Check your AS2 station's queue for stuck or retried outbound messages, a healthy post-cutover log shows nothing sitting in a retry loop.

Failure mode: negative MDN after cutover

If you get a negative MDN with a signature verification failure right after cutover, there are really only two causes. Either you loaded the wrong certificate (or the wrong role, encryption cert in the signing slot is a classic mix-up) on your own side, or your partner hasn't actually finished updating their store of your new public certificate yet, even if they confirmed they had. This exact scenario shows up constantly in Walmart's AS2 connectivity errors, where a signature verification failure on a negative MDN traces back to a stale certificate on one end of the exchange.

The fix is to fall back to the parallel certificate immediately rather than troubleshooting live. Confirm your old certificate is still active and valid, revert the partner connection to it, and resume production traffic on the known-good cert while you sort out the new one offline. Re-send the correct public certificate to the partner, have them explicitly confirm which certificate is loaded in their system (not just that they "updated it"), and re-test with a sample message before touching production traffic again. Trying to force the new certificate through a second time without closing the loop on what actually went wrong just produces a second outage.

Beyond invoicing: AS2 carries your carrier and TMS feeds too

AS2 isn't only moving 850s and 810s to retailers. Plenty of shippers use the same protocol to exchange 204 load tenders, 214 status updates, and 990 tender responses with carriers and 3PLs. A lapsed certificate on that side of the house stalls tracking data and tender acceptance just as completely as it stalls an invoice, except now it's your freight desk fielding the "where's my shipment" calls instead of accounts payable. Transport management platforms like MercuryGate, Oracle TM, and SAP TM, along with multi-carrier connectivity tools such as Cargoson, sit on the receiving end of exactly these AS2-delivered feeds, so the same renewal discipline that protects your retail EDI needs to apply to your carrier integrations too. Treat the certificate inventory as one list, not two, and you won't be surprised by which feed goes quiet next.

Build the 60-day expiry check into whatever monitoring you already run, whether that's a cron job polling certificate metadata or a calendar reminder tied to your AS2 station's export. The renewal itself takes an afternoon. Finding out about it from a partner's phone call takes a lot longer to recover from.