Always On VPN SSTP Certificate Binding Error

Always On VPN SSTP Certificate Binding ErrorWhen configuring a Windows Server with the Routing and Remote Access Service (RRAS) role to support Windows 10 Always On VPN connections, the administrator may encounter the following error message when installing or updating the TLS certificate used for Secure Socket Tunneling Protocol (SSTP) connections.

“The thumbprint (cert hash) of the certificate used for Secure Socket Tunneling Protocol (SSTP) is different than the certificate bound to the Web listener (HTTP.sys). Configure SSTP to use the default certificate or the certificate bound to SSL. You can configure web server applications to use the same certificate used by SSTP.”

Always On VPN SSTP Certificate Binding Error

IIS Binding

Most commonly this error can occur if an administrator mistakenly binds a TLS certificate directly in IIS. To resolve this problem, open the IIS management console (inetmgr.exe), navigate to the Default Web Site and click Bindings in the Actions section. Highlight the HTTPS binding and click Remove. Once complete, open an elevated command window and run the iisreset.exe command.

Always On VPN SSTP Certificate Binding Error

Netsh

In some instances, the administrator may find no certificate bindings in the IIS management console. However, a certificate binding may still be present. To confirm, open an elevated command window and run the following command.

netsh.exe http show sslcert

Always On VPN SSTP Certificate Binding Error

Remove existing certificate binding by running the following commands.

netsh.exe http delete sslcert ipport=0.0.0.0:443
netsh.exe http delete sslcert ipport=[::]:443

SSTP Configuration

When configuring SSTP in RRAS for Always On VPN, certificate assignment should always be performed using the Routing and Remote Access management console (rrasmgmt.msc). No changes are required to be made in the IIS management console for SSTP.

Additional Information

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

Windows 10 Always On VPN SSTP Load Balancing with Citrix NetScaler ADC Load Balancer

Windows 10 Always On VPN SSTP Load Balancing with Kemp LoadMaster Load Balancer

Windows 10 Always On VPN SSTP Load Balancing with F5 BIG-IP Load Balancer

Leave a comment

5 Comments

  1. Adam Patek

     /  September 4, 2020

    I have suggestion vaguely related to this, which I’m not sure will be relevant to many, but it was quite a catch in my environment.

    As the AlwaysOn VPN is the only resource available from the internet which uses certificates from the internal CA, I had to provide a publicly accessible CRL distribution endpoint… and where else, I thought, than on the RRAS box which had to have a public IP anyway.

    So I installed IIS and created a CDP on port 80, but then I was stuck with IIS starting quicker than RRAS and hogging the 443 port, although there was no HTTPS endpoint bound to any site.

    Therefore

    netsh http show servicestate

    netsh http delete urlacl [Registered URL belonging to the IIS]

    so IIS is no longer allowed to register 443 port and my CDP and SSTP VPN happily coexist on one machine.

    Reply
    • Thanks for the insight! To be clear, the CRL does NOT need to be publicly accessible for IKEv2. This is only a requirement for the TLS certificate used for SSTP. This is one of the many reasons we recommend using a TLS certificate issued by a public CA rather than a private internal enterprise CA.

      Reply
      • Adam Patek

         /  September 5, 2020

        That makes sense and I haven’r realized it before. Thanks for yet another invaluable piece of information!
        And thanks for keeping this awesome repository of knowledge going, it’s so much better and more comprehensive than any other source on the topic.

  2. Kristof

     /  September 10, 2020

    Hey Richard,

    We just switched from CA and updated our old always on public certificate. Once we swapped the SSL certificate on the VPN server in the Security tab and restarted the Routing service, clients had the issue that they could connect to the VPN tunnel but no traffic was sent over the tunnel.

    When putting the old certifcate back, everything started working again.

    Did you already came across this issue?

    Thanks!

    Kristof

    Reply
    • That’s not something I’ve ever encountered myself. Quite unusual for sure. I can’t imagine why changing the TLS certificate would prevent traffic from flowing through the tunnel. I’m curious to know if you tried restarting the server after that happened? As opposed to just restarting the RemoteAccess service?

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: