certificate expired on vpn client

Not specified by the original author.

TL;DR

Find the expired certificate in the machine or user store, then trigger renewal: domain-joined machines usually auto-enroll on next Group Policy refresh (gpupdate /force), or request a new one from the CA web enrollment page. Then reconnect the VPN.

The error

Certificate expired. A valid certificate is required to connect.

Steps

1. Locate the certificate: Windows certlm.msc (machine) or certmgr.msc (user) > Personal > Certificates. Expected: you see the expired VPN/device certificate with its expiry date.
2. Try auto-renewal: run gpupdate /force on a domain-joined machine on the corporate network or VPN-less onboarding network. Expected: a new certificate appears. Auto-enrollment handles most renewals.
3. If auto-enrollment fails, request manually: open the CA web enrollment page (https://example.com/certsrv), request a new certificate using the VPN template. Expected: certificate issued.
4. Delete or archive the expired certificate so the client does not keep selecting it. Expected: only the valid cert remains. Clients often pick the first match, including expired ones.
5. Reconnect the VPN. Expected: certificate auth succeeds. If it still fails, check the client is presenting the machine cert vs user cert as the gateway expects.

When to use

• VPN client explicitly reports an expired certificate
• Annual mass-expiry after a CA template lifetime ends

When not to use

• Gateway certificate errors (server side)
• "No certificate found" (enrollment never happened)

Compatibility

• Windows certificate store; Active Directory Certificate Services; machine or user cert auth VPNs

Variants

macOS clients

Check Keychain Access > System for the expired identity; renew via the MDM or SCEP profile.

Expiry right after a CA migration

The client may trust the old CA only. Deploy the new CA chain via GPO or MDM.

Why it happens

Certificate-based VPN auth fails closed at expiry by design. Enterprises hit this in waves because certificates issued together expire together, usually a year after a mass deployment.

Edge cases

• Off-network machines cannot reach the CA to renew; provide an onboarding network or manual process.
• Track expiry centrally next time; a 30-day warning prevents the wave.

Provenance

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

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

Thread query: "certificate expired" on vpn client

TL;DR: Find the expired certificate in the machine or user store, then trigger renewal: domain-joined machines usually auto-enroll on next Group Policy refresh (gpupdate /force), or request a new one from the CA web enrollment page. Then reconnect the VPN.

Not specified by the original author.

TL;DR

"No valid certificates available" means the client cannot find a usable machine or user certificate for authentication. Open certlm.msc and check the Personal store for an expired or missing computer certificate; if it is expired, renew it through your SCEP or NDES flow or re-enroll the device. If the cert exists and is valid, the Secure Client profile is probably pointing at the wrong certificate store or filter.

The error

No valid certificates available for authentication

Steps

1. On the machine, open certlm.msc (computer certificates) and look under Personal > Certificates. Expected: a computer certificate issued by your CA, not expired. If it is missing or expired, that is the whole problem.
2. If expired or missing: renew through your normal flow (SCEP or NDES auto-enrollment, or re-run device enrollment). Expected: a fresh certificate appears in the Personal store with a future expiry.
3. Check certmgr.msc (user certificates) too if your VPN uses user certs instead of machine certs. Expected: clarity on which store the VPN is supposed to use. Mixing these up is common.
4. In the Secure Client (AnyConnect) profile XML on the client, verify the certificate match criteria point at the right store and issuer. Expected: the profile's certificate settings match the actual certificate. A profile copied from another org often filters for the wrong CA.
5. Restart the Cisco Secure Client service (vpnagent) after fixing the certificate. Expected: the client now lists a certificate and connects. The agent caches the "no valid certificates" state.
6. If the cert is valid and the profile is right: repair the Secure Client install or update to the supported version. Expected: the client enumerates certificates correctly.

Use this when

• Cisco Secure Client shows "no valid certificates available"
• Certificate-based VPN auth suddenly breaks across many machines (likely mass expiry)
• A reimaged machine cannot use VPN until its certificate is reissued

Not for this skill when

• VPN uses username and password or SAML (no certificates involved)
• Duo or other MFA push is failing after the certificate step succeeds
• The certificate is for Wi-Fi 802.1X, not VPN (different profile, same store)

Compatibility

• Cisco Secure Client (AnyConnect) 5.x on Windows 10/11 and macOS; machine or user certificate authentication

Variants

Works for some users but not others

Compare a working and a broken machine's Personal store; the broken ones usually have an expired cert from a failed auto-renewal. Check the SCEP server logs for renewal failures.

Certificate exists but the client still says none available

The certificate may lack the client-authentication EKU, or the private key is missing (cert imported without the key). Re-enroll with the key handled properly.

Why it happens

Certificate VPN auth needs three things to line up: a non-expired certificate, in the right store, with a private key, matching the profile's selection criteria. Any one missing produces the same message, which is why the fix is a checklist through the stores and the profile rather than a single setting.

Edge cases

• Machine certs issued with short lifetimes (90 days) expire silently; monitor expiry centrally instead of waiting for VPN tickets.
• Clock skew on the machine can make a valid cert look expired; check the clock if the cert looks fine.
• Smart card certs need the card inserted AND the middleware running; "no valid certificates" with the card out is expected behavior.

Provenance

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

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

Thread query: cisco secure client no valid certificates available fix

TL;DR: "No valid certificates available" means the client cannot find a usable machine or user certificate for authentication. Open certlm.msc and check the Personal store for an expired or missing computer certificate; if it is expired, renew it through your SCEP or NDES flow or re-enroll the device. If the cert exists and is valid, the Secure Client profile is probably pointing at the wrong certificate store or filter.

Not specified by the original author.

TL;DR

An expired cert is a race against every client that validates it: confirm the expiry, renew immediately (certbot renew or your CA's flow), reload the service so it picks up the new cert, and verify from outside. Do this in minutes, not hours; every expired minute is failed handshakes. Then set up expiry alerting so it never happens again.

Error / query

TLS certificate expired: emergency renewal steps

Use this skill when

• Users or monitors report certificate errors and the cert is past its notAfter date
• A deploy or server rebuild served a stale certificate
• Auto-renewal silently failed weeks ago and nobody noticed
• You need the fastest path from expired to valid, not a lecture on PKI

Not for this skill when

• The cert is valid but clients distrust it; that is a chain or CA problem, not expiry
• You are setting up certificates for the first time; follow the normal issuance flow
• The expiry is weeks away; fix the renewal automation calmly instead of emergency-renewing

Steps

Step 1: Confirm the certificate is actually expired and find its dates

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Expected: notBefore and notAfter dates; if notAfter is in the past, expiry is confirmed.

Step 2: Renew the certificate now

certbot renew --force-renewal --cert-name example.com 2>&1 | tail -5

Expected: "Congratulations" or a success line; if certbot fails, check the ACME challenge path before retrying.

Step 3: Reload the service so it serves the new cert

systemctl reload nginx 2>/dev/null || systemctl reload apache2 2>/dev/null; echo "reloaded"

Expected: "reloaded" with no error; a restart works too but drops connections, reload does not.

Step 4: Verify the live certificate from outside

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -issuer

Expected: a notAfter date in the future and the expected issuer; this is the cert clients actually see.

Step 5: Check how many days of validity you have and set a reminder

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -checkend 2592000 && echo "valid for 30+ days" || echo "expires within 30 days"

Expected: "valid for 30+ days"; then add a monitor that alerts at 21 days so renewal never becomes an emergency again.

Variant phrasings

"certbot renewal failed, now the cert expired"

Fix the challenge first (port 80 reachable, webroot path correct), then force-renew; renewing against a broken challenge just fails again.

"Expired cert on a load balancer"

Renew at the CA, upload the new cert to the LB (acm import-certificate or console), and verify the listener serves it; the backend cert can wait.

"How to check cert expiry for many domains"

Loop step 1 over a domain list in a weekly cron; the check is cheap and it is the alert that would have prevented this.

Why it happens

Auto-renewal breaks silently (challenge path changes, ACME account issues, cron dies) and nobody watches the expiry date. The cert keeps working until the exact second it does not, so the failure always feels sudden.

Edge cases and pitfalls

• Reload, not just renew: the new cert sits on disk doing nothing until the service reloads it.
• Intermediate chain changes can make a fresh cert distrusted; verify with the issuer line in step 4, not just the dates.
• If you serve the cert from multiple places (CDN, LB, origin), renew and reload every one; one stale copy keeps the errors coming.
• Do not rate-limit yourself: repeated failed renewals against the CA can trigger ACME rate limits, fix the underlying error first.

Provenance

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

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

Thread query: TLS certificate expired: emergency renewal steps

TL;DR: An expired cert is a race against every client that validates it: confirm the expiry, renew immediately (certbot renew or your CA's flow), reload the service so it picks up the new cert, and verify from outside. Do this in minutes, not hours; every expired minute is failed handshakes. Then set up expiry alerting so it never happens again.