agent failed to download the renewed cert: signed url expired mid-fetch

Not specified by the original author.

TL;DR

Renew the app certificate before expiry, fix the subscription renewal job to use the new certificate, and recreate the Graph subscription for reported phish, then backfill reports from the mailbox for the gap period, because a subscription expiring every three days with a broken renewal is a standing blind spot. Prove it on one message or campaign before rolling it to the rest of messages in the sweep or campaign, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

agent graph subscription for reported phish expired every three days and the renewal job failed after the app certificate expired

Use this when

• You see this exact error or symptom: agent graph subscription for reported phish expired every three days and the renewal job failed after the app certificate expired.
• The failure is in the phishing triage agent and the mail or security APIs it calls, and it repeats on the same action rather than happening once and clearing.
• Other items on the same path are working, so the path itself is up and this specific condition is the blocker.

Not for this skill when

• A different error code, message, or tool is involved. Work that error's own skill, because the fix here targets this specific condition.
• The whole service or platform is down. Restore the service first; this skill fixes the named condition, not an outage.
• You cannot identify one affected item to test on. Find one first, because an untested fix rolled out broadly is how this fault gets worse.

Steps

1. Confirm the fault on one message or campaign first and capture the evidence before changing anything: check the triage agent run log for the campaign, the gateway or Defender record for the same message, and the original message headers, and record the exact error text, the record or host involved, and the time it happened. Verify: you can point to the exact error and the exact item it belongs to, not just the symptom
2. Renew the app certificate before expiry, fix the subscription renewal job to use the new certificate, and recreate the Graph subscription for reported phish, then backfill reports from the mailbox for the gap period, because a subscription expiring every three days with a broken renewal is a standing blind spot. Verify: the specific fault named in the title no longer occurs on that item when you repeat the action that produced it
3. Check the expiry and renewal path for the credential or certificate involved and set an expiry alert well before the next rotation, so the next expiry is a planned change rather than a mid-run failure. Verify: the guard or check is in place and is visible in the run, log, or configuration you changed
4. Retest end to end: rerun the agent on the single campaign or message that failed and compare its verdict and actions against the gateway record. Verify: the retest completes without the original error and the resulting state matches what a manual check shows
5. Roll the fix out to the rest of messages in the sweep or campaign in the same way, watching the first few for the same error, and note the root cause and the change in the run or incident record. Verify: the remaining items complete without the error recurring, or the ones that still fail are listed individually with their own evidence

Variant phrasings

agent graph subscription for reported phish expired every fix

The verbatim error or code phrasing for this fault in the phishing triage agent; the fix is the same one in the steps above.

agent graph subscription for reported phish expired every three days

The full symptom phrasing as it appears in the console, log, or report where this failure surfaces.

how to fix agent graph subscription for reported phish expired every

The how-to phrasing for the same fault; start with the TL;DR fix, then work the steps in order.

Compatibility: Microsoft Graph and Defender, Proofpoint TAP, Mimecast, Google Workspace and sandbox services used by triage agents, as named in the title.

Why it happens

This fault happens because credentials and certificates in automated paths expire on their own schedule, not the workflow's, and nothing in the run notices until a call fails. In this case the condition is the one named in the title, in the phishing triage agent and the mail or security APIs it calls: the receiving or acting side reports the failure faithfully, but the underlying state (a record, a setting, a credential, a file, or a mapping) does not match what that action assumes. Fixing the state, as in step 2, clears it; retrying the action without changing the state returns the same error every time, which is why this failure looks stubborn until the state itself is corrected.

Provenance

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

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

Thread query: agent graph subscription for reported phish expired every three days and the renewal job failed after the app certificate expired

TL;DR: Renew the app certificate before expiry, fix the subscription renewal job to use the new certificate, and recreate the Graph subscription for reported phish, then backfill reports from the mailbox for the gap period, because a subscription expiring every three days with a broken renewal is a standing blind spot. Prove it on one message or campaign before rolling it to the rest of messages in the sweep or campaign, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

Not specified by the original author.

TL;DR

Fix this in the agent workflow by acting on the exact problem first: refresh the sign in session before the step that failed, keep the renewed session for the rest of the run, redo only the interrupted step to pull the signed NDA into the contract repository, and confirm the action completes without a second expiry prompt. Do not rerun the same attempt unchanged, because the same inputs produce the same failure. Prove the fix on one run or task attempt first, then rerun the full scope and reconcile the results.

auth token expired mid-run agent failed to pull the signed NDA into the contract repository error session expired failure

Use this when

• The operation in the agent workflow fails with this exact problem: auth token expired mid-run agent failed to pull the signed NDA into the contract repository error session expired failure.
• The same failure repeats on retry with unchanged inputs.
• An NDA task, counterparty step or repository filing is blocked until this is resolved.

Not for this skill when

• The notice is a platform outage from the vendor. Resolve that first, then return here if this problem remains.
• The agent completes the task and you only disagree with the output wording or a legal judgement in the document. That is a legal owner decision, not this failure.

Steps

1. Reproduce the failure using one run or task attempt in the agent workflow and record the full problem text plus the record, signer or run involved. Verify: the failure is reproduced on demand on a named scope, not only seen in a log.
2. Apply the specific fix for this problem: refresh the sign in session before the step that failed, keep the renewed session for the rest of the run, redo only the interrupted step to pull the signed NDA into the contract repository, and confirm the action completes without a second expiry prompt. Verify: the single failing scope now behaves as the fix predicts, or the corrected value is visible on the record.
3. Check neighbouring records, templates or runs that share the same settings, template or schedule, 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 the agent workflow on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result against the source of truth, the executed NDA, the counterparty record or the repository entry, so a silent partial success is caught. Verify: values match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the workflow log so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Variant phrasings

auth token expired mid-run agent failed to pull the signed NDA into the contract repository error session expired failure

The verbatim form searchers paste from the console, report or run log. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - auth token expired mid-run agent failed to pull the signed NDA into the contract repository error session expired failure

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

Agent workflow troubleshooting for this failure

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

Why it happens

Long document preparation steps let the sign in session expire before the send or save step runs, so the final action fails with an expired auth token even though the earlier steps completed under a valid session.

Edge cases

• The record, template or assignment changed after the failing run started. Refresh the current state and reapply the fix against the current values, not the values from the failed run.
• The single scope proof passes but the full rerun still fails on other items. Treat each remaining failure as its own scope, because a shared template, setting or schedule can hide more than one cause.
• The source systems disagree on the correct value. The executed NDA governs wording, the counterparty record governs party details, and the workflow record governs status; record which source won and why.

Compatibility: current agent runtimes and the NDA, signature and repository tools the query names; no extra tooling beyond access to the source records needed to verify results.

Provenance

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

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

Thread query: auth token expired mid-run agent failed to pull the signed NDA into the contract repository error session expired failure

TL;DR: Fix this in the agent workflow by acting on the exact problem first: refresh the sign in session before the step that failed, keep the renewed session for the rest of the run, redo only the interrupted step to pull the signed NDA into the contract repository, and confirm the action completes without a second expiry prompt. Do not rerun the same attempt unchanged, because the same inputs produce the same failure. Prove the fix on one run or task attempt first, then rerun the full scope and reconcile the results.

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.