Migrating 180+ Public Certificates to AWS ACM Exportable Certificates

Managing 180+ public TLS certificates through a third-party CA sounds manageable until renewal cycles shrink from yearly to every 200 days. This post breaks down what it takes to migrate a large certificate estate to AWS ACM exportable public certificates — the pricing math, the automation architecture, and the limitations you need to know before committing.

The Problem

A large enterprise manages two types of public certificates:

• ACM non-exportable certificates — attached to ALBs and CloudFront distributions, auto-renewed for free by AWS. No operational burden.
• Third-party CA certificates — 180+ certificates managed manually, used for infrastructure outside AWS: on-premises servers, third-party vendor systems, and hybrid environments.

The manual approach worked when certificates were valid for 398 days. Two industry-wide changes are about to break it:

• March 2026: The CA/Browser Forum (Ballot SC-081) reduces maximum certificate validity to 200 days (down from 398).
• May 2026: Mutual TLS (mTLS) will be deprecated for public certificates, pushing internal use cases toward private certificates.

With 180+ certificates and validity cut in half, manual renewal becomes a full-time job. The team needs automation — and ACM exportable public certificates look like the answer.

The Solution

Replace the third-party CA with ACM exportable public certificates. ACM handles issuance, renewal, and notifications. An EventBridge + Lambda pipeline automates the export and distribution of renewed certificates to external systems.

The critical insight: ACM’s responsibility ends at the ExportCertificate API call. Everything after that — secure distribution, installation on external systems, tracking which vendors hold which certificates — is on you.

How It Works

ACM Exportable Certificates — The Basics

ACM exportable public certificates are standard X.509 TLS certificates with one key difference from regular ACM certs: you can export the certificate and its private key via the ExportCertificate API. This makes them usable on any system, not just AWS services.

Key characteristics:

• 198-day validity period — already under the upcoming 200-day industry limit
• Auto-renewal 45 days before expiration — roughly every 153 days in practice
• EventBridge notifications on certificate state changes (issued, renewed, expiring, expired)
• Domain validation — same DCV process as standard ACM certificates

Since ACM already issues certificates at 198-day validity, the March 2026 industry change has zero impact on ACM-issued certificates. Third-party CA certificates currently issued at 398 days will be impacted — that’s the forcing function for migration.

Pricing Reality

ACM charges per certificate at issuance and at each renewal:

Certificate Type	Per Issuance/Renewal	Renewals/Year (~153-day cycle)	Annual Cost
Standard FQDN	$7	~2.4	~$14–17
Wildcard	$79	~2.4	~$158–190

For a fleet of 180 standard FQDN certificates: ~$2,520–3,060/year.

Export API calls add negligible cost: the first 10,000 calls/month are free, then $0.50 per 10,000. With 180 certificates renewed every ~153 days, that’s roughly 430 export calls/year — well within the free tier.

The critical cost question is the standard vs. wildcard mix. If even 10 of those 180 certificates are wildcards, the annual cost jumps by ~$1,600–1,900. Get the cert breakdown before building the business case.

The Automation Pipeline

The real value of ACM exportable certificates isn’t the certificate itself — it’s the automation you can build around the renewal lifecycle:

ACM auto-renews certificate (day ~153)
  → EventBridge emits certificate state change event
    → Lambda function triggers
      → Calls ExportCertificate API (cert + private key)
        → Distributes to target systems via secure channel
          → Logs deployment status

The EventBridge event contains the certificate ARN, which Lambda uses to call ExportCertificate. The API returns the certificate chain and private key in PEM format. From there, your Lambda pushes the renewed certificate to wherever it needs to go — SFTP, vendor API, Secrets Manager for on-premises agents to pull, etc.

This is the pattern that replaces manual renewal. Instead of a human tracking 180 expiration dates and re-issuing through a CA portal, ACM renews automatically and your pipeline handles distribution.

What ACM Does NOT Do — S/MIME

ACM is specifically designed for SSL/TLS server authentication certificates. It does not issue S/MIME certificates (used for email signing and encryption). These are fundamentally different certificate types with different key usage extensions.

If your organization needs S/MIME:

• AWS Private CA can issue S/MIME certificates using blank templates (BlankEndEntityCertificate_APIPassthrough/V1) with EMAIL_PROTECTION extended key usage
• Cost: $400/month per CA + $0.75 per certificate — only makes sense if you have broader internal PKI needs
• Trust limitation: Recipients outside your organization won’t trust your private CA. For external email encryption, you still need a publicly trusted CA

The recommendation: keep your existing CA for S/MIME. Migrate only SSL/TLS public certificates to ACM. Don’t try to consolidate fundamentally different certificate types into a single solution.

Monitoring and the Post-Export Visibility Gap

This is the gotcha that doesn’t show up in the ACM documentation overview.

What ACM monitors (AWS side):

Signal	Source	What You See
API calls	CloudTrail	Who exported, when, from which IP, which certificate ARN
State changes	EventBridge	Certificate issued, renewed, expiring, expired
Export metering	ACM billing	Number of ExportCertificate calls

What ACM does NOT monitor:

• Certificate usage on non-AWS systems — once exported, ACM has zero visibility
• Whether a third-party vendor actually installed the renewed certificate
• Private key compromise on external systems
• Certificate revocation needs from vendor-side incidents

The ExportCertificate API is a one-way door. After export, the certificate is a standard X.509 file. ACM can’t “call back” to check on it. This means your organization is responsible for:

1. Securely transferring the exported cert + private key to each vendor
2. Tracking which vendors hold which certificates (a mapping ACM doesn’t maintain)
3. Re-distributing after every renewal cycle (~every 153 days)
4. Revoking certificates if a vendor relationship ends

For 180+ certificates, some going to third parties, this post-export lifecycle management is the real operational challenge. The automation pipeline from the previous section handles re-distribution, but you still need an inventory system to track the cert-to-vendor mapping.

Security Considerations for Exported Private Keys

Every ExportCertificate call returns the private key. That key leaving AWS means shared responsibility kicks in hard:

• IAM policies: Restrict who can call ExportCertificate — use condition keys to limit by certificate ARN, source IP, and MFA requirement
• Transit encryption: Never transfer cert + key over unencrypted channels. Use encrypted SFTP, TLS-protected APIs, or store in Secrets Manager for secure retrieval
• Audit trail: CloudTrail captures every export — integrate with your SIEM for anomaly detection (unexpected export times, unknown source IPs, bulk exports)
• Key rotation: With 198-day validity and auto-renewal, keys rotate naturally. But if a key is compromised mid-cycle, you need a process to re-issue immediately

What I Learned

• ACM is already ahead of the industry — with 198-day validity, ACM certificates won’t be affected by the March 2026 CA/Browser Forum changes. Third-party CA certificates issued at 398 days will. This alone is a compelling migration driver.
• The real cost variable is wildcard vs. standard — a fleet that looks cheap at $7/cert becomes expensive fast if wildcards are involved at $79/cert. Always get the exact cert type breakdown before building the business case.
• Post-export is where the complexity lives — ACM handles issuance and renewal beautifully. But the moment a certificate leaves AWS via ExportCertificate, you own the entire lifecycle: distribution, tracking, rotation confirmation, and revocation. This is the part most teams underestimate.
• S/MIME is a separate problem — don’t try to consolidate SSL/TLS and S/MIME into ACM. They’re different certificate types with different trust models. Keep your existing CA for S/MIME and migrate only TLS certificates.
• EventBridge + Lambda is the automation backbone — the pattern is straightforward (renewal event triggers export and distribution), but the “last mile” — actually deploying to each vendor’s system — requires per-vendor integration work that can’t be generalized.

What’s Next

• Build a PoC with ACM exportable certificates in a sandbox account — validate the full EventBridge + Lambda + export + deploy pipeline
• Map the certificate estate: standard FQDN vs. wildcard, per-vendor distribution, renewal frequency
• Design the cert-to-vendor inventory system that ACM doesn’t provide
• Evaluate AWS Private CA for internal mTLS use cases before the May 2026 deprecation deadline
• Cost comparison: current third-party CA spend vs. projected ACM exportable cost (including Lambda execution and data transfer)