What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To avoid unnecessary certificate issuance after a Kubernetes restore, restore each TLS Secret before the cert-manager Certificate that uses it—and before an Ingress when ingress-shim manages certificates. Exclude transient ACME Order and Challenge resources from backups so cert-manager can reconstruct work from durable desired state. This is an operational timing hazard, not a documented version-specific defect named “the Restore Race.”
What causes a cert-manager restore race?
cert-manager stores a certificate and its private key in a Kubernetes Secret. That Secret is part of the state you need to restore, not just a disposable output. If a restored Certificate becomes visible before its Secret, cert-manager can treat the certificate as missing and trigger issuance. The same risk applies when an Ingress is restored first and ingress-shim creates a corresponding Certificate.
As cert-manager’s v1.19 backup and restore guide puts it: “If cert-manager does not find a Kubernetes Secret with an X.509 certificate for a Certificate, reissuance will be triggered.” The race is between resource visibility and reconciliation: cert-manager acts on what it can see at that moment.
A rebuild can therefore create new ACME activity even if the old cluster had a working certificate. Restoring operational ACME objects wholesale is not a reliable way to avoid this: Kubernetes backup tools may omit custom-resource status, and restored status can no longer reflect what the ACME server actually completed.
#1 Best Overall
What should you restore, and in what order?
Use the cert-manager guide’s conceptual sequence, adapting the mechanics to your backup tool and resource types:
- Install cert-manager and its CRDs. The custom resources must be recognized by the destination cluster before they can be restored.
- Restore issuer credentials and certificate Secrets. Restore the credentials referenced by issuers and the TLS Secrets containing existing certificates before the resources that depend on them.
- Restore durable desired state. Restore
Certificateresources, and restore dependentIngressresources according to your chosen strategy. When ingress-shim is in use, make sure the Secret is present before the Ingress can prompt certificate creation. - Leave transient ACME work out of the restore. Exclude
OrderandChallengeresources; the guide also cautions thatCertificateRequeststatus may be incomplete or missing. Let cert-manager derive new work from the durable resources.
These are sequencing principles, not guarantees about every tool. The v1.19 guide notes, for example, that Velero’s default ordering restores Secrets before Ingresses and custom resources later. It also warns that custom-resource status and owner references may not be restored. Check what your own backup and restore configuration actually preserves rather than assuming its default order is sufficient.
Why should Orders and Challenges usually be excluded?
The durable intent is expressed by resources such as a Certificate; an Order and its Challenge represent point-in-time ACME work. Their status may describe a step that the backup captured, but the ACME server’s state may have moved on—or the backup tool may not have captured that status at all. Restoring those objects can leave Kubernetes and the CA with mismatched views of the issuance process.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →cert-manager’s documented recommendation is to exclude Orders and Challenges from backups and let the controllers rebuild necessary work. The same caution applies to CertificateRequests when their status or associated ephemeral state cannot be restored faithfully. The goal is to restore the certificate state and desired configuration, not to replay a possibly stale snapshot of an in-flight validation.
Does cert-manager’s challenge limit prevent CA rate limits?
No. cert-manager’s ACME scheduler applies concurrency back-pressure; it is not a budget of allowed requests at a certificate authority. The ACME Orders and Challenges documentation says: “The scheduler does not attempt to model CA-specific rate limits, tenant fairness, or ownership policy for DNS names.”
The scheduler defaults to 60 concurrent challenges and prevents concurrent challenges for the same HTTP-01 hostname or DNS-01 _acme-challenge name. Those controls limit overlapping work inside cert-manager; they do not guarantee that a CA will accept every new issuance request.
Let’s Encrypt’s current rate-limit policy distinguishes renewals recognized through ACME Renewal Information (ARI), which are exempt from all rate limits, from older renewal recognition based on an exact set of identifiers, which may still be subject to some limits. Do not assume a post-restore request will be recognized as an exempt renewal, and consult the live policy before relying on particular numeric limits.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsHow can you tell a propagation delay from a rate-limit problem?
Follow the ACME lifecycle: Certificate → CertificateRequest → Order → Challenge. A Challenge controller presents HTTP-01 or DNS-01 proof, checks whether it has propagated, and then asks the ACME server to validate it. A failed local self-check is not the same as a CA rejecting an order for rate limits.
Best Value
Inspect the Challenge first
Check the Challenge status and events, especially its Reason, Presented, and Processing fields. These help distinguish a proof that has not been presented or propagated from a later ACME validation or issuance failure.
Check the public validation path
- HTTP-01: Check that the challenge URL is reachable from the public internet, and that the cluster’s own vantage point can reach it.
- DNS-01: Check that the
_acme-challengeTXT record is visible publicly and that the resolver used for cert-manager’s self-check can see it.
When propagation has not passed, cert-manager retries its self-check every 10 seconds, according to its ACME troubleshooting FAQ. That is the documented self-check retry interval—not the CA’s retry interval, and not evidence that the CA has accepted or rejected the order.
If a self-check never succeeds, cert-manager documents deleting an Order or correcting the Certificate as possible interventions. Diagnose and fix the underlying issue before intervening: repeatedly deleting and recreating work can generate additional issuance attempts rather than resolve a propagation problem.
What to verify before relying on a recovery plan
- Certificate Secrets and issuer credentials are restored before dependent Certificate or Ingress resources.
- Orders and Challenges are excluded, and CertificateRequest status is not assumed to be usable unless the restore process preserves it correctly.
- Your backup tool’s behavior for custom-resource status and owner references is understood.
- You have checked the current CA policy rather than treating cert-manager’s challenge concurrency as a CA rate-limit allowance.
- Your HTTP or DNS checks cover both public visibility and the cluster’s own self-check vantage point.
cert-manager documents an exponentially increasing retry delay from 1 to 32 hours by default after certain issuance failures in its current FAQ. Because retries can affect recovery timing, inspect the reported failure and its events rather than assuming a restore-triggered issuance will immediately succeed or fail.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
