AWS Certificate Manager (ACM) now issues public SSL/TLS certificates with a 398-day validity period, down from 13 months, to align with new industry standards. This change can silently break automation scripts that rely on hardcoded validity periods, but the fix is straightforward once you know where to look.

AWS Just Shortened Your SSL Certs. Here’s Why Your Automation Broke (And How to Fix It).

It was 11:37 PM on a Tuesday. PagerDuty did its thing, and my phone lit up the room. The alert? “CRITICAL: Deployment Pipeline for `internal-dashboard` Blocked.” I sighed, rolled out of bed, and logged in. The Jenkins runner, `deploy-runner-prod-03`, was spitting out an error that made no sense: “Certificate validity check failed: renewal required but not performed.” But that was impossible. I knew for a fact that the cert for `internal-dashboard.corp.techresolve.com` had been auto-renewed by ACM just last week. We had a script, a simple little Python check, that ensured no cert with less than 30 days of life made it into production. So why was it failing now? After a frantic 20 minutes of digging, I found it. A single, hardcoded line assuming a 13-month (395-day) certificate validity. The new cert? 398 days. The math was just slightly off, and it was enough to bring our entire internal tooling deployment to a grinding halt. Fun times.

So, What Actually Changed? The “Why” Behind the Pain

This wasn’t AWS just deciding to make our lives difficult. The change comes from the Certificate Authority/Browser (CA/B) Forum, the group that sets the rules for public SSL/TLS certificates. They passed a ballot (SC-063 v2, if you’re curious) that reduced the maximum validity period for all public certs from 397 days to 398 days, but most importantly, it effectively made the old 13-month certs obsolete. The goal is better security through faster key rotation. Shorter-lived certs mean a smaller window of opportunity for a compromised key to be exploited.

The problem is, many of us—and I’m guilty of this too—wrote automation years ago that made assumptions. We might have a script that checks if a certificate’s `ValidityPeriod > 365` days to decide if it’s a “standard” cert. Or, like in my case, logic that calculated remaining days based on a 13-month issuance. When AWS and the other CAs complied with the new standard, those assumptions broke. Your code, which was working perfectly, is now suddenly failing on brand-new certificates.

Fixing the Mess: From Band-Aids to Proper Surgery

Alright, you’re in the hot seat. The pipeline is red, and your manager is asking for an ETA. Here’s how you get things moving again, from the quick fix to the one you should actually implement.

Solution 1: The “It’s 2 AM” Quick Fix

This is the band-aid. The goal here is to get the system working, not to win any awards for elegant code. You find the script that’s breaking and adjust the hardcoded value. Let’s say you have a shell script that pulls the “Not After” date and does some simple math.

The Broken Logic (Bash Example):

# OLD SCRIPT - Assumes ~395 day validity
CERT_ARN="arn:aws:acm:us-east-1:123456789012:certificate/your-cert-id"
EXPIRY_DATE=$(aws acm describe-certificate --certificate-arn $CERT_ARN --query 'Certificate.NotAfter' --output text)
EXPIRY_EPOCH=$(date -d "$EXPIRY_DATE" +%s)
CURRENT_EPOCH=$(date +%s)
DAYS_LEFT=$(((EXPIRY_EPOCH - CURRENT_EPOCH) / 86400))

# The check that now fails on a newly renewed cert
if [ "$DAYS_LEFT" -gt 390 ]; then
  echo "OK: Certificate is fresh (more than 390 days remaining)."
else
  echo "ERROR: Certificate is either old or not a standard 13-month cert."
  exit 1
fi

The Quick Fix:

Just change the number. The new validity is 398 days. Adjust your check accordingly.

# QUICK FIX
# Just lower the threshold to something safe, like 366
if [ "$DAYS_LEFT" -gt 366 ]; then
  echo "OK: Certificate is fresh (more than 1 year remaining)."
else
  echo "ERROR: Certificate is approaching its first month anniversary."
  exit 1 # Or maybe don't exit, just warn
fi

This works. It gets the pipeline green. But it’s brittle. You’re just kicking the can down the road until the next CA/B Forum change.

A Word of Warning: Hardcoding magic numbers related to time (30 days, 365 days, 13 months) is a classic technical debt trap. What seems obvious today becomes a mystery landmine for the next engineer (or your future self) a year from now.

Solution 2: The Permanent (And Sane) Fix

The right way to do this is to stop checking the total validity period and instead focus on the actual expiration date. Your script’s only job should be to answer the question: “Does this certificate expire within our risk window (e.g., the next 30 days)?” That’s it. It shouldn’t care if the cert was issued for 90 days or 900 days.

Here’s how you’d rewrite that logic in Python, which handles datetimes much more gracefully.

import boto3
from datetime import datetime, timezone

def is_cert_expiring_soon(cert_arn, days_threshold=30):
    """
    Checks if an ACM certificate is expiring within a given threshold.
    This is the robust way to do it.
    """
    acm_client = boto3.client('acm')
    
    try:
        response = acm_client.describe_certificate(CertificateArn=cert_arn)
        expiration_date = response['Certificate']['NotAfter']
        
        # Ensure we have a timezone-aware datetime object for comparison
        now = datetime.now(timezone.utc)
        
        time_left = expiration_date - now
        
        print(f"Certificate {cert_arn} expires in {time_left.days} days.")

        if time_left.days < days_threshold:
            print(f"WARNING: Certificate expires in less than {days_threshold} days!")
            return True
        else:
            print("OK: Certificate has sufficient time before expiration.")
            return False

    except Exception as e:
        print(f"Error checking certificate {cert_arn}: {e}")
        return True # Fail safely

# --- Usage ---
CERT_ARN = "arn:aws:acm:us-east-1:123456789012:certificate/your-cert-id"
if is_cert_expiring_soon(CERT_ARN, days_threshold=21):
  # Trigger alert, stop deployment, etc.
  pass

This code doesn't care about the certificate's total lifespan. It only cares about the gap between "now" and the expiration date. If the CA/B forum changes the validity to 180 days tomorrow, this script will still work perfectly.

Solution 3: The 'Embrace the Chaos' Cloud-Native Option

Why are we even running a script on a cron job to check this? We're on AWS! We can do better. Stop polling for state changes and start reacting to events.

AWS EventBridge can natively capture events from ACM. One of those events is "ACM Certificate Approaching Expiration." This event fires automatically when a certificate enters its renewal window (typically 45 days before expiry for auto-renewed certs).

The architecture is simple:

1. EventBridge Rule: Create a rule that listens for the specific ACM event.
2. Target: Set the target of the rule to a Lambda function, an SNS topic for notifications, or even a Step Function for more complex logic.

Your EventBridge Rule pattern would look something like this:

{
  "source": ["aws.acm"],
  "detail-type": ["ACM Certificate Approaching Expiration"]
}

Now, your Lambda function receives the event payload, which includes the certificate ARN. It can then perform any action you need: send a detailed Slack message, create a JIRA ticket, or update a status page. No more cron jobs. No more polling scripts. You've replaced a brittle, imperative script with a resilient, event-driven workflow. This is the way.

Which Fix is Right for You?

Here's a quick breakdown to help you decide.

Ultimately, this little ACM change is a great reminder that the cloud is a dynamic environment. The assumptions we code today might not be valid tomorrow. Building resilient systems means avoiding hardcoded values, preferring event-driven patterns over polling, and always, always having a plan for when the PagerDuty alert goes off at midnight.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions