The certificate for IP-HTTPS does not rebind if the certificate is changed after the configuration is applied one time in Windows Server 2008 R2

The DirectAccess Setup Wizard does not rebind the new SSL certificate that the IP-HTTPS component uses if the certificate is changed after the configuration is applied one time. This happens only when the Network Location server is installed on a different computer, that is, the Network Location server is not installed on the DirectAccess server. In this case, remote users cannot use IP-HTTPS to connect to internal resources.

To work around this problem, manually perform the rebinding operation.

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

In the DirectAccess Setup Wizard, the administrator must select a certificate for IP-HTTPS. The administrator makes this selection on the Certificate Components page of the DirectAccess Setup Wizard. Also, the administrator must select a certificate for the Network Location server. The administrator makes this selection on the Location page of the Infrastructure Server Wizard.

If the administrator selects the first option for the Network Location server (that is, the Network Location server is not installed on the DirectAccess server) and then changes the IP-HTTPS certificate after the configuration is applied one time, a remote client cannot obtain an IP-HTTPS interface. Therefore, the remote client cannot use IP-HTTPS to connect to the internal network. This situation occurs because the new SSL certificate for IP-HTTPS is not bound to the IP-HTTPS interface.

Steps to reproduce the behavior

To reproduce the behavior, the administrator must complete the following actions:

1. Select a specific certificate for IP-HTTPS.
2. Select a specific computer as the Network Location server. This computer is not the DirectAccess server.
3. Apply the configuration.
4. Open the DirectAccess Setup Wizard again and change the certificate for IP-HTTPS.
5. Apply the configuration again.

Steps to work around this behavior

If the administrator completes steps 1 through 5 in the previous section, the administrator can manually bind the new certificate to IP-HTTPS to work around this behavior. To manually bind the new certificate, follow these steps:

1. Manually delete the old binding. To do this, open a command prompt, type the following command, and then press ENTER:
   netsh http del sslcert 0.0.0.0:443
2. Create the new binding. To do this, open a command prompt, type the following command, and then press ENTER:
   netsh http add sslcert ipport=0.0.0.0:443 certhash=<certHash> appid="{5d8e2743-ef20-4d38-8751-7e400f200e65}" dsmapperusage=enable
   Note: The certhash parameter is the SHA hash for the certificate. This hash is 20 bytes long, and you must specify this value as a hexadecimal string. You can retrieve the certificate hash value from the certificate properties. Another way to retrieve the certificate hash value is from the XML file that is created by the DirectAccess configuration. The name of the XML file is DirectAccessConfig.xml. By default, this file is located in the %systemroot%\DirectAccess folder on the DirectAccess server. This certificate hash value can be found in the XML file under the following node:
   <root>\<serverdata>\<IPhttps>\<IPhttpscerthash>
   To view the current binding, open a command prompt, type the following command, and then press ENTER:
   netsh http show sslcert