The VPN Outage That Was Actually a Certificate Problem
4 Hours of Troubleshooting. 5 Minutes to Fix.
This is a story about a VPN outage. Specifically, it’s a story about an engineer who spent 4 hours troubleshooting network infrastructure before discovering the root cause was a certificate that expired 3 days earlier.
It’s not unique. This pattern plays out in enterprises every week. And it always follows the same script.
VPN Certificate Outage Analysis
Where time is spent and what actually causes failures
Time Spent During Incident
Root Causes of VPN Cert Failures
75%
of incident time spent finding the problem
10%
of time is the actual fix
Hour 0: The First Ticket (7:12 AM)
Ticket: “VPN won’t connect from home. Was working Friday.”
The on-call engineer checks the ticket. Classic Monday morning complaint. Probably a user issue. Sends the standard KB article: “Restart VPN client, check internet connection, try again.”
User replies: “Already tried. Still broken.”
Two more tickets come in within 10 minutes. Same issue. Different users.
Hour 1: It’s Not a User Problem (8:00 AM)
27 tickets now. All the same: “VPN was working Friday, not working today.”
The network team gets pulled in. First checks:
| Check | Result |
|---|---|
| VPN Gateway (RRAS) | Running, accepting connections |
| Firewall rules | Unchanged since last Thursday |
| ISP/Internet | No reported outages |
| Split tunneling config | Unchanged |
| DNS resolution | Working |
| VPN concentrator CPU/memory | Normal |
Everything looks fine. Some users CAN connect. Others can’t. No pattern by location, ISP, or device model.
Hour 2: Deeper Investigation (9:15 AM)
Engineer digs deeper:
- Windows Event Logs on VPN server: No errors
- NPS (Network Policy Server) logs: Some authentication failures, but NPS has been “flaky” before
- RADIUS accounting: Shows successful auths AND failed auths — mixed results
- Network captures: IKE_SA_INIT succeeds, IKE_AUTH fails for affected users
The IKE_AUTH failure is the clue. But what’s causing it?
Engineer checks NPS policies:
- Connection request policies → unchanged
- Network policies → unchanged
- Conditions and constraints → all look correct
“Maybe it’s a Windows Update that broke something over the weekend?”
Checks Windows Update history on VPN server. Nothing installed since 2 weeks ago.
Hour 3: Going Down the Wrong Path (10:30 AM)
Team starts exploring increasingly unlikely theories:
- Maybe a GPO change affected VPN settings?
- Could it be a certificate revocation issue? (checks CRL — CRL is fine)
- Is the RADIUS shared secret mismatched? (no, it hasn’t changed)
- Did someone modify the VPN connection profile via Intune? (no changes)
- Could it be MTU issues? (tests say no)
Someone suggests: “Let’s restart NPS and RRAS.”
Services restarted. No change. Affected users still can’t connect.
The team notices a pattern: devices issued certificates in March 2022 are failing. Devices with certificates from September 2023 work fine.
But nobody connects this to the actual problem yet.
Hour 4: The Certificate (11:20 AM)
Finally. Someone says: “Let me check the actual client certificate on one of the failing devices.”
Remote session to an affected laptop. Opens certlm.msc. Personal → Certificates.
The machine certificate:
Subject: CN=LAPTOP-JN4782.corp.contoso.com
Issuer: CN=Contoso-Issuing-CA
Valid From: March 15, 2022
Valid To: March 15, 2024Today’s date: March 18, 2024.
Certificate expired 3 days ago.
The Root Cause (11:25 AM)
Root cause: Machine certificates issued in March 2022 with a 2-year lifetime expired on March 15, 2024.
Why auto-enrollment didn’t prevent it:
- Template lifetime: 2 years
- Renewal window: last 20% = ~4.8 months (starts ~October 2023)
- Affected devices: laptops that were off-network or powered off during October 2023 - March 2024
- Remote workers who rarely connect to corporate network via alternative means
Why it wasn’t caught earlier:
- No certificate expiry monitoring in place
- No inventory of issued certificates with expiry dates
- Auto-enrollment assumed to handle renewals
- Friday expiry → not detected until Monday
The Fix (11:30 AM — 5 Minutes)
Knowing the root cause, the fix is straightforward:
- Set up a temporary wired/alternate network connection for affected devices
- Trigger
certutil -pulseto force auto-enrollment - New certificate issued within minutes
- VPN connection works immediately
Time to fix once root cause identified: 5 minutes per device.
Total time wasted before root cause: 4 hours of senior engineer time.
The Scale Problem
The 5-minute fix is per device. With 200+ affected devices:
| Remediation Method | Time per Device | Total Effort |
|---|---|---|
| Remote session + certutil | 10 min | 33 hours |
| User self-service with instructions | 5 min | Variable (many can’t do it) |
| Physical visit for offline devices | 30 min | Significant |
Total remediation: 2-3 days to reach all affected devices.
Why This Takes 4 Hours to Diagnose
Certificate problems masquerade as network problems because:
- Error messages don’t say “certificate” — VPN client says “connection failed”
- Some devices work, some don’t — only certs from a specific date range are expired
- Infrastructure looks healthy — VPN server, RADIUS, NPS all running fine
- Certificates are “set and forget” — not part of standard troubleshooting checklist
- NPS logs are cryptic — “Reason: 16” doesn’t scream “expired certificate” to most engineers
- Recent changes are checked first — but nothing changed; the certificate just aged past its valid date
What Would Have Prevented This
| Prevention | How |
|---|---|
| Certificate inventory | ”Show me all machine certs expiring in the next 30 days” |
| Expiry alerting | Email/Teams notification 30 days before batch expiry |
| Renewal verification | Confirm auto-enrollment completed on devices with expiring certs |
| Runbook inclusion | Add “check client certificate validity” as Step 3 in VPN troubleshooting |
The 4-hour troubleshooting session would have been a 5-minute lookup if anyone had a view into certificate expiry dates.
The Lesson
This isn’t a story about incompetence. The engineer followed a logical troubleshooting path. Network issues get checked before certificate issues because network issues are more common.
The lesson is: certificate problems are invisible until they’re not. There’s no monitoring, no dashboard, no alert that says “heads up, 200 machine certificates expire on Friday.” So the first indication is always the outage itself.
The difference between a 4-hour incident and a proactive 5-minute fix is visibility. Know what’s expiring. Know when it’s expiring. Fix it before Monday morning.
Want to stop diagnosing certificate problems after the outage? QCecuring gives you the view into certificate expiry that prevents these incidents entirely. Talk to us →