Failure to manage an AS2 certificate rollover is one of the most common drivers of unplanned EDI outages with trading partners. When a certificate used for signing or encryption expires, even if every other system and mapping remains unchanged, orders, invoices, and acknowledgments can immediately start failing. Many teams overlook critical steps in the rollover, assuming that sending a new certificate file is enough. Instead, treating certificate rotation as a structured, team-owned operational process is the safest way to prevent data flow interruptions. This detailed runbook outlines how to inventory certificates, coordinate with all affected parties, execute robust bidirectional testing, and keep your EDI landscape stable throughout a certificate changeover—especially when working within a large, diverse trading partner network or using a managed provider like Nexus VAN.
Quick Answer
Begin your AS2 certificate rollover at least 60 to 90 days before expiration. Inventory all connections and partner contacts, generate the replacement key pair, distribute only the public certificate (never the private key), confirm each partner’s import and intended use, test message flow both directions, agree on a cutover date and timezone, and maintain the old certificate for the documented overlap period. Monitor acknowledgments and downstream systems before considering the change complete.
In This Article
Why AS2 Certificate Rollovers Fail
AS2 connections require multiple certificates that serve distinct purposes—digital signatures, encryption, and often TLS for transport. Misunderstanding which certificate does what, or failing to differentiate their roles, is a regular source of incomplete rollovers. It’s also not enough for your side to be ready: a partner may import the new public certificate incorrectly, miss activating it, or misunderstand the activation sequence. These errors are amplified in multi-partner environments where implementation guides, allowed algorithms, and activation protocols may differ across organizations. Nexus VAN regularly advises teams to approach every certificate update as a granular, two-sided coordination exercise with no assumptions about other parties’ readiness or process maturity.
Never treat the act of sending or uploading a public certificate as evidence that a partner is ready. Require confirmation of proper import, assignment to the correct role, and successful two-way testing before proceeding.
Frequent Failure Points
- Certificate tracking sheets omit relationships or incorrectly list certificate roles
- Replacement certificates are distributed less than two weeks from expiration
- The private key is mistakenly sent to a trading partner
- partners activate certificates on test but not production endpoints
- Inbound (received) message processing isn’t validated
- Production or testing overlooks required signed message disposition notifications (MDNs)
- Old certificates are deleted before all retries and queues are cleared
- Cutover times are set without explicitly specifying the timezone
Building a Robust Certificate Inventory
Prior to certificate generation, complete an inventory review of all AS2 relationships, partner identifiers, endpoints, certificate roles, and expiration dates. Use production data flows, portal audit logs, and integration server certificates stores to catch edge cases and test endpoints. Each record in the inventory should reflect an actual, documented connection. For each trading partner, confirm the following fields:
| Inventory Field | Details to Record | Rollover Relevance |
|---|---|---|
| Trading partner | Official name and internal owner | Assigns responsibility for coordination |
| AS2 identifiers | Your ID and partner’s ID | Surgical accuracy for updates |
| Endpoint | Prod/test URL, transport settings | Separates test from production change |
| Certificate role | Signing, encryption, TLS, etc. | Prevents misuse of certificate |
| Expiration date | With timezone | Determines rollover window |
| Algorithm/format | Required cryptography, file format | Ensures compatibility |
| Partner contact | Tech/escalation contacts, open ticket | Reduces delays at crunch time |
| Overlap capability | Does platform allow dual certs? | Controls switchover safety |
Assign clear owners for each row. In large environments, open a separate change record or checklist item per relationship rather than relying on broad team emails or chat threads.
The inventory phase surfaces expired test certificates, outdated endpoints, and undocumented integrations that could create risk during the rollover. This is your “safety net” phase.
The 90-Day Rollover Timeline
A best-practice AS2 certificate rollover starts 60 to 90 days prior to expiration and moves through a set of defined checkpoints to ensure every party and role is ready. Below is a practical schedule based on industry experience and operational reliability measures, including what evidence to collect at each step.
| Timeline Phase | Required Actions | Required Evidence |
|---|---|---|
| 90 days out | Inventory connections, designate owners, open tickets | Complete inventory, confirmed owners |
| 75–60 days out | Generate new key pair & certificate, secure private key | Certificate & private key access logged |
| 60–45 days out | Distribute public certificate, fingerprint, planned activation date | Partner written acknowledgment, ticket ID |
| 45–30 days out | Confirm import and role assignment with partner, confirm overlap support | Partner confirmation, import log |
| 30–14 days out | Exchange test traffic in all supported message directions | Success logs, application receipt, MDNs |
| 14–7 days out | Set cutover date/time/timezone; finalize rollback contacts | Formally documented plan, signoff |
| Cutover | Promote new certificate according to plan; monitor production | Success notification, message trace, live message |
| First business cycle after | Monitor all traffic, investigate errors, reconcile logs | Reconciliation report, cleared queues |
Certificate Generation and Distribution
Always generate the replacement certificate using settings documented by your trading partners and platform capabilities. Confirm algorithm, key usage, file format, and validity period in advance. Distribute only the public certificate, plus fingerprint, activation date, and support contact using each partner’s preferred and approved method. Never email or otherwise share the private key. Store the private key securely with access restrictions and an encrypted backup, following organizational policy.
Both old and new certificates should be available during the transition. Early removal of the old certificate creates risk for queued or retried messages and removes rollback options.
Testing the New Certificate Safely
Effective testing after a certificate change goes beyond simple file transfer. Successful AS2 validation includes acceptance, authentication, decryption of the payload, downstream application processing, and generation of a correctly signed MDN. Nexus VAN recommends maintaining explicit test records and confirming results with partners before announcing the rollover as ready.
Two-Sided Test Matrix
| Test Case | Expected Result | Proof/Evidence |
|---|---|---|
| Outbound signed | Partner validates new certificate signature | Message/time, confirmation from partner |
| Outbound encrypted | Partner successfully decrypts & processes | Receipt/MDN, status log |
| Inbound signed | Your platform validates partner signature | Inbound log, signature check |
| Inbound encrypted | Your platform decrypts and routes inbound document | Decryption/app status |
| Signed MDN | MDN received and validated | Raw MDN, status check |
| Transition queue | All queued/replayed messages process normally | Queue cleared, no errors |
When a test fails: identify the initial point of error (signature validation, decryption, application ingest, MDN generation, etc.), review both the sender and recipient environments, and check logs and acknowledgment records before retrying.
Details like AS2 IDs, endpoints, allowed algorithms, and message disposition settings are always governed by the latest documented partner implementation guide. Do not assume uniformity across your connection landscape.
Executing Cutover and Rollback
Success in the production cutover phase requires a precise time (including explicit timezone), all parties’ confirmation, and a full backup of current configuration. On platforms supporting parallel certificates, activate the new one as secondary, complete live flow testing, then promote during the agreed window. Always monitor traffic closely for at least a full business cycle afterward and validate every out/inbound document has been processed and acknowledged as expected.
Cutover Checklist
- Verify that all required partners have completed testing and approved the plan
- Document the active certificate fingerprint before change
- Set and confirm the exact cutover time and timezone
- Promote the new certificate for intended roles (signing/encryption/TLS)
- Get final partner confirmation of configuration changes
- Send and monitor a controlled live production message
- Monitor MDNs, queues, logs, and downstream applications for at least one business cycle
- Reconcile sent vs. acknowledged documents to ensure nothing is lost
- Do not retire the old certificate until overlap and retention criteria are fully satisfied
Rollback Requirements
Every rollover must define rollback conditions in advance: who can trigger the reversal, which certificate will be reactivated, and how notification, queued messages, and retransmissions will be handled. Mistakes—such as replaying already-processed documents—create risks of duplicate transactions, incorrect inventory, and payment errors. Carefully use control numbers, partner tickets, and application logs to guide recovery work. For a deeper view into reconciliation and dual-VAN controls, see our post on dual-VAN reconciliation.
Post-cutover reconciliation—comparing your acknowledged output with trading partners’ receipts, MDNs, and application states—is the only way to confirm the transition was fully successful.
Using Managed EDI to Reduce Certificate Risk
The larger your partner network or the more integration points you have, the more likely certificate details get lost or missed. Moving to a managed EDI network with modern tools, such as those offered by Nexus VAN, centralizes certificate storage, communication history, acknowledgment tracking, and migration planning. Our portal gives teams live visibility into transaction status, control numbers, and acknowledgment trail, which is invaluable for investigation and audit following a certificate change. Nexus VAN’s phased, supported migration process reduces risk with stepwise partner cutover, documented rollback steps, and dual-VAN traffic reconciliation as needed.
Because Nexus VAN pricing is based on precise kilo-character usage and does not round up on document sizes, you can reconcile your data volumes during the change process and accurately predict billing after the transition. This predictability, plus included migration, unlimited IDs, and expert support, provides finance and operations teams with assurance that certificate rollover activities will not create budget, support, or compliance surprises.
If you are planning a switch to a managed provider, always request a written migration plan detailing certificate inventorying, partner sequencing, test responsibilities, reconciliation procedures, rollback criteria, and decommissioning steps.
Frequently Asked Questions
How far in advance should an AS2 certificate be renewed?
Begin certificate renewal planning 60 to 90 days in advance. This lead time ensures enough margin to inventory, coordinate, resolve compatibility issues, and complete two-sided testing before expiration risks cut service.
Can old and new AS2 certificates be active at the same time?
Many platforms allow overlap. Always confirm with each partner whether their system supports dual certificate loading, which certificate is used for which message role, and when the old certificate can be safely retired.
What information should you send to a trading partner during rollover?
Send only the public certificate via the partner’s approved channel, including its fingerprint, activation date, expiration date, and a technical contact. Never share the private key under any circumstances.
What scenarios should be tested after an AS2 certificate update?
Test all message directions and types supported in the relationship: outbound and inbound signed and encrypted payloads, MDNs, application routing, and error scenarios including retries and queues.
What if a certificate expires before the rollover is finished?
Traffic will likely fail: messages may be rejected, signatures will not validate, and encrypted data cannot be processed. Connect with partners and your VAN provider immediately to triage errors, avoid resending transactions blindly, and reconcile all critical documents once service returns.
Plan a Lower-Risk EDI Transition
Review your AS2 connection landscape and transition options with an EDI specialist from Nexus VAN. We’ll cover certificate process, partner testing, reconciliation, and transparent usage-based pricing—so you can avoid outages and overages with your next rollover.
Schedule Demo