Expiring certificates and secrets that silently break hosted applications

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.

Direct answer: A hosted application can lose a working dependency when a certificate expires, a provider expires or revokes an application secret, or a key rotates before its consumers are updated. X.509 certificates have notBefore and notAfter validity fields; API keys, client secrets and other signing material have provider-defined expiry, revocation and rotation rules rather than a universal notAfter field. Steady-state operations need a cross-app inventory that ties each hostname, service principal and secret to owners, renewal method and dependent connection strings—not a one-off IIS or load-balancer renewal project.

Expiry feels silent because clients cache trust, health checks hit a different endpoint, or only overnight batch jobs use the expiring credential.

Why it matters

A single expired TLS certificate on an integration tier can present as “application down” while the web tier still answers. Mutual-TLS partners, SAML signing certs, OAuth client secrets, database passwords in connection strings, and platform-managed certificates on PaaS slots all share the same failure mode: authentication or trust breaks without a configuration change anyone remembers making.

For platform owners, calendar risk is uneven. CA/Browser Forum TLS Baseline Requirements v2.3.1, dated 4 October 2026 sets a 200-day maximum for publicly trusted TLS server certificates issued from 15 March 2026 to before 15 March 2027. The scheduled maximum becomes 100 days from 15 March 2027 and 47 days from 15 March 2029. Certificates issued earlier may remain in use under their issuance-era limit; this is not a claim that every installed certificate now expires within 200 days. Issuers may choose shorter lifetimes. Private-CA certificates and provider-defined secret lifecycles are separate policies, not DNS TTLs.

How it works

Public TLS follows the X.509 model in RFC 5280: each certificate carries a validity interval. TLS clients reject expired server certificates during the handshake. Microsoft’s Windows and application stacks surface that as trust or hostname errors that users phrase as “can’t log in” or “API stopped”.

Secrets (symmetric keys, client secrets, private keys in keystores) rarely embed automatic expiry in the protocol; instead, identity providers and SaaS APIs enforce administrative expiry or compromise rotation. A hosted stack may hold dozens of these across web heads, workers, message consumers and scheduled jobs.

Inventory mechanics (editorial recommendation, not a single vendor feature):

Discovery should start from dependency edges: for each hosted application, list outbound HTTPS hostnames, inbound hostnames, and scheduled jobs. Match those to certificate stores (Windows certmgr, platform binding panels, key vault references). Duplicate certs often exist on load balancers and origin servers; renewing only one side prolongs a false sense of safety.

What to choose and why

Central visibility beats per-server calendar reminders when more than one team touches the estate. Prefer a single register with owner, environment, blast radius and verification method (synthetic login, partner test call, batch replay).

Staged renewal reduces surprise: issue or install the replacement, validate on a non-production listener or slot, then cut over. Allow time for the issuer's validation and the certificate deployment or activation delays documented by the selected platform.

Secret rotation needs a provider-specific plan. Use overlapping credentials only when both the provider and every relevant consumer support them. Validate the replacement with controlled requests, update each consumer, and retain the old credential only for an agreed transition and rollback window; include scheduled or infrequent callers before retirement. For a single-active-credential system, rehearse a coordinated cutover, define a maintenance window if needed, and validate the documented rollback method. Credential overlap does not mean dual-writing business data. Microsoft Entra application credential documentation describes creating a client secret with a chosen duration; it does not establish universal overlap support.

Risks and limits

This article covers ongoing certificate and secret operations. Recovering a lost certificate authority or rebuilding an estate-wide trust store needs a separate recovery plan.

CA/Browser Forum policies and issuer practices change; confirm maximum validity for new issuances at implementation time. No commands or renewal scripts were executed in this draft (untested).

This is source research only; certificate issuance, binding changes and credential rotation have not been lab validated.

Sources

Primary sources checked 14 November 2026. Procedures remain source-researched, not lab validated.

• RFC 5280 — PKIX certificate profile (May 2008)
• Install a TLS/SSL Certificate for Your App - Azure App Service | Microsoft Learn
• CA/Browser Forum TLS Baseline Requirements v2.3.1 (4 October 2026)
• Register a Microsoft Entra app and create a service principal - Microsoft identity platform | Microsoft Learn

Related future topics

Mutual TLS between application tiers; proving firewall changes before port work. Service context: Managed support (related link only; no SLA or product claims).

Learning notes

1. Expiry outages often hit integrations and batch jobs before interactive users notice.
2. One hostname may need coordinated renewal on load balancer, origin and API consumers.
3. Secrets lack the visible browser error that expired public TLS provides.
4. Inventory by dependency edge finds consumers calendar-based host lists miss.
5. Steady-state certificate management is distinct from post-incident trust-store recovery.

This article was originally published on 14 November 2026.