What the “47-Day Certificate” Change Really Means
If you manage AS2 connections, you may have heard claims that certificates will soon need to be renewed every 47 days — raising fears of constant outages, endless partner coordination, and operational chaos.
The good news:
This change is real, but it does not automatically apply to all AS2 certificates. Understanding which certificates are affected and which are not makes the situation far more manageable.
The short version (key points):
- AS2 message signing and encryption certificates are different and are usually not subject to this requirement.
- Most AS2 environments will not need to renew partner certificates every 47 days.
- The biggest risk isn’t cryptography — it’s certificate coordination and process discipline.
Where did “47 days” come from?
The CA/Browser Forum — the industry body governing public SSL/TLS certificates — approved a policy change that phases down the maximum lifetime of publicly trusted TLS certificates.
The phased timeline (high level)
- Today: ~398 days (about 13 months)
- March 2026: ~200 days
- March 2027: ~100 days
- March 2029: 47 days
This applies to publicly trusted certificates — the kind issued by commercial Certificate Authorities (CAs) and trusted automatically by browsers and operating systems.
Why this change exists
The goals are:
- Reduce the impact window of compromised private keys
- Limit long-lived mis-issued certificates
- Encourage automation instead of manual renewals
In short: shorter certificate lifetimes = lower security risk.
Why this causes confusion in AS2 environments
AS2 uses X.509 certificates, just like HTTPS — but they are used for different purposes. Many teams hear “certificates are going to 47 days” and assume all certificates must follow suit. That’s not how AS2 works.
AS2 uses two different kinds of certificates
1) TLS certificate (HTTPS transport)
- Secures the HTTPS connection to your AS2 endpoint
- Is presented during the TLS handshake
- Is usually issued by a public CA
If your AS2 endpoint is publicly reachable over HTTPS and uses a publicly trusted CA certificate, this certificate will eventually fall under the 47-day lifecycle.
Important: This certificate is typically not exchanged with trading partners the way AS2 signing certificates are. It behaves like any other web server certificate.
2) AS2 signing and encryption certificates (message-level security)
- Sign AS2 messages
- Encrypt AS2 payloads
- Validate Message Disposition Notifications (MDNs)
They are:
- Exchanged directly between trading partners
- Often self-signed or privately issued
- Commonly valid for 2–5 years
These certificates are not automatically subject to the 47-day rule.
Unless your organization (or a partner) explicitly mandates short-lived certificates for AS2 signing, they can continue to use longer validity periods.
The real AS2 challenge: coordination, not expiration length
AS2 certificate renewals are painful because both sides must act in sync.
Common failure points include:
- One side installs a new certificate while the other hasn’t
- Cutovers happen outside business hours
- Expired certs block messages silently
- Emergency renewals disrupt operations
The challenge isn’t how long certificates last — it’s how predictable and well-managed the renewal process is.
Best practice: treat certificate renewal as a window, not a moment
A reliable AS2 renewal process uses overlapping certificates.
A proven renewal approach
Generate a new signing/encryption certificate well before expiration (60–90 days).
- Share it with the trading partner early.
- Keep the old certificate active during the transition.
- Agree on a cutover date.
- Begin signing (and/or encrypting) with the new certificate.
- Retain the old certificate for validation until all in-flight messages are complete.
This approach avoids “flag day” failures and eliminates last-minute emergencies. Note: having two active certificates for a partner might not be practical or possible with most AS2 software packages. However, generating a separate local partner agreement attached to the new certificate when dealing with multiple trading partners allows for a transition period up to the ‘drop dead’ date when expiration of the original agreement occurs
What about partners who require CA-signed certificates?
Some organizations require CA-signed certificates for policy or compliance reasons. If that applies:
- TLS certificates should be CA-signed — this is standard.
- AS2 signing certificates may be:
- CA signed by a commercial CA, or
- Issued by a private CA, with the CA trust chain exchanged during onboarding
In closed B2B relationships, self-signed certificates are technically sufficient — trust is established by direct exchange, not browser validation.
Will AS2 really require 47-day renewals in the future?
For most organizations:
- TLS certificates: Yes, eventually — automation is essential.
- AS2 signing/encryption certificates: Only if your governance or partner requirements change.
There is no AS2 standard mandating 47-day signing certificates.
What AS2 teams should do now
1) Inventory your certificates
For each AS2 connection, document:
- TLS certificate (if applicable)
- Signing certificate
- Encryption certificate
- Expiration dates
- Renewal owner
- Supported overlap/rollover behavior
2) Automate TLS renewals early
The industry direction is clear. Manual TLS renewals will not scale.
3) Standardize partner renewal procedures
Make renewals boring and predictable:
- Clear notification timelines
- Overlap windows
- Test message validation
- Rollback plans
4) Decide where you want to manage complexity
Some teams choose to:
- Handle renewals in-house with strict SOPs, or
- Offload coordination to a managed service or VAN
Either approach works — as long as the process is intentional.
References used to create this article
- CA/Browser Forum – Ballot SC-081v3: Reduce Certificate Validity Periods (2025)
- CA/Browser Forum – TLS Baseline Requirements (current revision)
- DigiCert – Certificate Lifetime Reduction to 47 Days
- GlobalSign – 47-Day TLS Certificates: FAQs
AS2 Terminology used in this article:
AS2 (Applicability Statement 2)
A secure protocol used to exchange business documents (like EDI files) over the internet using HTTP or HTTPS.
CA (Certificate Authority)
An organization that issues digital certificates and vouches for the identity of the certificate holder.
Certificate
A digital file that contains a public key and identity information, used to secure communications and verify authenticity.
Encryption Certificate
A certificate used to encrypt AS2 message payloads so only the intended recipient can read them.
HTTPS
HTTP stands for Hypertext Transfer Protocol, and is a fundamental protocol used for data communication over the internet. HTTPS, with the addition of the S at the end indicates that the data is secured with TLS encryption.
MDN (Message Disposition Notification)
An electronic receipt confirming that an AS2 message was successfully received and/or processed.
Private CA
An internally managed certificate authority used within an organization or closed partner ecosystem.
Public CA
A commercial certificate authority whose certificates are trusted by browsers and operating systems by default.
Publicly Trusted Certificate
A certificate issued by a public CA that is automatically trusted by standard operating system or browser trust stores.
Self-Signed Certificate
A certificate that is signed by its own private key rather than by a CA. Trust is established by directly exchanging the certificate.
Signing Certificate
A certificate used to digitally sign AS2 messages, allowing the receiver to verify message integrity and sender identity.
TLS (Transport Layer Security) Encryption
The cryptographic protocol that secures over a computer network, such as the internet. It uses encryption algorithms to protect data during transmission.
TLS Certificate
The certificate used during a TLS handshake to secure a server’s HTTPS endpoint.
Trust Store
A collection of trusted CA certificates used by systems to validate incoming certificates.
X.509
The standard format used for digital certificates in TLS, AS2, and many other security systems.
Certificate Overlap (Rollover Window)
A period during which both the old and new certificates are valid to allow safe, coordinated transitions.
Certificate Fingerprint
A cryptographic hash of a certificate used to uniquely identify it and verify integrity.
