AS2 Certificates Explained: How to Get, Exchange, and Test Them

What an AS2 certificate is

An AS2 certificate is a standard X.509 digital certificate. Nothing AS2-specific about the file itself. What makes it an "AS2 certificate" is how it gets used: your AS2 software uses the private key to sign outbound messages, and your trading partner uses the public certificate to verify those signatures and to encrypt messages they send you. Signing proves the message came from you and was not altered. Encryption ensures only you can read what arrives.

A working AS2 connection typically has three certificates in play, and confusing them is the source of endless onboarding pain:

• The TLS certificate: secures the HTTPS transport layer, exactly like a website certificate. It lives on the server receiving AS2 traffic and is usually CA-issued.
• The signing certificate: signs the AS2 payload itself and signs MDN receipts. This is the one your partner verifies.
• The encryption certificate: your partner encrypts payloads to your public encryption certificate; you decrypt with the matching private key.

In most deployments the signing and encryption certificate are the same file. The TLS certificate is almost always separate. When a partner asks for "your certificate," confirm which one they mean before sending anything.

Self-signed vs CA-issued

Here is the part that surprises people coming from the web world: self-signed certificates are completely normal in AS2. Browsers reject self-signed TLS certificates because they have no way to establish trust with an unknown server. AS2 does not have that problem. You and your partner exchange certificates directly, out of band, before any message flows. Trust is established by the exchange itself, not by a certificate authority vouching for you.

Most AS2 connections in production today run on self-signed signing and encryption certificates. They cost nothing, take one command to generate, and work everywhere.

Some partners require CA-issued certificates anyway. Large retail networks, some pharma trading hubs, and organizations with strict internal security policies may reject self-signed certificates on principle. The requirement will be in their onboarding documentation. Read it before you generate anything, because swapping certificates after a connection is live means a full rollover with every affected partner.

How to generate an AS2 certificate

One openssl command produces both the private key and a self-signed X.509 certificate. Use RSA 2048 at minimum; 4096 if your partner's spec calls for it or you want more headroom:

openssl req -x509 -newkey rsa:2048 -sha256 -days 730 \
  -keyout as2-private-key.pem -out as2-certificate.pem -nodes \
  -subj "/CN=YOUR-AS2-ID/O=Your Company/C=US"

• -days 730: two years of validity. See the expiry section below before picking a longer window.
• -sha256: signs the certificate with SHA-256. Never generate anything with SHA-1 in 2026; many partners reject it outright.
• -nodes: skips passphrase encryption on the key file so your AS2 server can load it unattended. Protect the file with filesystem permissions and a secrets store instead.
• CN: put your AS2 ID or company name in the Common Name. Partners see this when they import your certificate, so make it identifiable.

Most AS2 software (OpenAS2, mendelson, IBM Sterling, and others) wants the key and certificate bundled as a PKCS#12 file:

openssl pkcs12 -export -inkey as2-private-key.pem \
  -in as2-certificate.pem -out as2-keystore.p12 -name "as2-key"

The export prompts for a password. Use one; the .p12 contains your private key.

If a partner requires a CA-issued certificate, generate a key and a certificate signing request (CSR) with openssl req -new instead of -x509, submit the CSR to a public CA, and import the issued certificate plus the CA's intermediate chain into the same PKCS#12 bundle. The rest of the workflow is identical.

Exchanging certificates with a trading partner

The exchange is simple in principle and botched constantly in practice. The rule: your partner gets your public certificate and nothing else. The private key never leaves your infrastructure. Not by email, not in a .p12 "for convenience," not ever. Anyone holding your private key can impersonate you and decrypt your traffic.

Export the public certificate on its own:

openssl x509 -in as2-certificate.pem -out as2-public.cer -outform DER

Know your formats, because partners will ask for specific ones:

• .pem: Base64 text with BEGIN/END markers. Public certificate only (unless someone pasted a key into it; check).
• .cer / .crt / .der: a single certificate, either Base64 or binary DER encoded. Safe to send.
• .p7b: a PKCS#7 bundle carrying one or more certificates, typically a cert plus its CA chain. No private key. Safe to send.
• .p12 / .pfx: a PKCS#12 keystore containing the private key. Never send this to a partner. If a partner sends you one, tell them to rotate immediately.

On the receiving end, your partner imports your public certificate into their AS2 software and attaches it to your partner profile, and you do the same with theirs. Common failure at this step: the partner imports your certificate but attaches it to the wrong profile, or imports the old certificate from a previous email thread. Confirm the serial number or SHA-256 fingerprint over the phone or in writing. Before you send yours, run it through our free AS2 certificate checker to verify validity dates, key size, and usage flags, so the file you email is the file that works.

Expiry and rollover: the #1 sudden failure

Ask anyone who runs AS2 in production what breaks connections that worked yesterday. Certificate expiry. Every time. The connection passes every test at onboarding, runs quietly for two years, and then fails at 00:00 UTC on the expiry date with an error message that says nothing about certificates.

Check your dates today:

openssl x509 -in as2-certificate.pem -noout -dates -fingerprint -sha256

Rollover is the hard part, because it takes coordination. The sequence that works:

• Generate the new certificate at least 60 days before the old one expires.
• Send the new public certificate to every partner with a clear cutover date. Most AS2 software can hold both certificates during the transition and accept messages verified against either.
• Switch your outbound signing to the new certificate on the agreed date, after partners confirm the import.
• Keep the old certificate loaded for verification until in-flight messages and queued retries clear, then remove it.

The partner who never confirms the import is the one whose connection breaks on cutover day. Test each connection after rollover instead of assuming; our free AS2 connection test verifies the new certificate end to end without waiting on the partner's availability.

Common certificate errors and what they mean

• Decryption failure: the sender encrypted to a different certificate than the one your private key matches. Almost always a stale certificate on the partner side after a rollover, or your own keystore holding the wrong key. Compare fingerprints on both sides.
• Signature verification failure: the receiver holds a different public certificate than the private key that signed the message. Same root cause as above, opposite direction. Can also be an algorithm mismatch: you sign SHA-256, they only accept an older configuration, or vice versa.
• Certificate expired: exactly what it says, but the error often surfaces as a generic processing failure or an unexplained MDN rejection. When a stable connection fails suddenly, check expiry dates on all certificates, both sides, before debugging anything else.
• Chain or trust errors ("unable to find valid certification path," "certificate unknown"): a CA-issued certificate was imported without its intermediate chain, or a self-signed certificate was never imported into the trust store at all. Import the full chain, or explicitly trust the self-signed certificate in your AS2 software.
• Wrong certificate in the profile: no dedicated error for this one. Messages just fail with whichever symptom above matches the mismatch. This is why fingerprint confirmation during exchange saves days.

For the full end to end checklist beyond certificates, from TLS handshake through MDN validation, see our guide on how to test an AS2 connection.

AS2 certificate vs AS2 certification: not the same thing

One naming collision worth clearing up. An AS2 certificate is the X.509 file this guide covers. AS2 certification usually means Drummond certification, an independent interoperability testing program that AS2 software products go through to demonstrate they exchange messages correctly with other certified products. Software vendors get certified; individual companies running AS2 do not need any certification to trade. If a partner's spec sheet says "Drummond certified software required," that is a requirement on which AS2 product you run, not on your certificate. The full breakdown of who needs certification and who does not is in AS2 certification vs AS2 connection testing.