An AS2 certificate binds a public key to identity information and lets trading partners secure AS2 messages. The matching private key remains with its owner. Together, certificates and private keys support digital signatures, message encryption and validation of signed MDN receipts.
Certificate work is also one of the most frequent causes of AS2 outages. The cryptography may be sound while the connection fails because a partner imported the wrong file, associated it with the wrong profile or activated a replacement on a different date.
Public certificates and private keys
A public certificate is designed to be shared. A private key is secret and must be accessible only to the system that signs or decrypts on behalf of its owner.
When your company sends an AS2 message to a partner:
- you sign with your private key;
- the partner verifies your signature using your public certificate;
- you encrypt using the partner’s public certificate;
- the partner decrypts using its private key.
Inbound traffic reverses those roles. This directional model is the easiest way to diagnose certificate selection: ask who must prove origin and who must be able to read the content.
Signing and encryption are different controls
A digital signature lets the recipient detect changes and validate that the message was signed with the private key corresponding to the trusted certificate. Encryption makes the packaged content unreadable to anyone who does not hold the intended private key.
Signing does not hide the content. Encryption alone does not prove which trading partner created it. Partners commonly require both, together with HTTPS and a signed MDN.
Which certificate does an MDN use?
A signed MDN is signed by the recipient of the original message and verified by the original sender. Depending on the platform and partner agreement, the MDN may use the same signing certificate as normal outbound messages or another configured certificate.
Do not assume that a successful inbound payload signature means the MDN trust is configured correctly. Test the exact receipt path and retain the certificate fingerprint used to validate it.
Common AS2 certificate formats
| Format | Typical extensions | Can contain private key? | Notes |
|---|---|---|---|
| PEM | .pem, .crt, .cer | Sometimes | Base64 text between BEGIN/END markers; inspect the label |
| DER | .der, .cer | Normally no | Binary X.509 certificate |
| PKCS#7 | .p7b, .p7c | No | Can contain a certificate chain |
| PKCS#12 | .p12, .pfx | Yes | Password-protected bundle that may include private key and chain |
An extension is not proof of contents. Inspect the file before importing it. A .cer can be PEM or DER, while a .pfx may expose a private key and must never be distributed like a public certificate.
Self-signed or CA-signed?
Both can work for AS2 if the trading partner accepts the certificate and validates it according to the agreed trust model.
A self-signed certificate is trusted because the partner imports that exact certificate into its AS2 profile. It avoids dependency on a public certificate authority but requires deliberate bilateral exchange and replacement.
A CA-signed certificate has a chain to an issuing authority. Some organizations require it as policy, but public trust alone does not remove the need to map the correct certificate to the correct AS2 partner. Confirm requirements with the partner rather than assuming browser TLS rules apply unchanged to AS2 message signing.
AS2 certificate exchange process
Use a controlled exchange:
- Export only the intended public certificate.
- Record subject, issuer, serial number, validity dates and SHA-256 fingerprint.
- Transfer the certificate through the agreed channel.
- Verify the fingerprint through a second trusted channel or known contact.
- Import it into the correct partner and environment.
- Assign it to signature verification, encryption or MDN validation as agreed.
- Run a signed and encrypted test in both directions.
- Store the final fingerprint and activation evidence in the partner record.
Never email a private key or place a PKCS#12 bundle in a broadly shared folder. If a private key may have been exposed, treat it as compromised and replace it.
Certificate inventory
Maintain a searchable inventory with:
- certificate owner and trading partner;
- test or production environment;
- direction and purpose;
- serial number and SHA-256 fingerprint;
- issue and expiry dates;
- location of the protected private key, if owned locally;
- responsible technical and business contacts;
- partner notice period;
- planned replacement and activation dates;
- last successful validation event.
Do not use filename as the primary identifier. Different files can have similar names, and the same certificate can be exported under several filenames.
Renewal without downtime
Certificate renewal is a bilateral change. Generating a new certificate locally does not update the partner’s profile.
A safe runbook is:
- Start before the partner’s required notice window.
- Generate or obtain the replacement and verify its validity dates.
- Send the new public certificate and fingerprint to every affected partner.
- Ask each partner to confirm import into the correct environment.
- Agree the exact activation time and time zone.
- Use overlapping certificate support where both platforms allow it.
- Send controlled tests and validate message signatures, decryption and MDNs.
- Monitor the first production exchanges closely.
- Retire the old certificate only after all partners have confirmed success.
If one certificate is shared across many partners, renewal becomes a coordinated program rather than a single maintenance ticket. Track partner readiness separately so one delayed partner does not disappear inside an overall “in progress” status.
For alert timings and emergency recovery, read AS2 certificate expiration: how to avoid downtime.
Overlap and dual-certificate support
The lowest-risk rotation allows the receiver to trust both the old and new signing certificates temporarily, or the sender to select between active partner encryption certificates during a planned window. Platform behavior varies, so confirm whether overlap is supported and in which direction.
If overlap is not possible, schedule a synchronized cutover with rollback criteria. Keep the old key available securely until the new path is proven, but do not continue using an expired or compromised key.
Frequent certificate failures
Unknown signing certificate
The receiver cannot match the signature to a trusted partner certificate. Compare the actual signing fingerprint with the certificate imported on the receiving profile.
Decryption failed
The sender encrypted with a certificate whose private key is not available to the receiver. Confirm current partner encryption certificate and key association.
Certificate is not yet valid or has expired
Compare system clocks, validity timestamps and time zones. Then confirm whether the intended certificate was activated.
Test certificate used in production
Inspect fingerprint and profile mapping, not just subject name. Test and production certificates may have similar identities.
Signed MDN cannot be validated
Identify which certificate signed the receipt, whether the chain or exact certificate is trusted and whether the expected MIC algorithm is supported.
Certificate security practices
- Generate private keys in a controlled environment.
- Restrict export and administrative access.
- Protect backups and document recovery procedures.
- Log key and certificate changes.
- Use current key sizes and algorithms accepted by both partners.
- Revoke or replace compromised credentials promptly.
- Alert on expiry far enough in advance for partner coordination.
- Test restored keys and disaster-recovery paths safely.
Certificate validity is necessary but not sufficient. A connection also needs correct AS2 parameters, matching algorithms and an operational monitoring process.
For evidence retention, access reviews and controlled certificate changes, use the AS2 EDI compliance checklist.
Frequently asked questions
What certificate should I send to my AS2 partner?
Send the agreed public certificate, never the private key. State whether it is for signature verification, encryption, MDN validation or more than one purpose, and include its SHA-256 fingerprint and validity period.
Can the same AS2 certificate be used for signing and encryption?
Many implementations allow it, but platform and partner policies differ. Separate certificates can reduce coupling but increase inventory and rotation work.
Does renewing the HTTPS certificate renew the AS2 certificate?
No. The TLS certificate protecting the website session and the AS2 message certificate are separate controls, even if their expiry dates happen to be similar.
How early should an AS2 certificate be renewed?
Early enough to meet the slowest partner’s notice and test process. Many teams alert at several thresholds, then escalate partners that have not confirmed readiness.
AS2Connection manages partner certificate visibility and rotation as part of its hosted AS2 server service.
