Configure a multiserver farm by using a non-wildcard certificate

Workaround 1 (recommended): Use a non-wildcard certificate for the Workflow Manager components

This procedure avoids wildcard characters in the certificates that are exposed to Workflow Manager clients. It relies on auto-generated certificates (that have wildcard entries in them) for ServiceBus communications. This option works with Service Bus 1.0 and Service Bus 1.1:

1. Load-balance the WFM servers by using a hardware load balancer or Windows NLB. The virtual IP should map to load-balanced virtual IP address (VIP) for Wfmfarm.armsft.com for the three WFM servers. The DNS entry for this cert and the VIP should be created before the Workflow Manager farm is set up.
2. Obtain a secure communications TLS/SSL certificate (for example, "Web Server Certificate" in Windows Certificate Services) through CN=wfmfarm.atmsft.com. If you're using Windows Certificate Services, request the certificate by using the "Web Server" template. This cert will be used by the Workflow Manager components but not by Service Bus. Be aware that, unlike Workaround 2, this certificate does not require a DNS alternative name.
3. In the Workflow Manager Configuration Wizard, select the Custom option.
4. For Workflow Manager certificates, select the certificate that you created in the preceding steps.
5. For Service Bus certificates, select the auto generate option.
6. Complete the installation process by using the Configuration Wizard or the wizard-generated script.

This procedure has many advantages over the procedure in Workaround 2. First, it works with ServiceBus 1.1. It also lets you run the Configuration Wizard all the way through—or run the Configuration Wizard-generated PowerShell script without modification.

Workaround 1 also has a performance benefit over Workaround 2: it avoids routing Service Bus internal communications through the front-end load balancer, an extra network hop that might be expensive in a high-transaction rate environment. Finally, Workaround 1 avoids the operational compromises of Workaround 2, such as being unable to use the Get-SBFarmStatus command.

Note Workaround 1 also works in scenarios where the workflow farm’s DNS domain differs from the desired load-balanced endpoint. For example, if the servers are in a domain child.atmsft.com (for example, server1.child.atmsft.com, server2.child.atmsft.com, server3.child.atmsft.com), and you want a load-balanced URL of wfm.atmsft.com, the auto-generated certificates will not work. In this case, use the procedure in Workaround 1, using wfm.atmsft.com for the subject name of the certificate in step 2.

Workaround 2: Use a non-wildcard certificate for Workflow Manager and ServiceBus

The following workaround was tested by using Microsoft Windows Network Load Balancing (NLB). However, it should also work with hardware load balancers. This workaround only works with ServiceBus 1.0.

1. Set up a load-balanced farm of servers, and use a virtual IP address (VIP) for the farm’s selected load-balanced URL. For example, use the following load-balanced URL:
   
   
   wfm.atmsft.com
   Note DNS name resolution for the load-balanced URL must be set up before you can install Workflow Manager by using this procedure. 
2. Obtain a certificate. To do this, follow these steps:
   1. Use the Web Server certificate template for the request.
   2. Make sure that the subject name is of the Common name type and that it has a value of "wfm.atmsft.com" (load-balanced URL). 
   3. Add a Subject Alternative Name of the DNS type and that it has a value of "wfm.atmsft.com" (load-balanced URL). 
   4. Import the certificate to the Local Machine personal store of all nodes in the Workflow Manager farm.
   
   
3. Create a new farm. To do this, follow these steps:
   1. Run the Workflow Manager configuration wizard, and then select Configure Workflow Manager with Custom Settings.
   2. For all Workflow Manager and Service Bus certificates, use the custom certificate from step 2.
   3. On the last page of the wizard, click Get PowerShell script, and then save the PowerShell script.
   4. Exit the wizard, but do not actually finish it. This is because we have to customize the parameters.
   5. Change the script to update passwords, and then make all the following changes:
      • Append the following parameter to Add-SBHost:
        
        -ExternalBrokerUrl 'sb://<farmDns>'
      • Before Add-WfHost, replace the existing $SBClientConfiguration with the following:
        
        $SBClientConfiguration = 'Endpoint=sb://<farmDns>/WorkflowDefaultNamespace;StsEndpoint=https://<farmDns>:9355/WorkflowDefaultNamespace;RuntimePort=9354;ManagementPort=9355';
        
        Important The <farmDns> placeholder should be a fully qualified domain name that matches the name in the certificate. For example, use the following:
        
        
        wfm.atmsft.com
      • Update the password placeholders in the script.
      
      
      
   6. Open a Workflow Manager PowerShell window, and then run the script.
      
      Note You must run the commands in the Workflow Manager PowerShell window as an administrator.
   
   
   
4. Add two nodes to the farm. To do this, follow these steps:
   1. Use the same method that you used in step 3c to obtain the PowerShell script.
   2. Change the script in the same manner as you did in step 3d.
   3. Open a Workflow Manager PowerShell window, and then run the script.
   
   
   
5. When you register the workflow service in SharePoint, use <farmDns> for the workflowhosturi parameter. For example, use the following:
   
   
   https://wfm.atmsft.com:12290

Be aware that the Get-WFFarmStatus command does not list the status of the each workflow management IIS site. This is because of the certificate DNS difference. To check status, we recommend that you log on to each node, and then check the status from the IIS management console.