Certificates Kill More AS2 Connections Than Everything Else Combined

Wrong format. Wrong key size. Expired at 2am on a Saturday. Chain missing an intermediate. Self-signed when your partner expects CA-signed. You've seen at least one of these. Probably all of them.

Certificates handle two jobs in AS2: encryption (only the intended recipient reads the message) and signing (the recipient confirms the message came from you, untampered). When certificates are wrong, nothing works. No fallback. No graceful degradation. Just failure.

This checklist covers every validation you need to run before plugging a certificate into an AS2 connection. Print it. Bookmark it. Tape it to your monitor.

Format: PEM vs DER vs PKCS12

You'll hit three certificate formats in AS2 work. Know which one you're holding before you do anything else.

PEM (Privacy Enhanced Mail) — Base64-encoded text wrapped in -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- headers. Open it in a text editor. If you see readable characters, it's PEM. This is the most common format for certificate exchange.

DER (Distinguished Encoding Rules) — Binary format. Open it in a text editor and you get garbage. Some Java-based AS2 systems want DER. Same data as PEM, different encoding.

PKCS12 (.p12 or .pfx) — A password-protected container that bundles the certificate, private key, and intermediates into one file. Some AS2 systems import PKCS12 directly. Others need you to crack it open and extract the pieces.

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 bundle.p12 -clcerts -nokeys -out cert.pem

Extract private key from PKCS12:

openssl pkcs12 -in bundle.p12 -nocerts -out key.pem

Always verify the format before importing. Ten seconds with OpenSSL beats two hours debugging a cryptic error.

Key Size Requirements

RSA key sizes for AS2 in 2026. No room for debate here:

1024-bit — Reject immediately. NIST deprecated 1024-bit RSA in 2013. If a partner sends you a 1024-bit certificate, send it back. Don't configure the connection. Don't "try it and see."
2048-bit — Minimum acceptable. Most AS2 connections use this today.
3072-bit — NIST recommends this for data needing protection beyond 2030.
4096-bit — Maximum practical size. Slower handshakes, stronger security. Some large enterprises and government agencies mandate it.

Check the key size:

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

If the output reads Public-Key: (1024 bit), stop right there. Request a new certificate. Do not pass go.

Expiry: The Failure Nobody Sees Coming

Every certificate has an expiration date. When that date passes, your AS2 connection drops dead. Most systems give you zero warning. You find out when transactions stop flowing and someone upstream starts asking questions.

Check the expiry date:

openssl x509 -in cert.pem -noout -enddate

Output looks like notAfter=Mar 15 00:00:00 2027 GMT. Clean. Unambiguous.

Expiry Monitoring That Actually Works

Set calendar reminders at 90, 60, and 30 days before expiry. Yes, all three.
Automate it: a daily script checks every certificate and fires an alert when any are within 90 days of expiry.
Exchange new certificates with partners at least 30 days before the old one expires. Partners move slowly. Give them runway.
Test the new certificate in a non-production environment first. Every single time.
Keep the old certificate active until you confirm the new one works end-to-end. Don't cut over and hope.

One-liner to check every certificate in a directory:

for cert in *.pem; do echo "$cert: $(openssl x509 -in $cert -noout -enddate)"; done

Run this weekly. Put it in cron. Future you will be grateful.

Chain Validation

Your partner sends a CA-signed certificate. You import it. Connection fails with "certificate verification failed." Sound familiar?

The problem is almost always a missing intermediate certificate. Your system needs the full chain — from the partner's certificate up to a trusted root CA. Without the intermediates, it can't build that path, and it rejects the certificate.

The error message never says "you're missing an intermediate." It says "certificate verification failed" and leaves you to figure it out.

Check if the chain is complete:

openssl verify -CAfile chain.pem cert.pem

If it returns OK, you're good. If it returns unable to get local issuer certificate, you're missing an intermediate.

Where to get the missing intermediate: ask your partner. They should provide it. If they don't (or won't), look at the Authority Information Access (AIA) extension in the certificate — it usually contains a URL to download the intermediate from the CA.

Self-Signed vs CA-Signed

No universal rule here. Some AS2 connections use self-signed certificates. Others require CA-signed. It depends on your security policy and your partner's requirements. Confirm which one your partner expects before you generate anything.

Self-signed certificates — Free. Easy to generate. No third-party dependency. The tradeoff: your partner must explicitly trust your specific certificate. No chain of trust handles it automatically.

CA-signed certificates — Issued by a trusted Certificate Authority (DigiCert, Sectigo, Let's Encrypt, etc.). If your partner's system trusts the CA, it automatically trusts your certificate. The tradeoff: they cost money (Let's Encrypt is free but expires every 90 days), and you depend on the CA for issuance and renewal.

Either approach works for AS2. Just get alignment with your partner before you start generating keys.

Common Certificate Errors Decoded

"unable to decrypt message"

Your system is trying to decrypt with the wrong private key. You probably have multiple certificates configured and the wrong one is active. Or your partner encrypted with an old certificate that you already rotated out. Check which certificate your partner has on file for you. Match it to the private key your system is using.

"signature verification failed"

The certificate you have for your partner doesn't match the one they used to sign the message. They rotated their signing certificate and didn't tell you. Or you imported the wrong certificate for this partner. Get the current certificate from your partner and re-import.

"certificate has expired"

Exactly what it says. The certificate was valid when you configured it. Nobody set up monitoring. Now it's expired and everything is broken. Get a new certificate from your partner, update your configuration, and set up monitoring this time.

"unable to get local issuer certificate"

Incomplete certificate chain. You have the partner's certificate but not the intermediate CA certificate. Get the full chain from your partner or download the intermediate from the CA's repository.

"certificate not yet valid"

The certificate's "not before" date is in the future. First, check your system clock — NTP drift causes this more often than you'd expect. If the clock is correct, your partner issued the certificate with a future start date. Ask them to reissue, or wait.

The Validation Checklist

Run every item before configuring any AS2 connection. No exceptions.

Format — Identify PEM, DER, or PKCS12. Convert if your system needs a different format.
Readability — Can OpenSSL parse it? openssl x509 -in cert -text -noout. If this fails, the file is corrupt or not a certificate.
Key size — 2048-bit minimum. 1024-bit gets rejected on sight.
Expiry — Not expired. Not expiring within 30 days.
Algorithm — RSA or ECDSA. Avoid DSA.
Chain — If CA-signed, do you have all intermediates? Verify with openssl verify.
Key match — Does the public key match the private key? Compare: openssl x509 -noout -modulus -in cert.pem | md5sum must match openssl rsa -noout -modulus -in key.pem | md5sum.
Key Usage — Does the Key Usage extension allow digital signature and key encipherment?
Subject — Does the Common Name or Subject Alternative Name match the expected identity?

This whole checklist takes about five minutes. AS2 Certify runs every one of these checks automatically as part of a full connection test. It flags anything that doesn't meet current standards so you catch problems before they hit production — not after.