The failure mode is almost always expiry
In a mature B2B environment, the recurring causes of partner-facing incidents are narrow: an expired certificate, a rotated SSH key that was never exchanged, a PGP key that no longer matches, or a TLS configuration change at one end that the other end cannot negotiate. None of these are integration defects, and all of them are avoidable with a calendar and an owner.
They dominate incident volume because the material is distributed. SSH keys live with the partner connection, AS2 certificates with the trading partner profile, TLS certificates at the perimeter, and PGP keys with whoever set up payload encryption. Without a single register, expiry discovery happens when a transfer fails.
What each layer does
Four distinct mechanisms, frequently confused in incident calls.
SFTP and SSH keys
Authenticate the connection. A rotated key must be exchanged and installed before the old one is withdrawn, on a schedule agreed with the partner.
AS2 certificates
Sign and encrypt the message and validate the MDN. Signing and encryption certificates may differ, and both ends must trust the full chain.
PGP keys
Encrypt the payload itself, independent of transport. A file can arrive successfully and still be unreadable if the PGP key is wrong.
TLS certificates
Secure the transport for FTPS and HTTPS, usually terminated at the perimeter by Secure Proxy.
A practical operating routine
None of this requires tooling investment; it requires ownership.
- Maintain one register of every key and certificate: type, partner, environment, expiry date, and a named owner
- Review expiry on a fixed monthly cadence, looking ninety days ahead rather than thirty
- Schedule rotations outside month-end and outside partner freeze windows
- Exchange and install the new credential before withdrawing the old one, and confirm with a test transfer
- Record the rotation in the register immediately, since an unrecorded rotation is indistinguishable from none
- Keep a documented rollback for each rotation, particularly where a partner cannot support dual keys
Why AS2 is disproportionately expensive
AS2 concentrates several failure modes in one exchange. The message is signed and encrypted, the MDN is often signed as well, and each direction may use different certificates. A partner renewing one certificate without notice can leave files transmitting successfully while acknowledgements fail, which frequently reads as a routing problem rather than a trust problem.
The diagnostic discipline is to separate transport from payload from acknowledgement. Confirm the connection succeeded, confirm the payload decrypted, then confirm the MDN returned and validated. Establishing which of the three failed usually identifies the certificate involved immediately.
Make the register visible to operations
Security material managed in a spreadsheet is a register that only its author trusts. Holding keys and certificates as governed assets with expiry dates and owners inside the operational platform means the people handling partner escalations can see the same information as the person who installed it. That is how DIVE treats security assets, alongside partner and flow configuration.
For hands-on support with certificate operations, partner onboarding, and secure exchange, see IBM Sterling B2B Integrator Ecosystem Services.