An expiring AS2 certificate can halt a manufacturer's orders, shipment notices or invoices even when IBM Sterling and the ERP are otherwise healthy. The difficult part is aligning your certificate change with each trading partner's change.
Quick Answer
To renew an AS2 certificate in IBM Sterling while reducing trading partner disruption, identify every relationship using it, prepare a replacement, share the public certificate with affected partners and agree on a cutover window. Verify the correct signing and encryption settings against IBM's documentation, test traffic in both directions, retain the old certificate as your configuration permits and reconcile production transactions before retiring it.
In This Article
What an AS2 certificate renewal changes
AS2, or Applicability Statement 2, is a method for exchanging business documents over HTTP or HTTPS. Certificates help trading partners encrypt messages and verify digital signatures. An MDN, or message disposition notification, reports the receiving AS2 system's processing result. Certificate renewal replaces an expiring credential in that exchange, but neither side can assume the other has changed at the same time.
Think about direction and purpose separately. When you sign an outbound message, your partner needs the corresponding public certificate to check your signature. When a partner encrypts a message for you, your Sterling environment needs the matching private key to decrypt it. Conversely, your outbound encryption uses the partner's public certificate, while your validation of inbound signatures depends on the partner's signing certificate. A partner's certificate renewal and your own certificate renewal therefore call for different changes.
The application flow matters, too. A successful AS2 exchange does not establish that an 850 purchase order was accepted or that an 856 advance ship notice reached the right downstream process. Keep transport validation and EDI business validation on separate checklists.
Inventory dependencies before the cutover
Before touching production, find every partner relationship associated with the expiring certificate. Check where it is referenced, which organization and partner identities use it, what the certificate does in each flow and who owns the partner contact. In a Sterling environment shared by several business units, do not assume that one certificate belongs to one connection.
| Record | What to confirm | Cutover purpose |
|---|---|---|
| Certificate identity | Subject, serial number, expiration and whether the private key is available to Sterling | Distinguishes the replacement from the expiring certificate |
| Usage | Signing, decryption or another role in each AS2 relationship | Prevents changing the wrong certificate reference |
| Partner contact | AS2 identifier, technical owner, test contact and approval path | Establishes who will install and verify the public certificate |
| Business traffic | Inbound and outbound document types, schedules and downstream owners | Defines meaningful end to end testing |
| Change control | Cutover time, time zone, approval, fallback decision and monitoring owner | Clarifies action if either side is not ready |
Read each partner's published EDI implementation guide and its current AS2 change instructions. Confirm the accepted certificate format, delivery channel, required validation details and test procedure with the partner rather than treating one retailer's process as a standard for all partners. Build in time for its security review and change approval before the current certificate expires.
The key dependency is partner readiness. Loading a replacement certificate in Sterling does not mean the partner has installed its public portion. Do not activate outbound signing with the new certificate until the partner confirms it can validate messages signed with it.
A controlled renewal sequence
1. Prepare the replacement and preserve the current state
Record the existing certificate references and approved configuration before making changes. Generate or obtain the replacement through your organization's certificate process, confirm its intended use and validity period and protect the private key. Share only the public certificate with partners. Check the applicable IBM Sterling documentation for your installation when creating, importing and assigning certificates. Interface labels and activation behavior can vary by configuration.
2. Agree on the handoff with each partner
Send the public certificate through a channel the partner approves. Include the relevant AS2 identifiers, the old and new certificate identifiers, the certificate's intended use, a proposed activation time with time zone and a named test contact. Request confirmation that the partner has installed the certificate and is ready to test. Maintain a separate status for each partner, especially if one signing certificate is used across multiple relationships.
3. Stage carefully and change the intended reference
Confirm that the new certificate is present in the appropriate Sterling certificate management area and that the expected private key is available for your own signing or decryption. Then review the organization and partner relationships affected by the change. Apply the planned certificate assignment at the agreed time, following IBM's procedure for your deployment. Check signing and encryption roles separately. Avoid removing the old certificate simply because the new one has been imported.
4. Test both directions with the partner
Send an approved outbound test and check that the partner can receive it, decrypt it where applicable and validate your signature. For an inbound test, confirm that Sterling receives the message, performs the expected security checks and routes the document. Verify the MDN's disposition and correlate it with the original transmission. If the partner uses asynchronous MDNs, include their return path in the test.
5. Observe production and retire deliberately
Watch the first relevant production documents after activation. Check Sterling transaction records, partner confirmation and downstream order or shipping workflows. Keep the old certificate available during the agreed transition period where your configuration and security policy permit it. Retire it only after affected partners have moved to the replacement and you have addressed any queued or delayed traffic that could still rely on the old key.
Testing, pitfalls and recovery
A test that stops at an HTTP response misses several failure points. Your acceptance criteria should cover the certificate used, AS2 processing, acknowledgments and the business documents that depend on the connection.
| Test | What to inspect | Likely issue if it fails |
|---|---|---|
| Outbound AS2 | Partner receipt, signature check, decryption where used and MDN result | Partner has the wrong public certificate or has not changed its configuration |
| Inbound AS2 | Sterling receipt, signature check, decryption and routing | Wrong certificate reference, missing private key or partner cutover mismatch |
| EDI acknowledgment | Expected 997 functional acknowledgment and its acceptance or rejection result | EDI syntax issue after transport succeeds |
| Business flow | Expected order, shipment or invoice status in the receiving workflow | Document processed by AS2 but not accepted downstream |
A 997 functional acknowledgment tells the sender whether a document passed the receiver's syntax check. It can report acceptance or rejection, and it does not mean the order or its content was accepted. If an AS2 message fails before the document reaches EDI processing, you may not receive a 997 at all. For a closer look at the distinction, see EDI 997 acknowledgment failures that leave orders unconfirmed.
Common mistakes include updating a certificate reference for one relationship but missing another, confusing your certificate with the partner's certificate and treating a successful MDN as proof of ERP acceptance. Another risk is resending after a failed cutover without first determining whether the partner received the original message. That can create duplicate business transactions.
Write the fallback plan before activation. Identify who can authorize restoration of the previous certificate assignment, whether the partner can also revert and how you will reconcile messages held or transmitted during the change. Confirm delivery status before any replay.
If a test fails, isolate the layer before changing more settings. Compare certificate identifiers on both sides, inspect the Sterling processing record and request the partner's matching transmission result. Restore the approved prior configuration if the cutover cannot proceed, then reconcile affected messages with the EDI and ERP owners. Our guidance on EDI transaction monitoring helps frame that follow-up.
Where experienced Sterling support helps
Certificate work is especially sensitive during a Gentran migration, a Sterling upgrade or an ERP integration. In those projects, a failed exchange can be misdiagnosed as a mapping or application defect. Keep a separate certificate change record, baseline successful traffic and assign owners for Sterling, partner communications and downstream validation. If an upgrade is also on the calendar, use a distinct test window so you can attribute failures to the right change.
Focused E-Commerce is an IBM Partner with 20+ years of EDI expertise and 500+ EDI implementations delivered. We work on IBM Sterling implementations and ERP integration for SAP, Infor, Oracle and other systems. For certificate renewals, an experienced partner helps you inventory dependencies, plan the partner sequence, review test evidence and coordinate recovery with the teams that own business transactions. Those same controls apply when a renewal overlaps with an IBM Sterling B2B Integrator upgrade.
The practical finish line is clear: every affected partner has confirmed the replacement, expected traffic works in both directions and the EDI and ERP teams have reconciled the first production flows. Retire the old credential only after those checks and your security review are complete.
Frequently Asked Questions
Do trading partners need a new certificate when we renew our AS2 signing certificate?
Yes. Partners that validate your AS2 signature need your replacement public certificate and must make it available in their AS2 configuration before you begin signing with the new private key.
Can the old and new AS2 certificates overlap during cutover?
They can be retained during a planned transition if the Sterling configuration, partner setup and security policy allow it. Do not assume both are active for the same function. Confirm certificate selection behavior against IBM's documentation and test with each partner.
What does a successful AS2 MDN prove?
An MDN reports the receiving AS2 system's message processing result. Check its disposition and the partner's result, but validate EDI acknowledgments and downstream processing separately. An MDN alone does not confirm business acceptance of an order.
What should we do if messages fail after the new certificate goes live?
Pause further changes, compare the certificate and AS2 settings with the partner, and inspect Sterling transaction records. Follow the approved fallback plan if needed. Before replaying a message, confirm whether the original reached the partner to avoid duplicates.
Plan your Sterling cutover with the right owners
If certificate renewal coincides with a Sterling upgrade, Gentran migration or ERP project, talk with Focused E-Commerce about the partner inventory, test plan and production handoff.
Contact Us
