47-day certificates are solving
a browser problem.
You're applying it to systems that don't have one.
Certificate lifetimes are shrinking because revocation doesn't work reliably on the public internet. But most of your systems aren't the public internet.
Certificate lifetimes are collapsing.
Public CAs are reducing certificate lifetimes because revocation mechanisms like OCSP cannot be relied upon at internet scale. Instead of checking whether a certificate is still valid – they expire it faster.
This isn't a feature. It's a workaround.
If you rely on public certificates:
This is necessary – for browser-facing systems.
But it has quietly become the default everywhere.
Public trust is being used
where it doesn't belong.
Public certificate authorities were designed for one context. They're being deployed in another.
- ● Browsers
- ● Unknown clients
- ● Global trust
- ● Internal APIs
- ● Microservices
- ● Kubernetes workloads
Why this happens
Tooling makes it easy
Modern infrastructure defaults to public ACME flows – cert-manager, ingress controllers, built-in Let's Encrypt. If it has a hostname, it gets a public certificate.
Internal PKI is too hard
Enterprise solutions like Active Directory Certificate Services or HashiCorp Vault provide correct trust models – but require specialist teams, complex deployment, and significant cost.
Engineers optimise for speed
The decision is rarely "what trust domain is this system in?" It's "we need HTTPS – Let's Encrypt works – ship it."
You are rotating certificates every 47 days
for systems that never needed it.
Not because it's correct – because it's the only practical option available.
Certificate management doesn't just fail at scale.
It fails by design.
Operational chaos drives teams toward wildcards and multi-SAN certs – which introduce a different class of failure entirely.
Certificate Renewal Chaos
Let's Encrypt Breaks Silently
Certbot configs drift. DNS validation lapses. Cron jobs fail without alerting.
Every Service Is Different
Nginx, Go services, Java keystores – each has its own renewal method. Consistency is a myth.
Scaling Multiplies the Pain
3 services is manageable. 30 is fragile. 300 is a full-time job with another failure mode per service.
Rotation Means Downtime
Replacing a cert often means restarting the service. Even graceful reloads cause connection drops at scale.
No Single Pane of Glass
Certs scattered across servers, load balancers, CDNs, and container orchestrators. Nobody knows the full picture.
Mixed Provider Chaos
Let's Encrypt, internal CA, commercial certs – each has its own renewal flow and its own way of failing.
This doesn't scale.
You don't miss certificates because you're careless.
You miss them because the system doesn't scale.
Simplification turns isolated failures into systemic risk.
Wildcard and multi-SAN certificates bind APIs, frontends, admin panels, and internal services to the same certificate, the same renewal cycle, and the same validation event.
5 services · 1 certificate · 1 renewal cycle
One DV failure takes down every dependent service.
Single Point of Compromise
One key exposed = every subdomain compromised.
Least Privilege Violation
Staging holds the same cert as production APIs.
Increased Attack Surface
More servers storing the same private key.
Limited Scope Matching
Wildcards only match one subdomain level.
No Granular Visibility
Can't track or validate per service.
Compliance & Policy
Restricted in financial and regulated environments.
Trust domains.
There are two fundamentally different trust models. The certificates are the same. The trust model is not.
- • Designed for browsers
- • Unknown clients
- • No reliable revocation
- • Short-lived certificates (47–90 days)
- • Global validation required
- • Known identities
- • Controlled network
- • Real revocation possible
- • Policy enforcement
- • mTLS-based authentication
Same technology. Different model. Most organisations apply the public model to private systems.
The impact of the wrong trust model.
- Unnecessary renewal overhead
- ACME / DNS complexity
- Increased failure surface
- No control over internal trust
- Implicit trust between services
- No identity policy enforcement
- No trust domain separation
- Can't scale machine identity
- Hidden blast radius
Separate trust domains.
For browser-facing systems where global trust is required.
For internal systems where you control the trust boundary.
Introduce controlled trust
Enterprise-grade trust –
without enterprise complexity.
Your own internal certificate authority with full control over issuance, real revocation, policy enforcement, and visibility across every certificate and system.
Every certificate is an identity.
Every identity is trusted by something.
Understanding certificates is step one.
Controlling trust is what comes next.
Stop rotating certificates unnecessarily.
Start using the right trust model.