AWS Secrets Manager vs. Certificate Manager: Which Should Hold Your Certificates?
You have a certificate and a private key that need to end up somewhere your servers can reach, and AWS has two services whose names both sound like the right answer.
AWS Certificate Manager (ACM) is where certificates come from and where they get replaced. You ask it for one, it deals with the certificate authority and with proving you own the domain, and it reissues automatically before the old one expires so nothing goes down at 2am.
AWS Secrets Manager is a safe for sensitive strings. It encrypts whatever you put in, logs every read, and lets you say through IAM exactly which roles can open it. It will hold a certificate and a private key perfectly well. It has no idea that is what they are.
They are not competitors, and the honest answer is that certificates belong in ACM. The only reason the question gets asked is that ACM spent years refusing to hand the files to anything outside AWS, so teams put the PEM in Secrets Manager to get it onto their own servers. That changed in 2025.
| AWS Certificate Manager | AWS Secrets Manager | |
|---|---|---|
| What it holds | Certificates, as objects with a domain, a chain, and an expiry date | Any string up to 64 KB. A certificate is just text to it |
| Knows when it expires | Yes. Daily EventBridge events from 30 days out, 45 for private and imported certificates | No. Nothing parses the value |
| Renewal | Automatic for certificates ACM issued. None for imported ones | A Lambda function you write, on a schedule you set |
| How a workload gets it | An AWS service reads it directly, or you export the files | Any IAM role with permission calls GetSecretValue |
| Cross-account | Not possible for the certificate itself | A resource policy on the secret grants another account access |
| Price | Free for the standard kind. Exportable and ACME certificates are charged per domain | $0.40 per secret per month, plus $0.05 per 10,000 API calls |
If AWS terminates your TLS, you are done
An ACM certificate deploys itself to the AWS services ACM is wired into: Elastic Load Balancing, CloudFront, EKS, Cognito, Elastic Beanstalk, App Runner, API Gateway, Nitro Enclaves, CloudFormation, Amplify, OpenSearch Service, and Network Firewall.
Check your service against that list, because if it is there the decision is made. The certificate costs nothing, ACM renews it, and the load balancer starts serving the new one without anybody being paged. Nothing about Secrets Manager improves on that.
This works for a certificate you bought elsewhere too. Import it into ACM and every service above accepts it, with two asterisks. ACM will not renew what it did not issue, so you watch the expiry date and reimport by hand, in each region that uses it and in us-east-1 for CloudFront. And import is a one-way door: ACM will hand an imported certificate to a load balancer but will not hand it back to you, so importing does nothing for a workload you run yourself.
If you terminate TLS yourself, ACM can now give you the files
Nginx on an EC2 instance wants two files in a directory. So does a container terminating its own TLS, a self-managed Kubernetes ingress, or a box in a colo. None of them can read from ACM, and by default the private key is generated inside AWS and never comes out, so for years the workaround was to get a certificate elsewhere and keep it in Secrets Manager, where at least it was encrypted, audited, and covered by IAM.
ACM now has two ways to hand over the files directly.
Exportable certificates, since June 2025, can be downloaded with their private key under a passphrase you set. ACME, the protocol behind Let's Encrypt, is now served by ACM's own ACME server, so a standard client like certbot or cert-manager running on your machine can request publicly trusted Amazon certificates and write them straight to disk.
| Standard | Exportable | ACME | |
|---|---|---|---|
| Where it works | Integrated AWS services only | Anywhere | Anywhere, but not on integrated AWS services |
| Who holds the private key | AWS only | AWS, and you after export | Your ACME client. AWS never sees it |
| Validity | 198 days | 198 days | 45 days |
| Who renews | ACM, invisibly | ACM, then you redeploy the files | Your ACME client |
| Price | Free | $7.00 per domain, $79.00 per wildcard, charged at issuance and again at every renewal | $1.00 per domain for the first 1,000 a month, less above that. Wildcards $5.00 |
AWS services refuse certificates issued through ACME, so an ALB terminating public traffic with encrypted connections continuing to nginx behind it needs two ACM certificates of different kinds for the same domain. And a certificate created before 17 June 2025 cannot be exported at all, so switching means reissuing it, which returns a new ARN that anything pointing at the old one has to be updated for.
Between the two, prefer ACME wherever you can run a client, because renewal and deployment then happen in the same place. Exportable certificates leave you owning the redeployment step and paying again at every renewal.
What Secrets Manager will not do for a certificate
If a certificate still has to live in Secrets Manager, you have to manually manage two jobs:
- Monitor certificate expiry. Every certificate carries its own expiry date inside it, in a field called
notAfter. Tools that understand certificates read it, but Secrets Manager doesn’t understand certificates. A secret holding an expired cert looks exactly like a secret holding a valid one. You can build a job that reads each secret, parses the PEM, and alerts on the date, but that’s another maintenance job. - Rotating the certificate does not update the running server. Rotation works for a database password because applications constantly ask for the password. Certificates are read at startup and are served until something reloads the process. You can have a valid certificate inside Secrets Manager and still be handing users the old one.
Secrets Manager wasn’t built to manage certificates. Storing certificates inside it will always be a workaround.
Should you move the certificates you already have?
Secrets Manager is not the “correct” place for certificates, but it can deliver certificates where they need to end up. As your estate of certificates grows (and especially as it grows far beyond AWS), this solution becomes untenable. Public certificate lifetimes are also shrinking to 47 days, so getting certificate management right is becoming important.
As complexity increases, you should probably move to a certificate management system which can:
- Discover which certificates already exist
- Issue new certificates
- Automatically track expiries and alert you
- Automatically renew certificates close to expiry
And do all of this in a system that works across all of your infrastructure. Infisical Certificate Management is one way to do this.
Where Infisical fits
No AWS service can reach certificates on network hardware, on-premises servers, or in another cloud. Infisical Certificate Management lets you automate certificate discovery, issuance, renewal, and every other part of the lifecycle across any infrastructure.
Certificates come from a private CA you define or an external authority including ACM's public CA and Let's Encrypt, and workloads request them over ACME, EST, SCEP, or the API.
It works directly with your existing AWS services: A certificate sync delivers a certificate to a destination and delivers every renewal after it, and both AWS Certificate Manager and AWS Secrets Manager are destinations.
To start automating your certificate management, sign up today or talk to an expert about your use case.
