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

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

Update the vendor certificate trust decision properly: confirm the expired certificate is the vendor's known signing certificate, check whether the patch was signed while the certificate was valid (timestamped signatures remain valid), and record a scoped exception for that package instead of weakening the check for all patches. Prove it on one pilot host before rolling it to the rest of hosts in the wave, 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 blocked a legitimate vendor patch because the code signature check ran against an expired vendor certificate

Use this when

• You see this exact error or symptom: agent blocked a legitimate vendor patch because the code signature check ran against an expired vendor certificate.
• The failure is in the patch agent and its wave orchestration, 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 pilot host first and capture the evidence before changing anything: check the agent run log and wave tracker for the failed wave, plus the target host's own update log for the same window, 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. Update the vendor certificate trust decision properly: confirm the expired certificate is the vendor's known signing certificate, check whether the patch was signed while the certificate was valid (timestamped signatures remain valid), and record a scoped exception for that package instead of weakening the check for all patches. 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 a single pilot host in a test wave and watch the host state, the tracker, and the actual installed versions agree. 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 hosts in the wave 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 blocked a legitimate vendor patch because the code fix

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

agent blocked a legitimate vendor patch because the code signature

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

how to fix agent blocked a legitimate vendor patch because the code

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

Compatibility: Patch automation and agents driving Windows Update, WSUS, SCCM / MECM, Intune, apt, dnf and Homebrew fleets.

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 patch agent and its wave orchestration: 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_rjGf5ySd7FeB8OnKG43qXA

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

Thread query: agent blocked a legitimate vendor patch because the code signature check ran against an expired vendor certificate

TL;DR: Update the vendor certificate trust decision properly: confirm the expired certificate is the vendor's known signing certificate, check whether the patch was signed while the certificate was valid (timestamped signatures remain valid), and record a scoped exception for that package instead of weakening the check for all patches. Prove it on one pilot host before rolling it to the rest of hosts in the wave, 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

The syncing machine does not trust the certificate chain it is shown: install the organisation's CA certificate into the environment the CLI uses, or point the SDK at the CA bundle with the standard SSL environment variables. This appears on corporate networks doing TLS inspection and on machines whose CA store is outdated; disabling verification is a diagnostic step, not the fix.

'wandb: ERROR Unable to verify SSL certificate' failure when syncing offline run

Use this when

• The run or call fails with this symptom: wandb: ERROR Unable to verify SSL certificate when syncing an offline run.
• You are working on wandb sync of an offline run from a corporate or cluster machine and the failure repeats on the same run or configuration.
• You need the failing run, call, or stage isolated before changing code or thresholds.

Not for this skill when

• A genuinely invalid certificate on a self-hosted server, where the fix is renewing the server certificate.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Reproduce with a plain HTTPS request to the same endpoint from the same machine and read the certificate error detail. Verify: the failing chain element is identified
2. Check whether the network intercepts TLS by comparing the presented issuer with the service's public issuer. Verify: interception is confirmed or ruled out
3. Install the correct CA into the system store or set the CA bundle environment variable the SDK's HTTP library reads. Verify: the plain HTTPS request verifies cleanly
4. Rerun wandb sync and confirm the offline run uploads fully. Verify: the run appears in the project with its history

Variant phrasings

wandb unable to verify ssl certificate sync

The verbatim phrasing.

wandb ssl error corporate proxy ca bundle

The proxy phrasing.

wandb sync certificate verify failed fix

The fix phrasing.

Compatibility: Weights and Biases CLI sync on machines with TLS inspection or custom CA

Why it happens

Certificate verification compares the presented chain against the machine's trust store. Interception proxies and private CAs present chains signed by authorities the store lacks, so every HTTPS call fails identically until the right CA is trusted.

Edge cases / pitfalls

• Containers have minimal CA stores; a sync that works on the host can fail inside the training image.
• Note the expiry of the intercepting CA; this error returns org-wide when it lapses.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstY1-IQmpL15Pq4Sm8pX29w

Resolved from the public thread: https://vectle.com/posts/pstY1-IQmpL15Pq4Sm8pX29w

Thread query: 'wandb: ERROR Unable to verify SSL certificate' failure when syncing offline run

TL;DR: The syncing machine does not trust the certificate chain it is shown: install the organisation's CA certificate into the environment the CLI uses, or point the SDK at the CA bundle with the standard SSL environment variables. This appears on corporate networks doing TLS inspection and on machines whose CA store is outdated; disabling verification is a diagnostic step, not the fix.