How to change machine certificate on the SSTP server

  • [アーティクル]

This blog is going to tell about how to change the Certificate to be used for the SSTP Server.

Although, the normal procedure of installing the certificate on RRAS Server for SSTP mentioned in the step by step guide works perfectly fine, this blog is going to talk about how to change the certificate which is being used on the Server for SSTP Connections.

Let's consider that the admin has successfully configured RRAS Server for SSTP using a Server Authentication Certificate SAC1 which is bound to the SSL listener setup on the server. So, the certificate SAC1 will be bound to the two IP:Port pairs 0.0.0.0:443 and [::]:443 as shown below. Here, the certificate hash shown is the SHA1 thumbprint of the certificate that you can see from the Certificates console of MMC under Certificate details.

G:UsersAdministrator>netsh http show ssl

SSL Certificate bindings:

-------------------------

    IP:port : 0.0.0.0:443

    Certificate Hash : 926af74453ad0fcbb3fe9ee62e8843329a84c6ac

    Application ID : {ba195980-cd49-458b-9e23-c84ee0adcd75}

    Certificate Store Name : MY

    Verify Client Certificate Revocation : Enabled

    Verify Revocation Using Cached Client Certificate Only : Disabled

    Usage Check : Enabled

    Revocation Freshness Time : 0

    URL Retrieval Timeout : 0

    Ctl Identifier :

    Ctl Store Name :

    DS Mapper Usage : Disabled

    Negotiate Client Certificate : Disabled

    IP:port : [::]:443

    Certificate Hash : 926af74453ad0fcbb3fe9ee62e8843329a84c6ac

    Application ID : {ba195980-cd49-458b-9e23-c84ee0adcd75}

    Certificate Store Name : MY

    Verify Client Certificate Revocation : Enabled

    Verify Revocation Using Cached Client Certificate Only : Disabled

    Usage Check : Enabled

    Revocation Freshness Time : 0

    URL Retrieval Timeout : 0

    Ctl Identifier :

    Ctl Store Name :

    DS Mapper Usage : Disabled

    Negotiate Client Certificate : Disabled

Now, the admin thinks of changing the Server Authentication Certificate. So, he will issue a Server Authentication Certificate from the same CA in the name of same External IP address of the Server. Let's call this Certificate as SAC2.

Though the Subject (CN) name of these two certificates SAC1 and SAC2 are the same, the hashes of the two certificates will be different.

Wrong Way to Change the Server Authentication Certificate:-

-----------------------------------------------------------------------------------------

The admin will delete the older Cert SAC1 from the Personal store and will store the new Certificate SAC2 in the Personal store of the Computer Account. Now, he will disable and then enable RRAS. Notice here that this will not touch the existing binding from the IP:Port pairs 0.0.0.0:443 and [::]:443.

When an SSTP based connection is made from the client to this server, the connection will go through and the admin will think as if everything went fine. Now, here is the catch. Since the HTTP stores the context of the certificate bound to the IP:Port pair, this connection has gone through using the previous certificate SAC1 which is not there anymore in the Certificate Store. The moment, admin reboots the machine, this HTTP context storage will go away and so, after the Server comes up again, when an SSTP based connection is made, it will FAIL. The admin will have no clue here why the connection is not going through now though it was going fine just before the reboot.

Correct Way to Change the Server Authentication Certificate:-

------------------------------------------------------------------------------------------

- Delete the Older Certificate SAC1 from the Personal Store of Computer Account of the Server.

- Add/Import the new Certificate SAC2 to the Personal Store of Computer Account of the Server.

- Execute the following set of commands

Case 1:- Server has only one Server Authentication Or All Purpose Certificate in the store:-

netsh http delete ssl 0.0.0.0:443

netsh http delete ssl [::]:443

reg delete HKLMSYSTEMCurrentControlSetServicesSstpSvcParameters /v SHA256CertificateHash /f

net stop sstpsvc /y

net start remoteaccess

Case 2:- Server has more than one Server Authentication Or All Purpose Certificate in the store:-

netsh http delete ssl 0.0.0.0:443

netsh http delete ssl [::]:443

reg delete HKLMSYSTEMCurrentControlSetServicesSstpSvcParameters /v SHA256CertificateHash /f

netsh http add sslcert ipport=0.0.0.0:443 certhash= <SAC2 Cert Thumbprint> appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY

netsh http add sslcert ipport=[::]:443 certhash= <SAC2 Cert Thumbprint> appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY

net stop sstpsvc /y

net start remoteaccess

<SAC2 Cert Thumbprint> : This value is present in the Certificate itself. To get this value, open the certificate by double clicking on it in the store and go to "Details" tab. Under it, there are multiple "Field" and "value" pair. Go to the last of this list. You will find something like this:-

Thumprint f8 3e 90 44 82 02 69 e6 98 07 2e 19 88 0d 30 84 06 89 a1 f9

Pick this value and remove the spaces in between. After that, it will look like

f83e9044820269e698072e19880d30840689a1f9

Use this value in place of <SAC2 Cert Thumbprint> as below

netsh http delete ssl 0.0.0.0:443

netsh http delete ssl [::]:443

reg delete HKLMSYSTEMCurrentControlSetServicesSstpSvcParameters /v SHA256CertificateHash /f

netsh http add sslcert ipport=0.0.0.0:443 certhash=f83e9044820269e698072e19880d30840689a1f9 appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY

netsh http add sslcert ipport=[::]:443 certhash=f83e9044820269e698072e19880d30840689a1f9 appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY

net stop sstpsvc /y

net start remoteaccess

After executing the above mentioned command, the IP:Port binding will look like as follows:-

G:UsersAdministrator>netsh http show ssl

SSL Certificate bindings:

-------------------------

    IP:port : 0.0.0.0:443

    Certificate Hash : f83e9044820269e698072e19880d30840689a1f9 <-------

    Application

Comments

  • Anonymous
    January 01, 2003
    Hello Friends, In my previous posting related to VPN tunnel selection , I discussed various scenarios

  • Anonymous
    January 01, 2003
    Hi All, To all our beta testers who are trying out SSTP, first of all "many many thanks from my RRAS

  • Anonymous
    January 05, 2014
    Pingback from Nightmare on VPN street with TMG and SSTP Part 1 of 4 | Blogger See, Blogger Do :>)

  • Anonymous
    January 05, 2014
    Pingback from Nightmare on VPN street with TMG and SSTP Part 1 of 4 | Blogger See, Blogger Do :>)

  • Anonymous
    January 05, 2014
    Pingback from Nightmare on VPN street with TMG and SSTP – Part 3 of 4 | Blogger See, Blogger Do :>)