AS2 Certificates: Self-Signed vs CA-Signed Explained (2026)

AS2 Certificates: Self-Signed vs CA-Signed Explained (2026)

Self-signed and CA-signed AS2 certificates provide identical encryption strength. Self-signed is the AS2 default: free, fast, and secure when fingerprints are verified out of band. Choose CA-signed only when a trading partner, regulator, or industry network requires it. Most established B2B environments run both.

AS2 is one of the standard protocols for B2B communication, in use for more than two decades. Businesses use the AS2 protocol for exchanging all types of business documents, including orders, invoices, and shipment details. Its security relies on encrypting and signing messages with digital certificates, and when setting up your AS2 server, one question always comes up: self-signed or CA-signed?

The answer isn’t straightforward, and focusing on “one is more secure” misses the point. You’ll likely need both, and the best choice may change depending on your trading partner’s requirements and regulatory obligations.

This post explores each certificate type, how they fit into AS2 communication, and the operational considerations you should keep in mind.

Two Types of Certificates: Explained

AS2 uses certificates for two core functions:

1. Encryption: Keeping your message content private.
2. Digital Signatures: Verifying the sender’s identity and ensuring the message hasn’t been tampered with.

There are two primary ways to get these certificates:

Self-Signed Certificates

You generate and sign these yourself. Most of the time, AS2 software providers have this feature included in their software. (e.g., MFT Gateway / Mendelson) Your trading partners exchange certificates directly with you via secure channels (like encrypted email), then both sides import the public certificate, and communication can begin. This is the most common approach, as it’s cost-effective, simple, and well-established for B2B integrations.

CA-Signed Certificates

A recognized Certificate Authority (CA) issues these after verifying your organization’s identity. Since the CA is widely trusted, your partners gain an extra layer of confidence that the certificate is genuinely yours. This is particularly important when dealing with large corporations, government agencies, or highly regulated industries.

Why Many Businesses Start with Self-Signed Certificates

It’s a common misconception that all production AS2 environments must use CA-signed certificates. In reality, many successful setups run on self-signed certificates without any issues. This is how the AS2 protocol is designed.

Unlike HTTPS, which relies on a public web-of-trust model to establish trust between unknown parties, AS2 expects trading partners to exchange certificates proactively. Because both sides already know precisely which certificate they are trusting, a third-party validation isn’t inherently necessary. Self-signed certificates are typically ideal for organizations that:

• Have a limited number of trading partners.
• Enjoy long-term, stable business relationships.
• Communicate directly with partners.
• Have established and predictable integrations.

Plus, self-signed certificates are cheaper, faster to obtain, offer complete internal control, and keep you independent from external authorities. Many companies in manufacturing, logistics, retail, and supply chain sectors have successfully used this approach for years.

The Real Security Difference

The notion that CA-signed certificates offer inherently stronger encryption is a myth. Both types can use the same modern cryptographic algorithms (such as RSA or ECC) with current hashing standards, providing the same level of encryption security. The real distinction lies in identity verification.

Self-Signed: Security relies on the initial certificate exchange. If an attacker intercepts and replaces a certificate during this process, impersonation becomes a risk. However, this risk is significantly reduced when exchanging certificates via secure, out-of-band methods and verifying fingerprints before import.

CA-Signed: The CA verifies your identity before issuing the certificate, reducing the likelihood of impersonation during the initial trust-establishment phase. Once both sides have exchanged and verified certificates, ongoing communication security is practically identical.

In practice, the most common security vulnerabilities don’t stem from whether a certificate is self-signed or CA-signed. They usually come from:

• Expired certificates.
• Weak key lengths.
• Poor protection of private keys.
• Flawed certificate replacement procedures.
• Failure to revoke compromised certificates.

These operational weaknesses pose a far greater risk than the certificate type itself.

When Your Trading Partners Mandate CA-Signed Certificates

While self-signed certificates are still widely used, an increasing number of companies - especially large retailers, government entities, healthcare providers, banks, and enterprise procurement networks - require CA-signed certificates as part of their vendor onboarding. They often do this to streamline vendor management, simplify validation, or meet internal compliance requirements, rather than because they believe CA-signed certificates offer superior encryption. When a major trading partner dictates CA-signed certificates, it’s typically the most straightforward path to establish a connection, regardless of the technical pros and cons.

Can CA Signing Scale Economically?

For small numbers of trading partners, a CA-signed certificate is usually a negligible cost. However, this calculation changes as your partner network grows.

~50 Partners: Managing certificates is still relatively simple. You can use a single CA-signed certificate for partners who require it and a self-signed certificate for the rest, with minimal administrative overhead.

~200 Partners: Certificate lifecycle management becomes more crucial. You’ll need to track expiration dates, renewal cycles, partner notifications, and testing periods. Automation starts to provide significant value here.

~1000 Partners: Large enterprise AS2 environments may handle thousands of certificates. The operational burden of monitoring expirations, coordinating rotations, ensuring uptime, and maintaining partner records usually outweighs the cost of the certificates, prompting organizations at this scale to invest in centralized certificate management.

The Hybrid Approach: A Popular Choice

Many established B2B environments adopt a hybrid strategy: they use CA-signed certificates for major clients or regulatory requirements, self-signed certificates for their trusted long-term partners, and consistently apply the same robust internal security policies across both. This approach offers flexibility without unnecessary costs and accommodates trading partners with varying technical capabilities. Most AS2 servers, such as MFT Gateway, can support both types of certificates simultaneously, allowing each trading relationship to adhere to its specific, agreed-upon security protocol.

Operational Discipline Over Certificate Type

Ultimately, long-term success with AS2 depends more on strong certificate management than on the type of certificate used.

Monitor Expiration Dates: Certificate expiration is a leading cause of AS2 outages. Implement automated monitoring well in advance.

MFT Gateway has a built-in mechanism to notify users via email about the upcoming certificates that will expire in the next 2 weeks. In the UI, expiration dates are clearly visible, and creating or updating stations or partners for expired certificates is discouraged.

Rotate Certificates Proactively: Plan certificate rotations with your trading partners well before expiration. If possible, establish an overlap period where both the old and new certificates are valid.

MFTG offers this exact feature that allows users to set up a certificate scheduler where they can configure upcoming certificate rotations.

Protect Private Keys: Your signing private keys must remain confidential, stored securely (e.g., using encrypted storage or Hardware Security Modules if necessary).

MFTG leverages the security level of AWS services to ensure the highest level of protection for private keys stored in the MFTG.

Use Current Cryptography: Ensure your key lengths and signature algorithms meet modern industry standards, and retire outdated ones.

MFTG supports a wide range of signature/encryption algorithms.

Maintain Detailed Documentation: For each trading partner, record details such as the certificate owner, expiration date, fingerprint, contact information, rotation history, and encryption/signing settings. Comprehensive documentation simplifies onboarding and troubleshooting.

The MFTG’s modern UI allows users to manage all their certificates in one place. Generating self-signed certs and CSRs for CA authorities can be done easily from the UI without requiring extensive technical knowledge.

Frequently Asked Questions

Q1: Are self-signed AS2 certificates secure enough for production?

A1: Yes. AS2 was designed around direct certificate exchange between known partners, so third-party validation is not inherently required. Self-signed and CA-signed certificates support the same encryption algorithms and key lengths. Production security depends on verifying fingerprints during exchange and managing expiry, rotation, and private-key protection, not on who signed the certificate.

Q2: When do I need a CA-signed AS2 certificate?

A2: When a trading partner, industry network, or regulator requires one. Large retailers, government agencies, banks, and healthcare networks often mandate CA-signed certificates during vendor onboarding to simplify their own validation and compliance processes. If a major partner requires it, complying is almost always faster than debating the technical merits.

Q3: Is a CA-signed certificate more strongly encrypted than a self-signed one?

A3: No. This is the most persistent myth in AS2 security. Both certificate types can use identical modern algorithms such as RSA or ECC with current hashing standards. The only difference is identity verification at trust establishment: a CA vouches for who you are. After certificates are exchanged and verified, ongoing security is practically identical.

Q4: Can one AS2 server use both certificate types at the same time?

A4: Yes. Most AS2 servers, including MFT Gateway, support self-signed and CA-signed certificates simultaneously, assigned per trading partner. The common pattern is CA-signed for partners who mandate it and self-signed for trusted long-term relationships, with one internal security policy applied across both.

Q5: What causes most AS2 certificate failures?

A5: Expiry. Expired certificates are a leading cause of AS2 outages, ahead of weak keys, unprotected private keys, and botched rotations. Automated expiry monitoring, scheduled rotations with an overlap window, and per-partner documentation of fingerprints and renewal history prevent nearly all of them, regardless of certificate type.

Summary

Manage both certificate types from one place. Whether your partners demand CA-signed certificates or you run self-signed with fifty long-term partners, the failure mode is the same: expiry and rotation. MFT Gateway generates self-signed certs and CSRs from the UI, emails you two weeks before any certificate expires, and schedules rotations in advance. Start your free 30-day trial (no credit card) and import your first partner certificate in minutes.

Contact us to see how MFT Gateway can simplify certificate management for your AS2 integrations.