Certificate Errors Are the #1 AS2 Killer

If you've spent any time managing AS2 connections, you already know: certificate problems account for more failed connections than everything else combined. The error messages are often cryptic, the root causes are varied, and the back-and-forth with trading partners to resolve them can drag on for days.

This guide covers the six most common categories of AS2 certificate errors, with specific diagnostic commands and fixes for each. Everything here uses OpenSSL, which is available on every Linux and macOS system and on Windows via Git Bash or WSL.

1. Expired Certificates

The most frequent certificate error, and the most preventable. AS2 certificates have a validity window. When a certificate expires, every message signed or encrypted with it will fail. Most AS2 platforms will reject the message outright. Some will accept it and produce an MDN with a failure disposition, which is harder to debug because it looks like the message was received.

How to check expiration

Run this against any certificate file:

openssl x509 -in partner_cert.pem -noout -dates

Output looks like this:

notBefore=Jan 15 00:00:00 2025 GMT
notAfter=Jan 15 23:59:59 2026 GMT

If notAfter is in the past, the certificate is expired. If it expires within the next 30 days, start the renewal process now.

Checking a remote endpoint's certificate

You can inspect the certificate your partner's AS2 server presents during TLS without sending a message:

echo | openssl s_client -connect partner.example.com:443 2>/dev/null | openssl x509 -noout -dates

This tells you whether the TLS certificate (not necessarily the AS2 signing/encryption certificate) is valid. These are often different certificates, so check both.

What to do

Contact your trading partner and request a renewed certificate.
Update your AS2 platform's partner profile with the new certificate.
If you control the expired cert, generate a new one (see Section 5 for key size requirements) and distribute it to all trading partners.
Set a calendar reminder 30 days before the new certificate expires. Repeat this every time.

2. Self-Signed vs. CA-Signed Certificate Issues

AS2 uses certificates for two distinct purposes: TLS transport security and message-level signing/encryption. The rules for each are different, and confusing them causes a lot of unnecessary trouble.

TLS certificates

Your AS2 endpoint's HTTPS certificate should be CA-signed. Most AS2 clients will reject self-signed TLS certificates by default. If your partner's client is throwing a "certificate verify failed" or "unable to get local issuer certificate" error when connecting to your endpoint, your TLS certificate is likely self-signed or missing intermediate certificates.

AS2 signing and encryption certificates

For message-level signing and encryption, self-signed certificates are common and generally acceptable. Both Drummond-certified platforms and most enterprise AS2 implementations support them. The certificate just needs to contain the correct public key and be trusted by explicit configuration, not by a CA chain.

The confusion point

Problems arise when a partner's AS2 system validates the entire chain of trust for signing/encryption certificates. This is uncommon but not rare. In this case, you need either:

A CA-signed certificate for both TLS and AS2-level operations.
Your self-signed certificate explicitly imported into their trust store.

Ask your partner which mode their system uses. Don't guess.

Checking if a certificate is self-signed

openssl x509 -in cert.pem -noout -issuer -subject

If issuer and subject are identical, it's self-signed.

3. Chain of Trust Failures

When using CA-signed certificates, the full chain must be present: your certificate, any intermediate certificates, and the root CA certificate. Missing intermediates are the most common chain-related failure.

Symptoms

"unable to get local issuer certificate"
"certificate verify failed"
"unable to verify the first certificate"

All three typically mean the same thing: the certificate chain is incomplete.

Diagnosing chain issues

Verify the chain with OpenSSL:

openssl verify -CAfile ca-bundle.pem -untrusted intermediate.pem your_cert.pem

If you don't have the intermediate certificate, download it. The certificate itself usually contains a URL pointing to the issuer's certificate:

openssl x509 -in your_cert.pem -noout -text | grep -A 1 "Authority Information Access"

Look for the "CA Issuers" URI. Download that file and include it in your certificate chain.

Building a proper chain file

For PEM format, concatenate in order from leaf to root:

cat your_cert.pem intermediate.pem root.pem > chain.pem

The order matters. Leaf first, root last. Get it backwards and some systems will reject the chain silently.

4. Wrong Certificate for the Wrong Purpose

AS2 connections typically use two separate certificate operations: one for signing messages (proving you sent them) and one for encrypting messages (ensuring only the recipient can read them). These can be the same certificate, but they don't have to be.

Common mistakes

Swapped certificates: Your signing certificate in the encryption slot, or vice versa. This fails because the partner tries to verify your signature with what they think is your signing cert, but it's actually your encryption cert.
Key Usage restrictions: Some certificates have Key Usage or Extended Key Usage extensions that restrict what operations they can perform. A certificate with only "Key Encipherment" set cannot be used for digital signatures.

Checking Key Usage

openssl x509 -in cert.pem -noout -text | grep -A 3 "Key Usage"

You want to see:

For signing: Digital Signature
For encryption: Key Encipherment or Data Encipherment
For dual-purpose: both of the above

If the Key Usage doesn't match the operation, you need a different certificate or one without restrictive Key Usage extensions.

Verifying certificate assignment

In your AS2 platform's partner configuration, confirm:

Your signing certificate (private key) matches the public certificate you sent to your partner.
Your partner's encryption certificate (public key) is the one they actually sent you, not an older version.
The certificate serial numbers match between what you have and what your partner has.

Check serial numbers with:

openssl x509 -in cert.pem -noout -serial

5. Format Mismatches: PEM vs. DER vs. PKCS12

Certificate files come in several formats. Using the wrong format with your AS2 platform produces errors that look like certificate corruption or invalid data, not format errors.

The three formats you'll encounter

PEM (Base64 text, starts with -----BEGIN CERTIFICATE-----): Most common format. Used by OpenAS2, Mendelson, and most open-source AS2 implementations.
DER (binary): Used by some Java-based platforms and Windows. Same data as PEM, different encoding.
PKCS12 / PFX (binary, password-protected): Bundles the certificate and private key together. Common export format from Windows certificate stores and Java keystores.

Identifying the format

# Check if it's PEM (text-based)
file cert.pem
# Output: "PEM certificate" or "ASCII text"

# Check if it's DER (binary)
file cert.der
# Output: "data" or "DER Encoded Certificate"

Or just open it in a text editor. If it starts with -----BEGIN, it's PEM. If it's binary gibberish, it's DER or PKCS12.

Converting between formats

PEM to DER:

openssl x509 -in cert.pem -outform DER -out cert.der

DER to PEM:

openssl x509 -in cert.der -inform DER -outform PEM -out cert.pem

Extract certificate from PKCS12:

openssl pkcs12 -in keystore.p12 -clcerts -nokeys -out cert.pem

Extract private key from PKCS12:

openssl pkcs12 -in keystore.p12 -nocerts -nodes -out key.pem

Create PKCS12 from PEM certificate and key:

openssl pkcs12 -export -in cert.pem -inkey key.pem -out keystore.p12

Java KeyStore (JKS) note

Java-based AS2 platforms (like OpenAS2) use JKS keystores. To import a PEM certificate into a JKS keystore:

# First convert to PKCS12
openssl pkcs12 -export -in cert.pem -inkey key.pem -out temp.p12 -name myalias

# Then import PKCS12 into JKS
keytool -importkeystore -srckeystore temp.p12 -srcstoretype PKCS12 -destkeystore keystore.jks -deststoretype JKS

6. Key Size Requirements

Key size requirements have evolved. What was acceptable five years ago may be rejected today.

Current standards

1024-bit RSA: Rejected by most modern AS2 platforms. Considered insecure since 2013. If your certificates still use 1024-bit keys, replace them immediately.
2048-bit RSA: The current minimum for AS2 connections. Accepted everywhere. This is the safe default.
4096-bit RSA: Increasingly common, especially in regulated industries (pharma, healthcare, finance). Some partners now require it.
Elliptic Curve (EC): Not widely supported in AS2 implementations yet. Stick with RSA unless both sides explicitly support EC.

Checking key size

openssl x509 -in cert.pem -noout -text | grep "Public-Key"

Output: Public-Key: (2048 bit)

If you see 1024, generate a new key pair:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 730 -nodes -subj "/CN=YourAS2ID/O=YourCompany"

Use rsa:4096 if your partner requires it.

Putting It All Together: A Diagnostic Workflow

When you hit a certificate error, run through this sequence:

Check expiration. Is the certificate still valid? openssl x509 -in cert.pem -noout -dates
Verify format. Does your platform expect PEM, DER, or JKS? Convert if needed.
Check key size. Is it at least 2048-bit? openssl x509 -in cert.pem -noout -text | grep Public-Key
Verify Key Usage. Does the certificate allow the operation you're using it for?
Check chain of trust. Are intermediate certificates present and in the correct order?
Confirm assignment. Is the right certificate in the right slot (signing vs. encryption)?
Compare serial numbers. Does what you have match what your partner has?

This takes about five minutes. It will save you hours of email exchanges.

Automate the Checks with AS2 Certify

Every step in the workflow above is something you can do manually, and you should know how. But doing it for every trading partner, every time a certificate rotates, gets tedious fast.

AS2 Certify validates all of this automatically. Point it at your AS2 configuration and it checks certificate validity, key sizes, chain of trust, format compatibility, Key Usage extensions, and expiration windows. It sends a real AS2 message to your endpoint, verifies the signature, attempts decryption, and validates the MDN response. You get a graded report (A through F) telling you exactly what passed and what needs attention.

It catches the problems described in this guide before your trading partner does, which means fewer support tickets, faster onboarding, and no more surprise certificate expirations taking down production connections.

Run your first test at as2certify.org.