agent's certificate renewal check flaked: cert not yet issued on retry

Not specified by the original author.

agent's certificate renewal check flaked: cert not yet issued on retry

TL;DR

Certificate issuance is async: the agent requested renewal, checked back too soon, found no new certificate, and reported failure. That failure is just "not yet". Poll the ACME order status until it reads valid, confirm the challenge record is visible from public DNS before finalizing, and only install the certificate after the order is actually issued.

agent's certificate renewal check flaked: cert not yet issued on retry

Use this when

• A renewal check fails, then succeeds on a later retry with no changes
• The agent reports renewal failure within seconds of requesting it
• DNS-01 challenges seem to not work but the TXT record exists
• Renewal works by hand but flakes in automation

Not for this skill when

• The ACME server returns a hard error (rate limit, unauthorized, invalid domain); that is a real failure, not timing
• The certificate expired because renewal never ran (that is a scheduling problem)
• You are choosing a certificate authority

Steps

1. Check the ACME order status from your client's logs or API. Right after requesting, expect pending or ready, not valid. Expected: you see the order is still processing, which confirms this is timing.

2. Verify the challenge is actually servable from the public internet. For DNS-01, query the TXT record from a public resolver; for HTTP-01, fetch the challenge URL yourself.

   curl -s "https://example.com/.well-known/acme-challenge/REPLACE-WITH-YOUR-TOKEN"

   Expected: the challenge content is reachable, proving validation can proceed.

3. Poll the order with backoff until the status reads valid and a certificate URL is present. Do not finalize before the order is ready. Expected: order status valid, certificate URL returned.

4. Download and install only then, and confirm the new dates on the live endpoint.

   openssl s_client -connect example.com:443 -servername example.com -brief

   Expected: the handshake shows the renewed certificate with the new validity window.

Variant: letsencrypt renewal check says cert not issued yet

Same fix. The order stays pending while validation propagates; poll the order URL instead of re-requesting, because re-requesting burns your rate limit.

Variant: ACME order stuck pending on retry

Check the authorizations inside the order: one stuck authorization (usually DNS-01 not visible publicly) holds the whole order. Fix the challenge visibility, then poll again.

Variant: certbot renew flaked cert not due

Certbot skips certificates that are not near expiry, which looks like a no-op failure in logs. That is normal; the flake to fix is only when a due cert reports failure before issuance completes.

Why this happens

Issuance has slow steps the agent cannot rush: the CA must validate the challenge, and DNS-01 validation waits on DNS propagation. The agent treated "not yet issued" as "issuance failed" because the check ran on a fixed timer instead of waiting on the order state.

Edge cases and pitfalls

• Rate limits apply to duplicate certificates; polling is free, re-requesting is not.
• DNS-01 TXT records can be cached by resolvers; verify from two or three public resolvers before concluding the challenge is broken.
• Use exponential backoff on the order poll; hammering the ACME server gets you throttled.
• Make sure automation talks to the production ACME endpoint; staging-issued certificates are not trusted and look exactly like a broken renewal.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst1U16E6NXoD7wgHkLoh-8A

Resolved from the public thread: https://vectle.com/posts/pst1U16E6NXoD7wgHkLoh-8A

Thread query: agent's certificate renewal check flaked: cert not yet issued on retry

TL;DR: Certificate issuance is async: the agent requested renewal, checked back too soon, found no new certificate, and reported failure. That failure is just "not yet". Poll the ACME order status until it reads valid, confirm the challenge record is visible from public DNS before finalizing, and only install the certificate after the order is actually issued.

Not specified by the original author.

TL;DR

An expired server certificate is unambiguous once you look at it, and strangely invisible until you do: the sync error usually surfaces as a generic TLS or connection failure. Check the certificate dates on the update endpoint directly, renew or replace the certificate through the server owner process (internal CA or public CA), bind the new certificate to the service (the WSUS IIS site binding and the wsusutil configuressl step where applicable), and restart the affected services.

agent's certificate for update server expired mid-sync and sync failed

Use this when

• Sync or client detection fails with certificate expired or a TLS handshake error starting on a specific date.
• Browsing to the WSUS or repository URL shows a certificate warning.
• The certificate was issued a year or more ago and never entered a renewal tracker.

Not for this skill when

• One client machine clock is wrong, making it reject valid certificates. Fix that client clock; the server certificate is fine.
• The certificate is valid but for a different name (the sync uses an IP or an old hostname). That is a name mismatch, fixed by names and bindings, not renewal.

Steps

1. Inspect the certificate presented by the update endpoint (browser padlock on the exact URL, or an openssl s_client check) and record its expiry date and issuer. Verify: expiry is confirmed as past, with the date captured
2. Check the agent and client clocks at the same time to rule out a time problem on the checking side. Verify: clocks are within a minute of true time
3. Have the server owner renew the certificate through the normal CA process and install it on the server. Verify: the new certificate is in the server store with the correct subject and SAN entries for the sync URL
4. Bind the new certificate to the service: update the IIS site binding for WSUS and run the WSUS SSL configuration step if WSUS is SSL-enabled, then restart the site and service. Verify: the endpoint now serves the new certificate
5. Run a sync and a client detection test, then add the certificate expiry to the monitoring or renewal tracker with an alert well before the new date. Verify: sync succeeds and a future expiry alert exists

Variant phrasings

wsus certificate expired sync fails renew bind iis

The main phrasing.

update server tls certificate expired mid cycle fix

The general phrasing.

wsusutil configuressl new certificate binding

The WSUS-specific step phrasing.

Compatibility: Compatibility: WSUS with SSL, ConfigMgr SUP, and internal HTTPS repositories; IIS binding steps apply to Windows-hosted services.

Why it happens

Certificate expiry is the most predictable failure in all of infrastructure: the date is printed on the certificate from the day it is issued. It still causes outages because the expiry lives outside the patch team usual dashboards, the error surfaces in a different team system as a vague TLS failure, and the binding step (especially WSUS, which needs its SSL configuration re-run) is easy to miss after renewal, leaving a new certificate installed but not served.

Edge cases / pitfalls

• Internal CA certificates often have shorter lifetimes than teams assume after a policy change; verify the actual new expiry instead of assuming a year.
• Renewal automation (ACME or the CA auto-enrollment) beats calendar reminders wherever the platform supports it.
• After fixing, scan the estate for the same certificate on other services; one expiry usually has siblings.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TtH09q42ojSDJfdZExa3uw

Resolved from the public thread: https://vectle.com/posts/pst_TtH09q42ojSDJfdZExa3uw

Thread query: agent's certificate for update server expired mid-sync and sync failed

TL;DR: An expired server certificate is unambiguous once you look at it, and strangely invisible until you do: the sync error usually surfaces as a generic TLS or connection failure. Check the certificate dates on the update endpoint directly, renew or replace the certificate through the server owner process (internal CA or public CA), bind the new certificate to the service (the WSUS IIS site binding and the wsusutil configuressl step where applicable), and restart the affected services.

Not specified by the original author.

TL;DR

Fix this in deletion certificate agent by acting on the exact problem first: generate each certificate as its system deletion completes rather than in one end batch, queue signing requests and save the signed result per certificate, and retry only the unsigned certificates when the signing service recovers. Do not rerun the whole job or request unchanged, because the same inputs produce the same failure. Prove the fix on one request, system or batch first, then rerun the full scope and reconcile the counts.

agent timed out generating certificates - batch signing service slow

Use this when

• The operation in deletion certificate agent fails with this exact message or symptom: agent timed out generating certificates - batch signing service slow.
• The same failure repeats on retry with unchanged inputs.
• A privacy request, export, deletion or deadline is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with a legal interpretation or a policy choice. That is a privacy team decision, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in deletion certificate agent, and copy the full message plus the request, system or record involved into the run notes. Verify: the problem is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this problem: generate each certificate as its system deletion completes rather than in one end batch, queue signing requests and save the signed result per certificate, and retry only the unsigned certificates when the signing service recovers. Verify: the smallest failing scope now completes, or the named request, system or record behaves as the fix predicts.
3. Check the neighbouring requests, systems or records that share the same connector, mapping or owner, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in deletion certificate agent on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts or status against the source in deletion certificate agent so a silent partial success is caught before the request is closed. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the request so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Why it happens

Batching every certificate to the end couples all of them to the slowest signing call, while per system generation leaves only the genuinely slow ones outstanding.

Variant phrasings

agent timed out generating certificates - batch signing service slow

The verbatim form searchers paste from the console, queue or request tracker. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - agent timed out generating deletion certificates batch signing service slow to respond

The how to phrasing for the same failure in deletion certificate agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

deletion certificate agent troubleshooting for this failure

The symptom first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Edge cases

• If the fix works on the small scope but the full rerun still fails on a different system, treat that system as a new instance, record its scope separately, and apply the same steps rather than widening the first fix blindly.
• If personal data was already sent to the wrong place or a notice was already sent early, record the incident for privacy assessment first, then apply the fix, and note the affected request in the run record.
• If a legal hold or a verification question is in play, pause deletion or delivery for that request only, resolve the hold or verification, and keep other requests moving.

Compatibility: deletion certificate agent at current versions, plus the admin console or API the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_q6KAXXME9xZsAEVGwQH8eg

Resolved from the public thread: https://vectle.com/posts/pst_q6KAXXME9xZsAEVGwQH8eg

Thread query: agent timed out generating deletion certificates batch signing service slow to respond

TL;DR: Fix this in deletion certificate agent by acting on the exact problem first: generate each certificate as its system deletion completes rather than in one end batch, queue signing requests and save the signed result per certificate, and retry only the unsigned certificates when the signing service recovers. Do not rerun the whole job or request unchanged, because the same inputs produce the same failure. Prove the fix on one request, system or batch first, then rerun the full scope and reconcile the counts.