Why Revocation Checks Break SSTP VPN

SSTP (Secure Socket Tunneling Protocol) VPN uses SSL/TLS to tunnel traffic over HTTPS. When a client connects, Windows validates the server's certificate — including checking whether it has been revoked. This check works by downloading the Certificate Revocation List (CRL) or querying an OCSP (Online Certificate Status Protocol) responder published by the certificate authority.

The problem arises when the CRL or OCSP endpoint is unreachable at the moment the VPN connection is being established. Common causes include:

The user is on a restricted network (hotel Wi-Fi, guest network, mobile data) that blocks outbound HTTP on port 80
A corporate proxy intercepts or drops requests to the CRL URL
The internal CA's CRL distribution point is only reachable from inside the network (chicken-and-egg: you can't reach the CRL server without the VPN, but you can't connect to VPN without reaching the CRL server)
A firewall rule blocks the CRL distribution point URL

Windows defaults to failing the connection if revocation status cannot be confirmed. The user typically sees a generic error like "The remote connection was not made because the name of the remote access server did not resolve" or "Error 0x80092013".

⚠️Disabling revocation checking reduces your security posture. A revoked certificate can no longer be detected, which means a compromised or mis-issued certificate could be used to impersonate your VPN server. Only apply this fix when you understand and accept the risk, or as a short-term measure while you fix the underlying connectivity problem.

The Registry Key to Disable Revocation Checking

The setting is controlled by a DWORD value in the SSTP service parameters key on the client machine:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters

Add or set the following value:

Value Name	Type	Data
`NoCertRevocationCheck`	DWORD (32-bit)	`1` (to disable), `0` (to re-enable)

Applying via PowerShell

Run this on the affected client machine as Administrator:

# Disable SSTP certificate revocation check $regPath = "HKLM:\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters" # Create the key if it doesn't exist if (-not (Test-Path $regPath)) { New-Item -Path $regPath -Force | Out-Null } # Set the value Set-ItemProperty -Path $regPath -Name "NoCertRevocationCheck" -Value 1 -Type DWord Write-Host "SSTP revocation check disabled. Restart the machine or the SSTP service to apply."

To re-enable revocation checking later:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters" ` -Name "NoCertRevocationCheck" -Value 0 -Type DWord

After making the change, restart the SSTP service or reboot. You can restart the service without a reboot:

Restart-Service -Name SstpSvc -Force

Applying via Group Policy (Registry Preference)

To deploy this setting across multiple client machines through Group Policy:

Open Group Policy Management and create or edit a GPO targeting the affected computers.
Navigate to Computer Configuration → Preferences → Windows Settings → Registry.
Right-click and choose New → Registry Item.
Set Action to Update.
Set Hive to HKEY_LOCAL_MACHINE.
Set Key Path to SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters.
Set Value name to NoCertRevocationCheck, Value type to REG_DWORD, Value data to 1.
Link the GPO and run gpupdate /force on the target machines.

Understanding the Security Trade-Off

Certificate revocation exists for a good reason: if a certificate is compromised — say, the private key is stolen or a CA issues a certificate in error — revocation is the mechanism that tells clients to stop trusting it. Disabling revocation checks means:

A revoked VPN server certificate will still be accepted by clients
A man-in-the-middle attacker using a revoked (but otherwise valid) certificate won't be detected at the connection stage
You lose an important layer of the certificate trust model

This is an acceptable risk in controlled environments where the CA is internal, certificates are tightly managed, and network access is limited to trusted users. It is a poor choice if you're using a public CA-issued certificate and your VPN is internet-facing.

Better Long-Term Alternatives

Rather than leaving revocation disabled permanently, consider fixing the root cause:

Root Cause	Fix
CRL URL blocked by proxy	Add the CRL distribution point URLs to your proxy's allow list. CRL URLs are listed in the certificate's CRL Distribution Points extension.
Internal CA CRL only reachable on LAN	Publish the CRL to an internet-accessible URL (e.g., on your web server or Azure Blob Storage). Update the CA to include this URL in issued certificates.
OCSP responder unreachable	Ensure the OCSP URL in the certificate's Authority Information Access extension is reachable from client locations, or host your own OCSP responder.
Firewall blocking port 80	CRL downloads typically use HTTP (port 80). Open outbound port 80 from client machines to the CRL distribution point server.

To see the CRL distribution point URLs in any certificate, run:

# View CRL distribution points on the VPN server certificate # Run on the VPN server or any machine with the cert in its store $cert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*vpn*" } | Select-Object -First 1 $cert.Extensions | Where-Object { $_.Oid.FriendlyName -eq "CRL Distribution Points" } | ForEach-Object { $_.Format(1) }

ℹ️If you are running Always On VPN or a newer SSTP deployment, consider using a certificate from a public CA such as Let's Encrypt or DigiCert. Public CA infrastructure has well-maintained, globally reachable CRL and OCSP endpoints — eliminating this problem entirely.

How to Disable Certificate Revocation Checking for SSTP VPN