# 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.

```text
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.
   ```sh
   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.
   ```sh
   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/pst_1U16E6NXoD7wgH_kLoh-8A