47-Day TLS Certificates: What They Mean for mTLS on AWS
Public TLS certificates shrink to 47 days and lose clientAuth. Learn the impact on ACM and partner mTLS on AWS, and your private CA options.
If you have bought or renewed a public SSL/TLS certificate recently, you probably noticed it is valid for about 200 days, where it used to be 398. This applies to every publicly trusted certificate, whether it comes from DigiCert, Sectigo, Let’s Encrypt or AWS Certificate Manager (ACM). The whole industry is reducing the maximum lifetime of public TLS certificates in stages, down to 47 days in 2029.
The focus here is AWS workloads; other clouds have different certificate services.
On AWS, how much the change affects you depends on where the certificate is used and who installs it:
| Setup | Effect of shorter lifetimes |
|---|---|
| Standard ACM public certificates (export disabled, the default), used on AWS services such as load balancers, CloudFront or API Gateway. AWS keeps the private key. | Small. ACM renews and deploys them automatically. |
| Certificates you install yourself together with their private key: ACM exportable public certificates, certificates from ACM’s ACME endpoint or another ACME CA such as Let’s Encrypt, or certificates bought from a commercial CA | Small if renewal and installation are automated, medium if someone in your team does them by hand. |
| Client certificates for mTLS with an external partner | Large. Every renewal needs the partner, and public certificates are also losing the clientAuth usage that mTLS depends on. |
Standard ACM certificates work only on AWS services, where they are free and renew automatically as long as they use DNS validation and stay attached to a service. When you need the private key, for servers in your own data center, a third-party gateway or a Kubernetes cluster, use an ACME client with Let’s Encrypt or ACM’s ACME endpoint , or ACM exportable certificates with automated export. Certificates bought from a commercial CA and renewed by hand go from about one renewal a year to about eight by 2029, but that work stays inside your own team.
Automating your own side does not solve the third case: the partner must also change its certificate. That is the focus of the rest of this article.
1. What changed, and why lifetimes keep getting shorter
In April 2025 the CA/Browser Forum passed Ballot SC-081v3 . It reduces the maximum validity of publicly trusted TLS certificates, and also how long a CA may reuse an earlier domain control validation (DCV), the check that you control the domain:
| Effective date | Max certificate lifetime | Max DCV reuse |
|---|---|---|
| Before 2026-03-15 | 398 days | 398 days |
| 2026-03-15 (in effect now) | 200 days | 200 days |
| 2027-03-15 | 100 days | 100 days |
| 2029-03-15 | 47 days | 10 days |
This continues a long trend. Before 2012 there was no common limit and certificates valid for five years or more were normal. The limit then went to 60 months (2012), 39 months (2015), 825 days (2018) and 398 days (2020). Browsers pushed the recent cuts because revocation does not work reliably and shorter lifetimes limit the time in which a stolen key or wrongly issued certificate can be used. Sections 2 and 3 explain who the CA/Browser Forum is, why it can set these limits, and why browsers want shorter lifetimes.
2. The CA/Browser Forum, and why it can set these limits
2.1 The CA/Browser Forum
The CA/Browser Forum is a voluntary group with two kinds of members. Certificate Issuers are the Certificate Authorities (CAs), such as DigiCert, Sectigo, GlobalSign and Let’s Encrypt. Certificate Consumers are the companies whose software decides whether to trust a certificate, mainly Google, Apple, Mozilla and Microsoft.
The Forum publishes the Baseline Requirements, the minimum rules every public CA must follow: how domains are validated, how long certificates may last, which extensions they may contain. It began around 2005, when validation practices varied widely between CAs.
2.2 Where the power comes from
The Forum has no legal authority of its own. Its rules work because of the root stores.
Every browser and operating system ships with a list of trusted root CA certificates. Google, Apple, Mozilla and Microsoft control much of the software that uses those lists: Google makes Chrome, Android and ChromeOS; Apple makes Safari, iOS and macOS; Mozilla makes Firefox; and Microsoft makes Windows and Edge. Because the list ships inside their products, each of them runs a root program that decides which CAs are on it. If any one of these four companies removes a CA’s root certificate from its root store, every certificate issued under it shows a full-page security warning on that company’s browsers or devices. No customer can accept that for, say, every iPhone or every Chrome user, so for a commercial CA a single removal ends the business.
CAs and browsers vote on Forum rules, but root programs can impose additional requirements. In a disagreement, a root program can set the effective rule for the certificates it trusts. That influence grew through responses to CA failures.
2.3 CA failures
The main cases where browsers stopped trusting a public CA:
- DigiNotar, 2011: The Dutch CA was hacked and the attacker issued hundreds of fraudulent certificates, including one for
*.google.comthat was used to intercept the traffic of users in Iran. DigiNotar knew about the intrusion for weeks before it became public. Browsers removed it and the company went bankrupt the same month. (EFF , Computerworld ) - WoSign and StartCom, 2016: Mozilla found a long list of problems, including backdated certificates to get around the SHA-1 deadline, and WoSign hiding the fact that it had bought StartCom. Mozilla and Google stopped trusting new certificates from both. (Mozilla )
- Symantec, 2017: Then one of the largest CAs, owning the VeriSign, Thawte, GeoTrust and RapidSSL brands. Investigations found large numbers of certificates issued without proper validation. Chrome removed trust in stages and Symantec sold the business to DigiCert. (Google , Mozilla )
- Camerfirma, 2021: Distrusted after years of compliance problems that were not fixed. (The Register )
- TrustCor, 2022: Removed by Mozilla, Microsoft and then Google after press reports linked it to spyware vendors. (TechTarget )
- Entrust, 2024: A large and long-established CA. Google stopped trusting its new certificates after a pattern of compliance failures, and Entrust later sold its public certificate business to Sectigo. (Google )
None of these CAs recovered. And in each case, once a CA had misbehaved, there was no reliable way to deal with the certificates it had already issued.
2.4 How browsers took control
After DigiNotar, Google engineers designed Certificate Transparency (CT). Public certificates must be written to public, append-only logs, and Chrome and Safari reject certificates that are not logged. Domain owners can watch the logs and see every certificate issued for their names, so mis-issuance can no longer stay hidden.
Browsers also stopped giving EV certificates special treatment. Public certificates were sold at three levels. For DV (Domain Validated) the CA only checks domain control. OV (Organization Validated) adds a check that the organization exists. EV (Extended Validation) is a stricter check of legal identity, and browsers used to reward it by showing the company name in green next to the URL. EV certificates cost much more.
In 2019 Chrome 77 and Firefox 70 removed the EV indicator . Google’s Chrome Security UX team had concluded from its own research and academic studies that the indicator did not change what users did. It could also be faked: in 2017 a researcher registered a company called “Stripe, Inc” in Kentucky for about $100 and bought an EV certificate for it for $77. Safari showed “Stripe, Inc” in the address bar, exactly as it did for the real payment company in Delaware. (Ars Technica , Simon Willison )
Since then DV, OV and EV certificates look the same in a browser. To the browser, a certificate only proves that the server controls the domain name. OV and EV checks can still matter for some contracts or compliance requirements, but users no longer see them, and CAs lost one of their most profitable products.
The longest fight was over lifetimes. In 2019 Google proposed Ballot SC22 to cut the maximum lifetime to about a year. All browsers voted for it and the CAs voted it down .
In February 2020 Apple announced that Safari would not trust certificates issued after 1 September 2020 with a validity over 398 days . There was no vote. Safari runs on every iPhone and Mac, so CAs had to comply, and the other browsers adopted the same limit. (ZDNet )
In 2025 Apple proposed the 47-day schedule. This time a CA, Sectigo, sponsored it, and it passed with no votes against . After 2020 the CAs knew the browsers could impose the change through their root programs if the ballot failed.
3. Why not rely on revocation?
Certificates already have a way to be withdrawn before they expire: revocation. If it worked well, lifetimes would matter much less.
There are two mechanisms. With a CRL (Certificate Revocation List), the CA publishes a list of revoked serial numbers for clients to download. With OCSP (Online Certificate Status Protocol), the client asks the CA’s server about a specific certificate during the connection.
Both work badly in practice. If the client cannot reach the CRL or OCSP server, most clients continue anyway (soft-fail), and an attacker who can intercept the connection can usually block the check too. In 2012 Google engineer Adam Langley called soft-fail checks “a seat-belt that snaps when you crash” , and Chrome replaced online checks with its own centrally distributed list. Checks also add latency to the handshake, and OCSP tells the CA which sites each user visits. Privacy was one of the main reasons Let’s Encrypt shut down OCSP in August 2025 .
Without reliable revocation, the expiry date is the only dependable limit on a stolen key or a wrongly issued certificate. That is the main argument for short lifetimes. A compromised certificate valid for 47 days is useful to an attacker for about an eighth as long as one valid for 398 days.
There are two further arguments. A certificate only proves someone controlled the domain when it was validated. Domains change hands, DNS records change, and cloud resource names are reused, so limiting the reuse of domain control validation to 10 days keeps that proof recent. And lifetimes this short make manual renewal impractical. Once renewal is automated everywhere, the ecosystem can react quickly when a CA has to be distrusted or an algorithm has to be replaced, for example in a move to post-quantum cryptography. Certificates renewed by hand once a year cannot be replaced quickly.
4. How Let’s Encrypt made short lifetimes practical
Let’s Encrypt was announced in November 2014 by the Internet Security Research Group (ISRG), a non-profit backed by Mozilla, the EFF, the University of Michigan and others, and began issuing certificates in late 2015.
It was created to get more of the web onto HTTPS, not in response to the CA failures. Certificates cost money, and the EFF found that installing one by hand typically took a developer one to three hours. Let’s Encrypt made certificates free and automated issuance through a new protocol, ACME (Automatic Certificate Management Environment), now an IETF standard (RFC 8555) that most CAs support.
It also changed the balance between browsers and CAs. Its certificates have always been valid for only 90 days, and it became the largest CA on the web by number of certificates. That showed short lifetimes work at very large scale, and ACME gave everyone a free way to automate renewal. When browsers pushed for shorter lifetimes, CAs could no longer argue that customers would not cope.
Let’s Encrypt is still ahead of the rules:
- It is reducing its default lifetime from 90 to 45 days , in stages until 2028.
- 6-day certificates and certificates for IP addresses are generally available . IP address certificates are only offered with the short lifetime.
- It shut down OCSP in 2025.
- It no longer issues certificates with the TLS Client Authentication EKU . This was removed from the default profile on 11 February 2026, and the temporary
tlsclientprofile was retired on 8 July 2026.
5. The second change: clientAuth is leaving public certificates
5.1 What mTLS is
In normal TLS only the client verifies the server. Your browser checks that the certificate matches the domain and chains to a trusted root, but the server does not learn who the client is at the TLS layer. If it needs to know, it uses a password, an API key or an OAuth token at the application layer.
Mutual TLS (mTLS) adds the other direction. The client also presents a certificate and proves it holds the private key, and the server checks it during the handshake, before any application data is sent.
It is mostly used between machines:
- APIs between organizations, such as a company and a payment provider, bank or partner. Many payment and open-banking standards require it.
- Traffic between services inside a company, for example in a service mesh or a zero-trust network.
- Devices and clients such as IoT devices, company laptops and VPN clients.
Compared with an API key, the secret is never sent over the network, a stolen certificate is useless without its private key, and the key can be kept in hardware or a secrets store. Clients without a valid certificate are rejected before they reach the application.
The external-partner case is the focus here because renewal requires people in two organizations.
The handshake has one certificate check in each direction:
On AWS, the server side of this is supported directly. An Application Load Balancer in mTLS verify mode checks client certificates against a trust store that holds your CA bundle, and API Gateway does the same for Regional custom domain names with a trust store file in S3. Your own server certificate can still be a normal ACM certificate that renews automatically. The difficult part is the client certificate the partner presents.
5.2 What clientAuth is
A certificate can contain an Extended Key Usage (EKU) extension that lists permitted uses. Two values matter here.
serverAuth (TLS Web Server Authentication) identifies a server and is the EKU browsers expect for HTTPS. clientAuth (TLS Web Client Authentication) identifies a client; a server may enforce it when validating a client certificate.For many years public CAs included both values by default. So many organizations used an ordinary public certificate, bought for a domain name, as the client certificate in mTLS. The partner already trusted the public roots, and nobody had to run a private PKI (Public Key Infrastructure: their own CA and certificate setup).
5.3 Why it is being removed
The Chrome Root Program now requires public TLS hierarchies in its root store to be used for server authentication only.
The public Web PKI exists to tell browsers whether a server is the real one for a domain. Client authentication is a different relationship, usually between two specific organizations, and it does not need public trust. Keeping both in one hierarchy also means every change made for the web, such as 47-day lifetimes, breaks the non-web uses, and the non-web uses make the web rules harder to change. Separating them lets each change on its own schedule. A certificate with fewer allowed uses is also less useful to an attacker who steals it.
- 2026-06-15: new subordinate CAs added to the Chrome root store must be
serverAuth-only. - 2027-03-15: all newly issued public TLS leaf certificates must be
serverAuth-only.
5.4 Failures happen at renewal
Nothing breaks on the day the rule takes effect. A certificate you already have keeps working until it expires. The trouble starts at the next renewal. The new certificate, from the same CA and for the same domain, has only
serverAuth. It gets installed as the mTLS client certificate as before. If the server on the other side checks the EKU, it rejects the certificate during the handshake. Nothing warns you beforehand. The chain is valid and the dates are valid; only the EKU is wrong.Whether the server checks depends on its TLS implementation and configuration. Some servers and API gateways do not check the EKU on client certificates, so a
serverAuth-only certificate may keep working, and you can test whether yours does. It is not a safe basis for a design, though. It depends on software and configuration on the other side that you do not control and that can change with any upgrade.6. A different public CA does not solve partner mTLS
Both changes apply to every publicly trusted CA. The main providers’ positions:
| Provider | Shorter lifetimes | clientAuth in public TLS certificates |
|---|---|---|
| DigiCert | Promotes automated certificate lifecycle management (CLM) and ACME (details) | Removed from 1 March 2027 |
| Sectigo | Sponsored the 47-day ballot; promotes automation and its CLM platform | Off by default since 15 September 2025; removed completely by February 2027 |
| GlobalSign | Promotes automation; estimates about 12 times more renewal events than with 398-day certificates | Following the Chrome Root Program timeline |
| Let’s Encrypt | 90 days now, 45 days by 2028; 6-day certificates available | No longer issued since 8 July 2026 |
| AWS ACM | 198-day public certificates with managed renewal | Not issued since 11 June 2025 |
The public providers are responding with renewal automation, not a long-lived public
clientAuth product. A partner mTLS design therefore needs a private trust relationship rather than a different Web PKI provider.7. Options for mTLS client certificates on AWS
7.1 Why partner mTLS breaks
A client certificate shared with an external partner usually works like this:
Each renewal needs both organizations. Someone exports the new certificate, sometimes with its private key, and sends it over. The partner schedules a change, installs it, and both sides test. With 47-day public certificates, renewal can be required up to eight times a year, depending on the renewal policy. A missed change can interrupt the integration. From March 2027, public CAs also will not issue
clientAuth certificates.7.2 What every option has in common
Each option creates a private trust relationship: the server operator adds the agreed root or intermediate certificate to its trust store. That certificate is public information, not a secret, and can remain trusted for years. Browser root programs and CA/Browser Forum rules for public Web PKI do not govern this relationship. Client certificates can include
clientAuth, and no industry rule limits their lifetime. A certificate from your own CA can last as long as the CA itself, and X9 PKI certificates can last up to three years. You could issue a ten-year certificate, but if its key were stolen, it would stay usable for ten years. That is the risk short lifetimes exist to limit, so choose a lifetime your security policy accepts.The partner should generate the private key and send only a Certificate Signing Request (CSR). The key then remains with the partner rather than being sent between organizations.
7.3 The options
| Option | Cost model | Partner trusts | Fits when |
|---|---|---|---|
| AWS Private CA | $400 per CA per month, plus a per-certificate fee | A root or intermediate you control | You need a managed CA with IAM, CloudTrail and an API, or issue enough certificates to justify the fixed CA charge |
| DigiCert X9 PKI | Commercial per-certificate pricing | The shared X9 root | You need a small number of certificates, or partners already use X9, particularly in finance |
| Hosted private CA from a CA vendor, such as DigiCert or Sectigo | Quote-based | A root dedicated to you | You already use that vendor’s certificate management platform |
| Self-hosted CA, such as step-ca, HashiCorp Vault PKI or EJBCA | Software may be free or open source; operational cost includes running the service and protecting CA keys | A root or intermediate you control | Your team can operate a PKI or already runs Vault |
AWS Private CA has a fixed monthly CA charge, while commercial and self-hosted options have different pricing and operating models. Compare the total cost against the number of certificates, required integrations, key-protection requirements, and the operating responsibility your team accepts. X9 uses a shared root, so a relying partner must validate the certificate identity as well as its chain.
AWS Private CA can issue a
clientAuth certificate from the EndEntityClientAuthCertificate/V1 template against a partner CSR through the IssueCertificate API . Treat expiry tracking and renewal as part of the integration: ACM does not renew certificates issued this way .8. Plan the migration
Use ACM for public server certificates on AWS services that support it. DNS-validated certificates attached to those services renew automatically. For certificates whose private keys must be exported, automate issuance, export, installation, and renewal with ACM, ACME, or the CA’s tools.
For partner mTLS, inventory the certificates whose renewal depends on a person in either organization. Test whether the receiving server enforces
clientAuth, then agree on a private trust relationship, certificate lifetime, CSR exchange, renewal process, and identity checks before the next public-certificate renewal.References
Industry rules
- CA/Browser Forum Ballot SC-081v3: schedule for reducing validity and data reuse periods
- Chrome Root Program
- Apple: limits on trusted certificates (398 days)
Public CAs on shorter lifetimes and
clientAuth- DigiCert: 47-day TLS certificates , removing the client authentication EKU , X9 PKI for mTLS
- Sectigo: preparing for 47-day certificates , TLS client authentication changes in 2026
- GlobalSign: what 47-day certificates mean for security teams
- Let’s Encrypt: decreasing certificate lifetimes to 45 days , ending TLS client authentication , OCSP end of life
AWS
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article