It’s Always a Friday

The pattern is predictable. A certificate was created 12 months ago. Nobody set a calendar reminder. The original developer moved to a different team. The certificate expires at midnight UTC. By 8 AM Monday (or more often, Friday afternoon), customers can’t authenticate to your API, and the on-call engineer is staring at a SEC_ERROR_EXPIRED_CERTIFICATE error wondering where to even start.

This scenario plays out constantly across Azure environments. Microsoft’s own service health dashboard shows certificate-related incidents regularly. If it happens to Microsoft, it happens to everyone.

What Breaks When a Certificate Expires

The blast radius depends on what the certificate was doing.

TLS/SSL certificates on App Services or Application Gateway:

  • Browsers show a full-page security warning. Users can’t proceed without clicking through scary warnings (if they even can).
  • API clients get hard TLS failures. No workaround, no retry.
  • Mobile apps that pin certificates stop working entirely.
  • If the certificate terminates at a load balancer or Application Gateway, every backend behind it goes dark.

App Registration client certificates:

  • The application can’t acquire OAuth tokens.
  • Every downstream API call that depends on those tokens starts failing with 401 Unauthorized.
  • If the App Registration is used by multiple services (common in microservice architectures), the failure cascades across services.

Key Vault certificates used for code signing or encryption:

  • Signing operations fail.
  • Encrypted data can still be decrypted (the key material remains), but new encryption operations using the certificate’s public key may be rejected by consuming applications that validate expiry.

Azure API Management certificates:

  • Backend authentication fails.
  • Client certificate validation fails.
  • Mutual TLS (mTLS) endpoints become unreachable.

Counting the Real Cost

The financial impact of an expired certificate goes beyond the obvious.

Direct costs

Downtime duration. The mean time to resolve a certificate expiry incident isn’t the 5 minutes it takes to generate a new certificate. It’s the 2-4 hours it takes to:

  1. Get paged and acknowledge the alert
  2. Figure out which certificate expired (if monitoring doesn’t tell you)
  3. Trace which applications are affected
  4. Determine who has permission to issue a new certificate
  5. Generate and deploy the replacement
  6. Verify that all consumers have picked up the new certificate
  7. Confirm the incident is resolved

For a customer-facing API doing 10,000 requests per hour at an average revenue of £0.01 per request, 4 hours of downtime costs £400 in direct lost revenue. Scale that to a larger operation and the numbers get painful fast.

Indirect costs

Customer trust. A TLS error is one of the most visible types of failure. Customers see it before your monitoring does. If they screenshot it and post it on social media, the brand impact is disproportionate to the technical severity.

Engineering time. The on-call engineer dropping everything to firefight a preventable incident. The incident review meeting. The action items. The toil of manually auditing certificates after the fact to see if there are more ticking time bombs.

SLA penalties. If you have contractual SLAs (99.9% uptime = maximum 43 minutes of downtime per month), a single certificate expiry incident can blow your monthly budget in one shot.

Compliance findings. Auditors check certificate management practices. An expired-certificate incident creates audit evidence that your controls aren’t working.

Why It Keeps Happening

Certificate expiry isn’t a new problem. So why does it keep catching teams?

Long lifetimes create false safety. A certificate with a 12-month validity feels like a problem for “future you.” By the time it matters, the context is gone.

No single owner. The person who created the certificate may not be the person responsible for renewing it. In many organizations, nobody is explicitly responsible for certificate lifecycle. It’s an implicit expectation that falls through the cracks.

Fragmented tooling. Certificates live in Key Vault, on App Services, in Entra ID App Registrations, in Application Gateway configs, and in API Management. There’s no single place that shows you every certificate and its expiry date across all these locations.

Alert fatigue. Even when alerts exist, they often fire too late (30 days before expiry) or get lost in a noisy monitoring channel. By the time someone pays attention, the window for a calm, planned renewal has closed.

Prevention Strategies

Short-lived certificates

The shorter the certificate lifetime, the smaller the blast radius of an expiry and the sooner you discover gaps in your renewal process. Consider:

  • 90-day certificates for TLS (Let’s Encrypt’s default). This forces you to automate renewal.
  • 6-month certificates as a middle ground for App Registration credentials.
  • Managed certificates wherever possible (App Service managed certificates auto-renew).

Automated renewal

Azure Key Vault supports auto-renewal for certificates issued by integrated CAs (DigiCert, GlobalSign). For certificates issued by other CAs, use the CertificateNearExpiry Event Grid event to trigger a renewal pipeline.

# Check if a Key Vault certificate has auto-renewal configured
az keyvault certificate show \
  --vault-name my-vault \
  --name my-cert \
  --query "policy.lifetimeActions"

Centralised inventory

You can’t renew what you don’t know about. Build (or use) a system that maintains a live inventory of every certificate across:

  • All Key Vaults in all subscriptions
  • All App Registration credentials in Entra ID
  • All App Service TLS bindings
  • All Application Gateway listeners

Layered alerting

Don’t rely on a single alert. Set up notifications at:

  • 90 days: Informational. Gives the owning team time to plan.
  • 30 days: Warning. Should trigger a renewal task.
  • 7 days: Critical. Escalate if renewal hasn’t happened.
  • Expired: Incident. Page the on-call.

The Difference Between Knowing and Doing

Most teams know they should manage certificates proactively. The gap is between knowing and having the tooling to actually do it across a real environment with dozens of vaults, hundreds of App Registrations, and multiple subscriptions.

CertifyClouds closes that gap. It discovers every certificate across your entire Azure estate, gives you a single dashboard with expiry timelines, sends configurable alerts at the thresholds that matter to your team, and (on the Pro tier) automates the renewal and rotation workflow end to end. The Starter tier is free for 30 days and scans up to 4 subscriptions.

Further Reading