Killing Expired Certificate Auth Failures with Auto-Renewal Hooks

#The Old Way vs the New Way

The old way starts with a Teams message: “VPN just stopped working for the whole finance team.” A technician opens the RADIUS logs, spots hundreds of TLS handshake failures, and eventually finds that a client authentication certificate template expired overnight. Nobody renewed it because renewal was a manual task someone was supposed to remember every twelve months. The fix involves an emergency GPO push, a scramble to reissue certificates fleet-wide, and a painful few hours where half the building cannot reach internal resources. This happens far more often than most support teams admit, because certificate expiry is silent right up until it is not.

The new way removes the human memory dependency entirely. Instead of relying on someone to track expiry dates in a spreadsheet, we build a monitoring and auto-renewal hook that watches certificate lifetimes across the fleet, triggers renewal automatically at a safe threshold, and pushes the new certificate before the old one dies. The technician’s job shifts from firefighting expired auth to reviewing a weekly dashboard and confirming the pipeline ran. Tickets for “VPN suddenly broke” or “Wi-Fi keeps asking me to reconnect” stop being a recurring category altogether.

#Why Certificate-Based Auth Failures Are an Everyday Problem

Most mid-size and enterprise networks use certificate-based authentication for 802.1X wired/wireless access and for VPN client authentication because it is stronger than password-based methods and resistant to phishing. The trade-off is lifecycle management. Certificates issued by an internal Certificate Authority (CA) via Active Directory Certificate Services (AD CS) or a cloud PKI have a defined validity period, typically one or two years. If autoenrollment renewal is not configured correctly, or a certificate template’s supersede setting is wrong, devices silently sit on ageing certificates until the exact moment they expire, then everything breaks at once, usually for a whole OU or device group provisioned at the same time.

This is a textbook candidate for engineering the ticket out of existence: it is predictable, it is date-driven, and the fix is entirely deterministic. There is no reason a human being should discover this problem reactively.

#Architecture of the Fix

The approach has three moving parts:

• A scheduled inventory job that queries certificate expiry across endpoints (via Intune/MDM script or a scheduled task reporting to a central store).
• An alerting and auto-renewal trigger that calls the CA’s enrollment API or forces a Group Policy autoenrollment cycle once a certificate crosses a configurable threshold, for example 30 days before expiry.
• A verification loop that confirms the new certificate is bound to the correct authentication profile (WPA2/WPA3-Enterprise, IKEv2, EAP-TLS) before the old certificate expires, with rollback if renewal fails.

#Prerequisites and Permissions

• Active Directory Certificate Services with autoenrollment-capable templates, or a cloud PKI (e.g. Microsoft Cloud PKI in Intune, or a SCEP/NDES connector).
• Read access to certificate store data across endpoints — Intune Proactive Remediation scripts, or a Configuration Manager / RMM equivalent.
• An account with Certificate Manager rights on the issuing CA (not Domain Admin — scope this tightly) to permit revocation/reissue actions if automated remediation must intervene.
• A webhook-capable alerting target (Teams, Slack, or a ticketing system) for threshold breach notifications.
• Test scope: a pilot OU or Intune device group of no more than 25 machines, isolated from production auth policies during initial rollout.

#Step 1 — Inventory Certificate Expiry Fleet-Wide

Action: Deploy a PowerShell inventory script as an Intune Proactive Remediation detection script, run daily.

Expected result: A structured report of every client authentication certificate and its remaining validity, centralised in a Log Analytics workspace or a CSV drop location.

Evidence to capture: the raw JSON/CSV output and a timestamped run log showing the scheduled task executed successfully on all targeted devices.

1$thresholdDays = 30
2$certs = Get-ChildItem -Path Cert:LocalMachineMy |
3    Where-Object { $_.EnhancedKeyUsageList -match "Client Authentication" }
4
5$report = foreach ($cert in $certs) {
6    $daysLeft = ($cert.NotAfter - (Get-Date)).Days
7    [PSCustomObject]@{
8        Thumbprint   = $cert.Thumbprint
9        Subject      = $cert.Subject
10        NotAfter     = $cert.NotAfter
11        DaysLeft     = $daysLeft
12        NeedsRenewal = $daysLeft -le $thresholdDays
13        DeviceName   = $env:COMPUTERNAME
14    }
15}
16
17$report | ConvertTo-Json -Depth 3 | Out-File "C:ProgramDataCertAuditlatest.json" -Encoding utf8
18
19if ($report.NeedsRenewal -contains $true) {
20    Write-Output "Renewal required"
21    exit 1
22} else {
23    Write-Output "All certificates healthy"
24    exit 0
25}

#Step 4 — Validate Binding to the Auth Profile

Action: After renewal, confirm the new certificate thumbprint is correctly referenced in the Wi-Fi/VPN profile (many failures occur because the profile pins the old thumbprint rather than “select by template/issuer”).

Expected result: The 802.1X or VPN profile authenticates using the new certificate on the next connection attempt, with no user-visible reconnect prompt.

Evidence to capture: a successful RADIUS/NPS authentication log entry showing the new thumbprint, captured within 24 hours of renewal.

1Get-WinEvent -LogName "Microsoft-Windows-Wired-AutoConfig/Operational" -MaxEvents 20 |
2    Where-Object { $_.Message -match "EAP" } |
3    Select-Object TimeCreated, Message

#Step 5 — Build the Weekly Health Dashboard

Action: Aggregate inventory JSON into a Log Analytics table and build a simple KQL query for a weekly review, replacing the reactive ticket queue with a proactive review cadence.

Expected result: A single dashboard view showing fleet-wide certificate health, renewal success rate, and any devices stuck below the threshold for more than one renewal cycle.

Evidence to capture: a saved KQL query and a screenshot/export of the weekly review attached to the change record.

1query: |
2  CertAudit_CL
3  | where TimeGenerated > ago(7d)
4  | summarize LatestDaysLeft = min(DaysLeft_d) by DeviceName_s
5  | where LatestDaysLeft <= 30
6  | project DeviceName_s, LatestDaysLeft
7  | order by LatestDaysLeft asc

#Verification and Expected Evidence

1. Pilot group inventory report shows zero certificates below the 30-day threshold after one full renewal cycle. Evidence: exported JSON diff, before and after.
2. Webhook alerts fire correctly on a deliberately expired test certificate injected into the pilot group. Evidence: Teams message timestamp compared against the simulated expiry.
3. RADIUS/NPS logs show successful authentication using post-renewal thumbprints with no spike in EAP failure codes. Evidence: exported event log covering the 48 hours after renewal.
4. Helpdesk ticket volume for the category “VPN/Wi-Fi authentication failure” trends to zero for the pilot group across one full renewal cycle. Evidence: ticketing system report filtered by device group and category tag.

#Rollback

If the forced autoenrollment pulse causes duplicate or conflicting certificates (visible as two valid client-auth certificates with different thumbprints on one device), roll back by: revoking the newly issued certificate via the CA console, clearing the local machine certificate store entry with certutil -delstore My <thumbprint>, and allowing the standard Group Policy refresh cycle to re-enrol cleanly. Blast radius for rollback is a single device; this is not a fleet-wide action. Never revoke a certificate that is currently the only valid authentication method for a device with no alternate access path (e.g. no wired fallback) — arrange physical or console access first.

#Failure and Escalation Conditions

• Wake a human technician immediately if more than 5% of a device group fails renewal after two automated attempts — this indicates a CA-side issue (template misconfiguration, NDES/SCEP connector down) rather than an endpoint issue.
• Escalate to the PKI/CA owner if the issuing CA itself shows a certificate nearing expiry — this is a fleet-wide outage risk, not a per-device one, and sits outside the scope of endpoint remediation scripts.
• Escalate to network engineering if RADIUS/NPS logs show authentication failures with valid, non-expired certificates — this points to a trust chain or NPS policy issue, not a renewal problem, and the auto-renewal pipeline should not be blamed or retried further.

#Measuring Ticket Deflection

Baseline the current volume of certificate-expiry-related authentication tickets over the last two renewal cycles (typically visible as spikes around anniversary dates of device provisioning waves). After deploying the inventory and auto-renewal pipeline, track: tickets tagged “auth failure” or “VPN down” per month, mean days-before-expiry at which renewal actually occurs, and the percentage of the fleet with zero manual intervention required. A mature deployment should show renewal-related tickets drop to near zero, with the only remaining human touchpoints being the 5% CA-side escalation threshold and genuine hardware failures unrelated to certificates.

#Minimum Role, Blast Radius, and Monitoring Signal

The remediation script should run under the Intune system context with Certificate Manager delegation scoped only to the client authentication template — not enterprise CA admin rights. Test scope is a 25-device pilot OU before fleet-wide rollout. Blast radius of the remediation script itself is a single device per execution; the webhook alerting is read-only and cannot cause an outage. The monitoring signal to watch post-deployment is the weekly KQL dashboard result count for devices below the 30-day threshold — this should trend to a small, explainable number (new joiners, recently reimaged devices) and never grow week over week.

#Further Reading

For template and autoenrollment configuration detail, see Microsoft’s guidance on configuring certificate autoenrollment in Active Directory Certificate Services and the Intune documentation on building and deploying Proactive Remediation scripts.