Webinar: Certificate Automation for Windows Infrastructure

If you manage Windows Server workloads that require public TLS certificates like Always On VPN, DirectAccess, Remote Desktop Gateway, Internet Information Services (IIS), and others, you know that certificate expirations don’t send friendly reminders. Certificates expire quietly. Too often, end users are the ones who sound the alarm—when resources are already unavailable. Of course, this never happens at a convenient time. It’s usually the middle of the night, on the weekend.

Current State

Most Windows IT teams are still managing certificates the same way they did years ago, using spreadsheets, calendar reminders, and an assortment of renewal scripts. It usually works… until it suddenly doesn’t.

Free Webinar

I’m pleased to announce that I’ll be joining Todd Gardner from CertKit for a free live webinar on Tuesday, May 26, at 11:00 AM CDT, in which we will break down the following:

  • Why certificate mismanagement causes so much pain at scale
  • How to build real automation that works across your full environment, including internal services and vendor appliances
  • A live demonstration of CertKit showing end-to-end discovery, monitoring, and automated renewal

There will also be time for live Q&A, so bring your questions!

Join Us!

If you’re tired of patching the problem with fragile scripts and assorted reminders, join us to learn about a fully automated solution that can dramatically improve the situation. Register now and don’t miss this opportunity to reduce your TLS certificate management burden and end the need for 2 AM certificate renewal fire drills.

Webinar Details

Webinar: TLS Certificate Automation for Windows Infrastructure
Hosts: Todd Gardner (CertKit) and Richard Hicks (Richard M. Hicks Consulting, Inc.)
Date: Tuesday, May 26
Time: 11:00 AM CDT
Registration: Click here to register!

Always On VPN with PEAP Fails in Windows 11 26H1

Always On VPN RasMan Errors in Windows 10 1903

There appears to be a bug in the latest Windows 11 26H1 (no, that’s not a typo – 26H1) build affecting Protected Extensible Authentication Protocol (PEAP). In my testing, all VPN connection attempts (Always On VPN and manual/ad-hoc) failed when PEAP was used for authentication.

Windows 11 26H1

Recently, while reviewing downloads and product keys in Visual Studio, I noticed a new Windows 11 release listed: Windows 11 26H1 (business and consumer editions). I initially thought 26H1 would be ARM-only, but the download is available for x64 as well.

I’m not sure whether this is intended as a general release, because Microsoft describes it as an Insider Experimental Preview Build (28200.1873). I also don’t recall seeing Insider builds offered through Visual Studio downloads, so I’m not sure what to make of it. Either way, if you’re evaluating this build, the notes below document a VPN issue I was able to reproduce.

Troubleshooting

After preparing a Windows 11 26H1 test client, I found that the Always On VPN user tunnel would not connect. The same configuration worked on earlier Windows 11 versions. In the event log, I observed the following errors.

Error 619

When using SSTP, the event log records error code 619 (event ID 20227) from the RasClient event source, with the following error message.

The user [domain\user] dialed a connection named [connection name] which has failed. The error code returned on failure is 619.

Error 691

When using IKEv2, the event log records error code 691 (event ID 20227) from the RasClient event source, with the following error message.

The user [domain\user] dialed a connection named [connection name] which has failed. The error code returned on failure is 691.

Workaround

At the time of writing, the only workaround I’ve found to restore Always On VPN connectivity is to switch authentication from PEAP to EAP-TLS. This may not be a drop-in change for every environment, so evaluate the security and operational impact before rolling it out broadly. You’ll need to enable EAP-TLS on both the client and the NPS/RADIUS server.

Summary

I’m not convinced Windows 11 26H1 will be widely deployed soon, since it appears to be an experimental/Insider build rather than a general release. If you decide to evaluate it, plan to use the workaround above to maintain Always On VPN connectivity.

Feedback

Have you tested Always On VPN with Windows 11 26H1? If so, do you see the same behavior? Share your findings in the comments.

Additional Information

Windows 11 Insider Experimental (26H1) Preview Build 28200.1873

Always On VPN IKEv2 Security Vulnerability April 2026

Microsoft published its Security Updates for April 2026 today, and the good news is that there are no Windows Server Routing and Remote Access (RRAS) vulnerabilities this month. However, they disclosed a critical remote code execution (RCE) vulnerability that impacts deployments using Internet Key Exchange version 2 (IKEv2).

IKE Service Extensions RCE

CVE-2026-33824 addresses a security vulnerability in the Windows Internet Key Exchange (IKE) Service Extensions. This vulnerability is a Remote Code Execution (RCE) vulnerability, with a CVSS 3.1 base score of 9.8 (Critical). Always On VPN implementations that use the device tunnel or IKEv2 for the user tunnel are affected.

Impact

This vulnerability presents a unique challenge to Always On VPN administrators as IKEv2 is required to support device tunnel connections. Some implementations also use IKEv2 for the user tunnel. In either case, the vulnerable VPN server, often domain-joined, is reachable from the Internet, greatly increasing the attack surface and exposure to this vulnerability.

Recommendations

For deployments that use IKEv2 (device or user tunnel), administrators should update their RRAS server as soon as possible to protect against potential attacks on this service.

Not Using IKEv2?

If you are not using the device tunnel or IKEv2 for the user tunnel, ensure the following IKEv2 ports are blocked at the edge firewall.

  • Inbound UDP port 500 (IKE)
  • Inbound UDP port 4500 (IKE NAT-T)

In addition, consider disabling IKEv2 on the RRAS server by opening an elevated command window and running the following command.

netsh.exe ras set wanports device = "WAN Miniport (IKEv2)" rasinonly = disabled ddinout = disabled ddoutonly = disabled maxports = 0

Optionally, you can use the Routing and Remote Access management console (rrasmgnt.msc) to perform this task.

  1. Right-click on Ports and choose Properties.
  2. Select WAN Miniport (IKEv2).
  3. Click Configure.
  4. Uncheck Remote access connections (inbound only).
  5. Uncheck Demand-dial routing connection (inbound and outbound).
  6. Enter 0 in the Maximum ports field.
  7. Click Ok.

Additional Information

Microsoft Security Updates for April 2026

CVE-2026-33824 – Windows Internet Key Exchange (IKE) Service Extension RCE