If you have ever installed WSUS, you have probably noticed that the main WSUS Administrator screen gives you a warning if WSUS is not configured to use SSL encryption. I have talked to some people who believe that SSL encryption is not necessary if the WSUS server is not exposed to the Internet. After all, the server is a trusted member of your network and is maintained by the administrative staff, so there is no need for SSL if it is not servicing external clients, right?
If you stop and think about it, it does seem a bit silly to encrypt security patch downloads. The reason why Microsoft recommends using SSL encryption with WSUS doesn’t really have anything to do with encryption though. It has more to do with integrity. SSL encryption is certificate based. When a client connects to a WSUS Server (or to any other type of Web server for that matter) and requests SSL encryption, the server uses its certificate to encrypt the data. More importantly in this case though, the certificate proves the server’s identity and it also proves that the data has not been modified in transit.
So why is this important? Imagine for a moment that a hacker set up a WSUS server of their own. Let’s up the ante by saying that they modified all of the patches on the server so that they contained some really nasty malicious code. Once the hacker had set up the WSUS server, they could either change the host record on your DNS server to point to their malicious server, or they could use a malicious script similar to what many spyware mechanisms use to modify your workstation’s HOSTS file. The end result is that your clients think that they are connecting to your WSUS server, when in reality they are connected to a malicious WSUS server that has now infecting all of the machines on your network with evil Trojans. On the other hand, if your WSUS server had been configured to use an SSL certificate, then the server’s identity could be checked each time that a client requests a patch.
Acquiring a Certificate
As I explained earlier, SSL encryption is certificate based. Therefore, the first step in the process is to get your hands on a certificate that the server can use. There are several reputable third party certificate authorities that will sell you an SSL certificate. I have personally used VeriSign in the past, and Thawte and Digicert are also good. However, Windows Server 2003 can be configured to act as a certificate authority. If your WSUS server is only going to be servicing internal clients, then there isn’t a reason in the world why you can’t use your own internal certificate authority to provide the SSL certificate and save yourself the expense of a third party certificate. For the purposes of this article, I will be assuming that you are using a certificate that was issued by a local, Windows Server 2003 based, certificate authority.
Requesting the Certificate
Since the certificate is coming from an internal certificate authority, I’m going to assume that you do not yet have the certificate. You must therefore issue a certificate request to the certificate authority. To do so, open the Internet Information Services (IIS) Manager console from the WSUS Server’s Administrative Tools menu. When the console opens, navigate through the console tree to the Web site that contains the WSUS related virtual directories (it’s the Default Web Site by default). Right click on the Web site and select the Properties command from the resulting shortcut menu to display the Web site’s properties sheet. When the site’s properties sheet opens, select the Directory Security tab and then click the Server Certificate button. Doing so will cause Windows to launch the Web Server Certificate Wizard.
Click Next to bypass the wizard’s Welcome screen and you will see a screen asking you to select the method that you want to use for the Web site. Choose the Create a New Certificate option and click Next. The next screen that you will see basically just asks you if you want to request the certificate now or later. Choose the Send the Request Immediately option and click Next.
The following screen has a couple of important configuration options. First, you must provide a name for the new certificate. Default Web Site is entered by default, but you shoiuld really use something more descriptive. I recommend using a name that includes the name of the server and a reference to WSUS. The other important setting on this screen is the bit length for the encryption. The higher the bit length, the stronger the encryption. I know that there are some people who will disagree with me on this one, but I recommend going with the default value of 1024 bit encryption, even though much higher encryption strengths are available. The reason why I am recommending this is because higher bit lengths tend to effect performance, and the server is going to be sending out a high volume of encrypted data (think about how big some service packs are). You really don’t want the server’s performance to suffer too much. Besides, the main reason why we are using SSL is for identity confirmation, not so much for encryption.
Click Next and you will be asked to enter the name of your organization and the server’s organizational unit. The organizational unit basically just refers to the department that the server services. It does not refer to an organizational unit in the Active Directory sense. Click Next and you will be prompted to enter a common name for the server. If the server is going to be servicing external clients then you will have to use the server’s DNS name. Otherwise, you can use the server’s NetBIOS name. Click Next and you will be asked to enter the city and state that the server resides in. Enter this information (do not abbreviate the state) and click Next. You will then be prompted to enter an SSL port number. Go with the default value of 443, click Next and it’s time to select your certificate authority. Assuming that you have previously created an enterprise certificate authority, then the wizard will pull the names of your certificate authorities from the Active Directory. All you have to do is to pick a server and click Next.
At this point, you will see a summary screen for your certificate request. Verify that everything appears to be correct and then click Next followed by Finish to complete the request.
Approving the Request
Now that you have issued a request, the request must be approved by your certificate authority. Depending on how the certificate authority is configured, the certificate might be installed automatically or an administrator might have to go to the certificate authority server and approve the request. One way to tell whether or not the certificate has been automatically installed is to go to the Default Web Site’s Properties sheet, select the Directory Security tab and click the Server Certificate button like you did earlier. When the wizard starts, click Next to bypass the Welcome screen, but take note of the next screen that you see. If it contains options such as Renew the Current Certificate and Remove the Current Certificate than the request has been completed. Click Cancel twice to close any open dialog boxes.
Enforcing SSL Encryption
Now that you have the necessary certificate, you must configure IIS to use it. To do so, expand the Default Web Site in the IIS Manager console and then right click on the WSUSAdmin virtual directory and select the Properties command from the resulting shortcut menu. You will now see the properties sheet for the WSUSAdmin virtual directory. Select the properties sheet’s Directory Security tab and then click the Edit button that’s found in the Secure Communications section. Select the Require Secure Channel (SSL) check box and click OK, Apply, and OK.
Now you must test your ability to access the WSUS Web site. Go to http://servername/WSUSAdmin/ the request should fail. Now change the HTTP to HTTPS and the request should be successful.
The last thing that you must do is configure the clients so that they use HTTPS to download updates. If you are using a group policy to force clients to download updates from your WSUS server then the process is simple. Simply modify the policy and all of the clients will be updated dynamically!
Conclusion
In this article I have explained that although encryption isn’t really necessary when clients are downloading patches, it is important to be able to confirm the WSUS server’s identity. I then went on to show you how to implement SSL encryption for this purpose.
