By the TrustPin engineering team · Published 10 October 2026 · About 6 minutes
The short version
ACM generates a new key pair at every renewal, so the SPKI pin changes every time. ACM certificates are regional, so a hostname served from several regions, or from CloudFront alongside regional load balancers, has several valid certificates with different pins. Pin all of them, pick up the renewed key as soon as ACM issues it, and drive the update from the ACM renewal event with a schedule as a backstop.
What ACM does at renewal
AWS Certificate Manager renews the public certificates it issued on its own, ahead of expiry, when the certificate is DNS-validated, its validation record is still in place, and it is in use by an AWS service or has been exported; email-validated certificates wait for the owner to approve the renewal. Each renewal produces a new certificate and a new key pair; ACM does not support reusing the previous key. The renewed certificate is then deployed to the integrated services that use it, such as CloudFront, Application Load Balancers and API Gateway, without any action on your side.
For a browser that is invisible. For an app that pins the public key, the renewed certificate presents a key the app has never seen. If the app pins strictly, connections fail; if it pins the certificate hash rather than the key, the same happens, because a certificate hash changes at every renewal anyway. The rotation runbook covers the general procedure; the ACM specifics are below.
One domain, several certificates
ACM certificates belong to a region. A CloudFront distribution uses a certificate from us-east-1; a load balancer in eu-west-1 uses one from eu-west-1; an API served from three regions behind latency-based routing has three certificates. Each has its own key pair, so the same hostname legitimately presents different public keys depending on which endpoint answered. An app that pins only the key it observed from one location will fail from another.
The pin set therefore has to contain the key of every certificate that can serve the hostname. Because every publicly trusted certificate is logged to Certificate Transparency at issuance, all of them are discoverable: the pin lookup tool lists them for any hostname, and the TrustPin CLI stages all of them in one step.
The pinning strategy that survives ACM
- Pin the SPKI hash, not the certificate. It identifies the key, which is what changes, and it is what every platform's pinning API expects.
- Pin every current key plus every newly issued key. The renewed certificate appears in Certificate Transparency when ACM issues it, so its pin can be staged as soon as it exists. AWS does not document a delay between renewal and deployment to the integrated services, so treat any gap as a bonus rather than a guarantee, and keep the old pin in the set regardless.
- Keep the old pin until its certificate expires. Devices that have not fetched the new configuration still succeed, and you keep a way back if a deployment is reverted.
- Update pins without a release. With a renewal every few months per region, a pin set compiled into the binary cannot keep up. Pins have to be updatable on the device, and the update has to be signed and verified so the mechanism does not become the weak point. That is what dynamic certificate pinning provides.
Should you pin the Amazon root CAs instead?
AWS's own guidance for pinning an ACM endpoint is to pin the Amazon Trust Services root certificates rather than the certificate ACM issued, because the roots stay fixed while the leaf key changes at every renewal. That works, and it survives renewals with no action on your side. The trade-off is scope: a root pin accepts every certificate those roots ever issue for your hostname, to anyone who passes ACM's domain validation, which is the exposure pinning exists to narrow. It is also a pin set of its own to maintain: several roots can sign an ACM certificate, all of them have to be in the set, and if the set lives in the binary, changing it is a release.
TrustPin takes the other path. The SDK verifies the leaf certificate's key against the pins, so trust stays narrow, and the renewal event refreshes the pin as soon as ACM issues the new certificate, so the reason to widen the pin disappears. The explainer covers the leaf-versus-CA question in general.
Reacting to the renewal event
ACM publishes an ACM Certificate Available event to Amazon EventBridge when a certificate is issued, renewed, imported or reimported. An EventBridge rule that matches renewals of your certificates can start a Lambda function that refreshes the project's pins and publishes a signed configuration. In the simplest form the function needs no access to the certificate itself: it runs the same lookup the pin tool uses, so it only needs the TrustPin API token and the signing credential, the master password for cloud-managed keys or the private key under Bring Your Own Keys, both read from AWS Secrets Manager.
{
"source": ["aws.acm"],
"detail-type": ["ACM Certificate Available"],
"resources": ["arn:aws:acm:eu-west-1:123456789012:certificate/..."],
"detail": { "Action": ["RENEWAL"] }
}trustpin-cli projects refresh-certs <org> <project> --domain api.example.com --remove-expired
# compare the project's configuration version before and after; sign only if it changed
# BYOK signs with the key fetched from Secrets Manager; cloud-managed keys use --password "$MASTER_PASSWORD" instead
trustpin-cli projects sign <org> <project> --private-key key.pem
trustpin-cli projects jws <org> <project> --verifyTwo details matter. Publishing an unchanged configuration is rejected by the API, so decide whether to sign from the configuration version, not from the command output. And an unattended function that signs publishes to every installed app with nobody watching; if that is not acceptable, stop after staging and put the signing step behind an approval. The CLI DevOps guide has the full AWS flow, including the SAM template and the permissions the function needs.
Keep a schedule as a backstop
The event names one certificate in one region. A scheduled run of the same refresh, every twelve hours or so, catches what the event does not: certificates in other regions, certificates on endpoints that are not ACM, and any event that was missed. A refresh that finds no new certificate changes nothing, a lookup that fails writes nothing, and the pipeline's version check skips the publish in both cases. The combination of event and schedule is what a production deployment ends up with.
If you use an AI coding agent, TrustPin's CI/CD skill writes the EventBridge rule, the function and the schedule for your repository; you review and deploy them.
Frequently asked questions
Does AWS Certificate Manager reuse the key when it renews a certificate?
No. ACM generates a new key pair at every managed renewal and does not offer key reuse. The SPKI pin therefore changes at every renewal, and a pinned app has to learn the new pin before the renewed certificate is deployed.
Can I pin a CloudFront distribution or an Application Load Balancer?
Yes, with the understanding that the pin belongs to the certificate on that endpoint, not to the domain. A CloudFront distribution's certificate lives in us-east-1; a load balancer's certificate lives in its own region. Each is a separate ACM certificate with its own key, so pin every endpoint that serves the hostname, and expect each one to renew on its own schedule.
How do I find out when ACM renewed a certificate?
ACM publishes an "ACM Certificate Available" event to Amazon EventBridge on issuance, renewal, import and reimport, with the certificate ARN in the event's resources and the kind of event in its detail. An EventBridge rule on that event can start a Lambda function that refreshes the pins. AWS documents the event in the ACM user guide; confirm the current shape there.