Always On VPN Dynamic Profile Configurator (DPC) Webinar

Managing Microsoft Always On VPN deployments doesn’t have to be complicated. Always On VPN Dynamic Profile Configurator (DPC) is a free, open-source solution that simplifies deploying and managing Always On VPN client configuration settings while extending the capabilities of native deployment methods such as Microsoft Intune VPN profiles, custom XML, and PowerShell scripts.

Whether you’re deploying Always On VPN for the first time or looking to streamline an existing implementation, DPC provides powerful features that make advanced VPN configuration easier to deploy, manage, and maintain.

Join Our Live Webinar

Join me on Tuesday, August 18, at 1:00 PM EDT for a live webinar featuring Leo D’Arcy, creator and lead developer of Always On VPN DPC. During this live session, we’ll demonstrate many of DPC’s latest capabilities and show how they can simplify even the most complex Always On VPN deployments. Topics include:

  • Configuring flexible VPN deployment strategies
  • Optimizing interface and route metrics
  • Dynamically excluding Microsoft 365 and custom domains from the VPN tunnel
  • Configuring IKE mobility settings for improved roaming
  • Defining and managing IPv6 routes
  • Deploying DPC using Active Directory and Microsoft Intune
  • Exploring additional advanced features and deployment scenarios

Throughout the webinar, we’ll share practical guidance, configuration tips, and real-world examples to help you get the most from Always On VPN DPC.

Register Today

Registration is free, but you must register in advance to attend. If you can’t attend the live session, register anyway, and you’ll receive access to the on-demand recording after the event.

We’ll also reserve time for a live Q&A at the end of the presentation, giving you the opportunity to ask questions directly to the developers and experts behind DPC.

We look forward to seeing you there!

Additional Information

Always On VPN Dynamic Profile Configurator (DPC)

Always On VPN DPC Advanced Features

Always On VPN DPC with Microsoft Intune

Migrating from Always On VPN DPC Commercial to Open Source

Always On VPN DPC Commercial Support Now Available

Always On VPN DPC Discord Channel

Always On VPN Security Updates July 2026

Microsoft released the July 2026 Windows security updates today, including several fixes that directly affect Always On VPN deployments. This month’s release addresses vulnerabilities in the Secure Socket Tunneling Protocol (SSTP), Internet Key Exchange (IKE), and the Routing and Remote Access Service (RRAS), making it an important update for organizations using Always On VPN.

SSTP Remote Code Execution

The highest-priority issue for Always On VPN administrators is a Remote Code Execution (RCE) vulnerability affecting the Secure Socket Tunneling Protocol (SSTP). SSTP is commonly used for Always On VPN user tunnel connections. Because SSTP is, by design, exposed directly to the Internet, vulnerabilities affecting this protocol deserve immediate attention. Microsoft rates this vulnerability as Critical with a CVSS base score of 8.1.

CVE-2026-50694 – Windows SSTP Remote Code Execution Vulnerability

IKE Vulnerabilities

These vulnerabilities primarily affect IKE-based VPN connections and could allow an attacker to disrupt VPN connectivity using specially crafted packets. While Microsoft rates these vulnerabilities as Important rather than Critical, organizations should still plan to deploy these updates promptly.

CVE-2026-50721 – IKEv1 Denial of Service via RSA-SHA1 authentication payload

CVE-2026-50722 – IKEv2 Denial of Service via RSA-SHA1 authentication payload

CVE-2026-12413 – IKEv2 Denial of Service via malformed fragmentation

CVE-2026-50696 – IKE Protocol Denial of Service Vulnerability

RRAS Vulnerabilities

The July 2026 security updates also address several vulnerabilities in the Windows Server Routing and Remote Access Service (RRAS). All are rated Important by Microsoft.

CVE-2026-57096 – Windows RRAS Elevation of Privilege Vulnerability

CVE-2026-49791 – Windows RRAS Elevation of Privilege Vulnerability

CVE-2026-50451 – Windows RRAS Elevation of Privilege Vulnerability

Summary

The SSTP RCE vulnerability is particularly concerning because the service is typically exposed to the Internet and could allow an unauthenticated attacker to execute code remotely. Organizations should prioritize deployment of this update. The IKE and RRAS vulnerabilities are rated Important and can generally be addressed during the next scheduled maintenance window, although administrators should avoid unnecessary delays in applying these updates.

Entra Internet Access TLS Inspection Fails with ERR_CERT_INVALID

Microsoft Entra Internet Access is a powerful cloud-based Secure Web Gateway (SWG) feature within the Entra Global Secure Access (GSA) Security Service Edge (SSE) solution. Entra Internet Access provides Zero Trust, identity-aware access to internet resources, private web-based applications, and Microsoft 365, with full integration with Entra Conditional Access.

TLS Inspection

Entra Internet Access includes an optional TLS Inspection feature that allows the GSA client to decrypt HTTPS traffic, inspect for threats, identify policy violations, and enforce Data Loss Prevention (DLP) policies. Importantly, enabling TLS inspection for GSA allows administrators to apply prompt injection protection policies to control the usage of generative AI applications.

TLS Inspection Certificate

Before enabling TLS inspection for Entra Internet Access, administrators must first create a TLS inspection certificate. This certificate must be signed by a trusted certification authority (CA). The process is simple and straightforward, and well-documented here.

Invalid Certificate Error

After enabling Entra Internet Access TLS inspection, administrators may find that all websites subject to TLS inspection are inaccessible. The browser displays the following error message:

Your connection isn’t private
Attackers might be trying to steal your information from <website> (for example, passwords, messages, or credit cards.)

NET:ERR_CERT_INVALID

Clicking on the Advanced button shows the following additional information:

<website> uses encryption to protect your information. When Microsoft Edge tried to connect to <website> this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be <website>, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Microsoft Edge stopped the connection before any data was exchanged.

You can’t visit <website> right now because the website sent scrambled credentials that Microsoft Edge can’t process. Network errors and attacks are usually temporary, so this page will probably work later.

Root Cause (Pun Intended!)

This issue can be caused by restrictions placed on the root CA. Specifically, if the root CA certificate includes a policy that restricts the CA path length (the number of subordinate CAs allowed downstream), the Microsoft Global Secure Access Intermediate CA, which issues certificates for TLS-inspected websites, cannot be validated successfully.

In this example, the root CA certificate includes a basic constraint that defines a maximum of 1 intermediate CA in the chain. Crucially, the extension is marked as Critical, so it must be enforced.

Because the root CA enforces a path length constraint of 1, the TLS inspection subordinate CA can exist beneath it, but no additional subordinate CA certificates are permitted. As a result, the Microsoft Global Secure Access Intermediate CA exceeds the allowed chain depth, causing certificate validation to fail.

Resolution

The fix for this issue is simple, yet complex. The root CA certificate must be renewed, this time without enforcing the CA path length policy. To do this, open an elevated command window on the root CA and run the following command.

certutil.exe -setreg policy\capathlength 0xffffffff

Important: If your CA hierarchy uses CAPolicy.inf to define the CAPathLength setting, update the file before renewing the CA certificate.

Next, restart the CA service for the change to take effect.

Restart-Service CertSvc -PassThru

Finally, renew the CA certificate.

certutil.exe -f -renewcert ReuseKeys

Restart the CA service once more for the change to take effect.

Restart-Service CertSvc -PassThru

Once complete, distribute the new root CA certificate to Active Directory and to Intune-managed endpoints using a Trusted Certificate device configuration policy.

Finally, configure a new Entra TLS inspection certificate in the Entra admin center to replace the old one, signed with the updated root CA certificate. Once the certificate has been uploaded, ensure it is enabled.

Important: Renewing a root CA certificate can be highly disruptive. Proceed with caution in production environments. Ensure that all enterprise assets receive the new root CA certificate in a timely manner. Alternatively, to reduce the chance of disruption, consider deploying a new root CA dedicated to Entra TLS inspection.

Result

Once these changes are made, the certificate chain will allow the Microsoft Global Secure Access Intermediate CA to exist beneath the TLS inspection CA, resulting in a valid certificate chain for TLS-inspected websites. Browsers will once again trust the dynamically generated certificates, eliminating the ERR_CERT_INVALID error.

The following certificate chain shows the corrected configuration after renewing the root CA certificate and recreating the TLS inspection certificate.

Summary

Entra Internet Access TLS inspection relies on a certificate chain that includes the Microsoft Global Secure Access Intermediate CA. If the root CA that signs the TLS inspection certificate enforces a restrictive path length constraint, certificate validation can fail, causing browsers to display ERR_CERT_INVALID errors for all TLS-inspected websites. Reviewing the certificate chain and understanding how basic constraints affect subordinate CAs can help quickly identify and resolve this issue. When deploying TLS inspection, ensure that CA hierarchy restrictions are compatible with this deployment scenario. Consider using a dedicated PKI hierarchy to minimize operational impact.

Additional Information

Tutorial: Enable Entra Internet Access TLS Inspection

Protect Enterprise Generative AI Applications with Prompt Injection Protection