This blog post will be about configuring a Software Update Point (SUP) to use SSL for communicating with Windows Server Update Services (WSUS). I know there are many guides out on the web detailing the standard installation of WSUS and a SUP, but not many of them are explaining (or even touching) the HTTPS/SSL configuration. Also, I’ve been getting some questions about this subject lately, so I thought it would be time to dedicate a blog post to this.
Very high-level, this post will go through the configuration of WSUS to require SSL communication and the configuration of a SUP to use SSL communication. So, actually the title doesn’t cover the complete blog post.
Prerequisites
Before we go through the configuration steps of WSUS and a SUP, I want to point out the following important prerequisites that are not part of this post:
- Server authentication certificate – This how-to assumes that the server authentication certificate, that is required to configure the HTTPS binding of the WSUS Administration website, is available. For a step-by-step procedure for creating such a certificate, see: http://technet.microsoft.com/en-us/library/gg682023.aspx#BKMK_webserver2008_cm2012
- Note: The server authentication certificate for an Internet-facing software update point requires that the Internet FQDN and intranet FQDN are both specified in the server authentication certificate. I will show the reason why in a following blog post.
- WSUS – This how-to assumes that a standard WSUS installation is performed. For a step-by-step guide for installing WSUS, see: http://technet.microsoft.com/en-us/library/hh852338.aspx
- SUP – This how-to assumes that a standard SUP installation is performed.
Step 1: Add certificate to WSUS Administration website
Now let’s start with the first step, which is adding the server authentication certificate to the WSUS Administration website. This can be the same certificate that has been used on the Default website. To add this certificate to the WSUS Administration website, by using Internet Information Services (IIS) 7.0 or higher, perform the following steps:
- On the site system server, open IIS Manager.
- Navigate to Sites, right-click the WSUS Administration website, and click Edit Bindings.
- In the Site Binding dialog box, select the https binding, and click Edit.
- In the Edit Site Binding dialog box, select the server authentication certificate in the SSL certificate box, and click OK.
- Click Close to exit the Site Bindings dialog box.
Step 2: Require SSL on WSUS Administration website
Let’s continue with the second step, which is configuring five virtual directories, of the WSUS Administration website, to require SSL. After the virtual directories have been configured, the health monitoring feature of WSUS must also be configured to use SSL. To configure these virtual directories to require SSL, by using IIS 7.0 or higher, perform the following steps:
- On the site system server, open IIS Manager.
- Navigate to Sites, and expand the WSUS Administration website.
- Select the virtual directories APIRemoting30:
- In Features View, double-click SSL Settings.
- On the SSL Settings page, select Require SSL and click Apply in the Actions pane.
- Repeat the previous step for the following virtual directories:
- ClientWebService;
- DSSAuthWebService;
- ServerSyncWebService;
- SimpleAuthWebService;
- Close IIS Manager.
The last part of this steps is to also configure the health monitoring feature of WSUS to use SSL. This can be done by using the WSUSUtil tool. To configure the health monitoring feature of WSUS to use SSL run the following command from the location <WSUS Installation Folder>\Tools:
WSUSUtil.exe configuressl <Intranet FQDN of the site system server>.
Step 3: Use SSL on Software Update Point
The third and last step is to configure a SUP to use SSL for communicating with WSUS. Without doing this the SUP won’t be able to communicate to WSUS, as it will keep on trying to communicate on port 8530. To configure the SUP to use SSL, perform the following steps:
- Open the Configuration Manager console;
- Navigate to Administration > Site Configuration > Servers and Site System Roles and select the site system server;
- In the Site System Roles pane, double-click Software update point;
- In the Software update point Properties select Require SSL communication to the WSUS server and click OK.
Results
There are a couple of methods to check if the configuration was successful. The two methods that I like the most are the log files and the registry. I won’t show the registry here, but two important values to look at are PortNumber, which should be set to 8531, and UsingSSL, which should be set to 1. These values are located in the key HKLM\SOFTWARE\Microsoft\Update Services\Server\Setup. What I do want to show are the results in the following two log files:
- The first log files is the WSUSCtrl.log. This log file should show a successful connection to the local WSUS server and it should show no unhealthy WSUS Server components.
- The second one is the WCM.log. This log file should show a successful connection to the WSUS server on port 8531.
Further reading
For more information about PKI certificate requirements for ConfigMgr, see: http://technet.microsoft.com/en-us/library/gg699362.aspx
For more information about configuring software updates in ConfigMgr, see: http://technet.microsoft.com/en-us/library/gg712312.aspx
Great timing on the blog. I had to implement this today!
What would the configuressl command be if you’ve have a SUP role running on a Site System other than your CAS and PS ? Shall I point to PS ?
We’ve got an upstream WSUS and CAS talks to it and PS talks to CAS for Sync and I’ve another Site System that has got a SUP Role (wasn’t sure what configureSSL command should be? however I just pointed the configuressl to PS and I see the sync perfectly happening as per the wcm.log however now the SOE guys came back saying the TS is failing with 0x80244018 error code and can’t patch the machines during the build ? I am yet to evaluate the logs.. but any early thoughts ?
You should always use the FQDN of the site system that’s running WSUS/SUP.
If the server is internet facing, should I use the intranet or the internet FQDN for the WSUSUtil in the WSUSUtil command line
To my knowledge, the intranet FQDN. However, it does required both FQDNs to be in the certificate. See also: https://technet.microsoft.com/en-us/library/bb633246.aspx
Hi,
Excellent and short guide. I have a question regarding sync with upstream WSUS (standalone). My primary site/SUP is offline in intranet and I have setup WSUS in DMZ with Internet connection. I am able to sync the medtadata between Offline SUP and Upstream WSUS but when unable to proceed with Download and deployment. As it requires files to be either downloaded from Microsoft or choose network location. How can I automate this, instead of manually downloading on network location?
Hi AMK,
Apologies for the late reply. The only way to automate this is by making the content available on an accessible location…
Regards, Peter
We have followed this guide but get the following error in WCM.log:
Attempting connection to WSUS server: *************.**.**.local, port: 8531, useSSL: True SMS_WSUS_CONFIGURATION_MANAGER 28/09/2018 14:11:17 4564 (0x11D4)
The remote server returned an error: (403) Forbidden.~~ at Microsoft.UpdateServices.Administration.AdminProxy
Any help would be appreciated.
Hi Bob,
You might want to have a look at the IIS log. That log file should provide more details about the exact 403 error.
Regards, Peter
I followed these steps in setting up Third Party Updates from Lenovo. The updates will synchronize and download. But when I deploy them to a machine it just gets stuck in “Downloading” and then times out. Nothing gets downloaded and installed. It’s not a boundary issue as these machines are in the correct boundary and receive all other deployments.
Any suggestions?
Hi Kel,
Did you verify the client logs to see if the client finds a download location?
Regards, Peter
Hi Peter,
Turns out the issue was on the client side. “Incorrect Hash” was being caused by previously failed attempts, if I reinstall the SCCM client or if I try a clean machine that hasn’t been used for previous driver testing it works. The Lenovo Agent is still a little finicky sometimes and gives false negatives but for the most part it is working now, thanks.
Thank you for letting us known, Kel!
Hi,
Thanks for the blog article. I have Primary Site (non-PKI) and have a SUP on a standalone dedicated server.
I need to configure WSUS and SCCM to communicate over SSL to enable me to publish third party softewrae updates (Adobe, etc) via SCCM.
If I follow the above article. Will I need to be in full PKI mode for the clients to download updates from SCCM?
Thanks,
Simon
Hi Simon,
Are you going to require SSL for everything?
Regards, Peter
Hi Peter,
No , I was just looking at meeting the requirements here for Publishing Third Party Updates in Configuration Manager, when the SUP is remote from the top-level site server.
https://docs.microsoft.com/en-us/mem/configmgr/sum/deploy-use/third-party-software-updates#additional-requirements-when-the-sup-is-remote-from-the-top-level-site-server
We don’t use a full PKI implementation and I wondered if I secured the traffic between the Primary Site and the SP whether the clients could download the updates without going full blown PKI?
Cheers,
Simon
Hi Simon,
Are your clients using the same SUP, or a different downstream SUP?
Regards, Peter
Hi Peter,
The clients are using the same SUP. We only have one SUP and it resides separate from our single Primary Site.
Cheers,
Simon
Hi Simon,
If you’re using a single SUP on which you require SSL, you require it for your connections.
Regards, Peter
Sorry new to SCCM but we have a SCCM server and separate WSUS server which is configured with the SUP role. Do I have to configure both IIS WSUS administration consoles on both servers to use SSL?
Do I need a common certificate installed on each server to use in the https settings or can I use server1.domain.local on one and server2.domain.local on the other?
Hi Mr V,
The SSL configuration is for WSUS itself, not for a server that’s only running the console.
Regards, Peter
I am new to SCCM, and taking over the existing configuration. An audit wants us to eliminate http in favor of https. We have a single SCCM server which is also the SUP and runs WSUS.
In reviewing the GPOs for endpoints, they all are pointing their software update location to the WSUS\SCCM server. The question that I have is; what purpose does it serve having the endpoints pointing to that server for Software updates, and can I just remove that from the GPO for all endpoints?
The way I understand it is this. WSUS downloads all updates. It then scans the workstations for applicable patches (DOES THIS REQUIRE THAT GPO LOCATION TO THE SCCM\WSUS Server?). The admin then selects the patches and places them into Software Update groups to deploy. Does WSUS come into play at all for this deployment process?
I can quickly appease the auditors by pushing a new GPO which removes the Software Update reference to the SCCM\WSUS server location. I just want to make sure that I don’t break anything in the process.
I understand that getting the WSUS server to securely talk with Microsoft Updates is a entire different subject.
Thanks for your help.
Hi David,
When you are using ConfigMgr for managing the updates, you want to let ConfigMgr manage the configuration of the WSUS configuration on the client (which is basically the same policy setting, but then configured via local policies). The WSUS catalog is also used by the clients for scannning for update compliance.
Regards, Peter