When 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.”
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.
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
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
Adam Patek
/ September 4, 2020I 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.
Richard M. Hicks
/ September 5, 2020Thanks 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.
Adam Patek
/ September 5, 2020That 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.
Kristof
/ September 10, 2020Hey 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
Richard M. Hicks
/ September 10, 2020That’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?
LeeK
/ October 19, 2020Hi Richard, thanks 100x for your extensive KB that I have relied on frequently.
Re: SSTP and IKEv2 living in harmony. SSTP works perfectly for our Win10 users with an externally created CA certificate (GoDaddy, etc). IKEv2 works for our non-Win users via an internally created VPN server certificate (not using user certs at this time) and an imported CA root certificate on the client.
I realize the reasons for not using the external CA cert for IKEv2 and I don’t really want to externally publish the CRL for the internal cert. Is it one way or the other? Can I use both certs, configuring IKEv2 to always use the internal cert and SSTP the external cert? I can’t seem to find info relating to this specific question.
Thanks much!
Lee
Richard M. Hicks
/ October 24, 2020The recommendation is to use a private internal PKI to issue IKEv2 certificates and a public CA for SSTP. You do not have to publish your CRL to use internal certificates for IKEv2, FYI. That’s only required if using a private certificate for SSTP (again, not recommended). So to answer your question, yes, if you have both certificates present IKEv2 will use your internally-issued certificate (make sure it has IP Security IKE Intermediate EKU!) and SSTP can be configured to use your public TLS certificate (configured in the UI or via netsh).
Alan Pugh
/ August 8, 2021Thank you SO much. That’s worth gold. That information was exactly what I needed. Especially the mysterious case of “In some instances, the administrator may find no certificate bindings in the IIS management console.” when you need to use the netsh delete commands. Saved my bacon!
Richard M. Hicks
/ August 11, 2021I’m happy to help! 🙂