I am seeing a problem with SSTP VPN on Windows Server. In particular I’m using Windows Server 2016 Essentials but I think this would also apply to Windows Server 2016/2019.
The CTW client works well, and renews the certificate without issues. It also binds it correctly within IIS.
However - and this may be a limitation in Windows Server - the problem is that the SSTP VPN server in Windows Server 2016 (probably other versions) records the current certificate thumbprint expected by the SSTP listener in the registry, and drops the VPN connection if it doesn’t match. Since CTW doesn’t update the SSTP listener with the new thumbprint, it no longer matches IIS.
The solution is to manually update the registry key at HKLM > System > CurrentControlSet > Services > Sstpsvc > Parameters > Sha1CertificateHash.
Could the CTW renewal process also update this registry key and restart IIS (with the appropriate agreement from the administrator)? Otherwise, at every renewal, the SSTP VPN breaks.
NOTE: This doesn’t affect AnywhereAccess. It’s just the SSTP VPN.
Thanks,
Gary
Currently you would use a post-request powershell script to achieve this. In the next major update we are adding a whole stack of optional deployment tasks including the option to defer specific actions until you manually invoke them or schedule them as a task (for IT maintenance windows etc).
You need to check the ‘Show advanced options’ checkbox to see the scripting option, then you need to create a powershell scrpt that will perform the update you need.
param($result) # accept the status info Certify passes into the script
# the certificate thumbprint is provided in the variable $result.ManagedItem.CertificateThumbprintHash
$result.ManagedItem.CertificateThumbprintHash # ex: "78b1080a1bf5e7fc0bbb0c0614fc4a18932db5f9"
# do something here with the thumbprint hash or other info
# ....
# ....
I don’t think you would need to restart IIS for the cert change if it’s using an IIS https binding, but SSTP is obviously a different thing altogether.
As mentioned above the upcoming deployment tasks feature will allow you to prepare these steps and automatically renew your cert while making the actual deployment a step something you can control directly if you want to (either push a button to run deployment or run a command), which is ideal for working within specific maintenance date/time windows.
And you’re correct - it’s actually the RRAS service that requires a restart to pick up the changed certificate hash, not IIS. In this example, the option to defer the deployment would work really well, because it needs careful management to manually update the certificate hash and restart RRAS if your only access to the server is via that same SSTP VPN (including scheduling a server restart for 5 minutes, in case something hangs during the changes, to give the administrator an emergency recovery option). So, yes, the automated method would be 1) install the new cert 2) copy the hash to the SSTP SHA1 registry entry and 3) restart the RRAS service to pick up the change.
If you want to avoid auto updating any bindings just because the app has renewed the certificate you can currently choose ‘Certificate Store Only’ under Deployment > Deployment Mode.
This would have the advantage of just readying the next certificate for you to use (the previous one is still stored by default) but you would then need to dig a bit deeper into each services respective scripting to update the cert hash everywhere during deployment.
I have ran into this issue with a renewed GoDaddy certificate on a Windows Server Essentials 2016. I compared the Sha1CertificateHash to the new certificate and it appears the same. There is also a Sha256CertificateHash in the registry. Is there a fix for the issue? Or how can I update this registry key? Thanks!
It will be the same issue. The difference is GoDaddy cert would be installed manually by you, and only every couple of years.
Since it’s infrequent, just update the registry key yourself and bounce the RRAS service. Here are my notes I made for myself before using a CTW script to automate it. You have probably already done the top part (since you’re getting the disconnect problem) so jump straight to “Update SSTP to match…”
Certificate needs to be changed in IIS and also SSTP listener. Mismatching certificates causes client to connect then immediately disconnect.
Certificates in use can be checked - netsh http show sslcert All bindings are listed. 0.0.0.0:443 = default web site. [::]:443 = SSTP listener. Note the existing certificate hash in case it is necessary to revert
In IIS Manager, change the certificate for the default web site (“bindings”, non-host header site on port 443) Restart IIS Admin service. SSTP VPN will no longer stay connected. Test this from a previously-working client (to generate an event log error)
Update SSTP to match newly-installed IIS Certificate:
netsh http show sslcert Note the changed hash for 0.0.0.0:443. This will need to be changed for the SSTP VPN listener (SHA1).
If no RRAS GUI (per WS2016E):
Go to HKLM\System\CurrentControlSet\Services\SstpSvc\Parameters*
Enter the “SHA1CertificateHash” key from your new certificate (old hash should match Event 6 RASMAN error)*
In general you’d want Certify to take care of any IIS bindings and use Powershell (if applicable) to set the certificate if a powershell management command is available. From my understanding the SSTP VPN certificates can be set using Powershell Set-RemoteAccess and the suggested script (https://github.com/webprofusion/certify/issues/447) was :
# Enable/redo certificate for SSTP VPN
param($result)
# Store certificate in variable
$cert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Thumbprint -match $result.ManagedItem.CertificateThumbprintHash}
# Stop RRAS, set cert, start RRAS
Import-Module RemoteAccess
Stop-Service RemoteAccess
Set-RemoteAccess -SslCertificate $cert
Start-Service RemoteAccess
The above script finds the new cert in the computer certificate store by thumbprint, then uses Set-RemoteAccess to update the certificate used for VPN.
Can you confirm this script does/doesn’t work rather than having to touch the registry?
If the above works OK I’ll build it into Deployment Tasks in the next version, that way you get a UI to add the task and you don’t have to maintain your own script.
Confirmed working. I have been using it on WS2016Ess for the past 6-12 months (saved as a .ps1 script and called from the post-request box on the Scripting page).
I think Orchidist was asking in general because he’s using a GoDaddy certificate and hence is outside the CTW program. Hence my suggestion to edit the registry directly.
On older windows the code i use is this bellow. Will the Updated app support rass on win2k8?
Because right now, the ssl is updated with this code but connections are rejected and requires a reboot of the server. (not just rras)
netsh ras set sstp-ssl-cert hash = $result.manageditem.certificatethumbprinthash
Start-Sleep -s 15
net stop remoteaccess
Start-Sleep -s 15
net start remoteaccess
Windows Server 2008 (SP2) cannot install .NET 4.6.2 which is required by Certify v5.
Windows Server 2008 R2 (SP1) can install up to .NET 4.8. This OS is not supported by Certify officially, but it may work?
It might not however solve your problem where you have to reboot as that might be OS specific.