Publishing WSUS with a different URL using ssl

This article describes the steps needed to configure successfully WSUS (Windows Server Update Services) to run with a different URL (Uniform Resource Locator) (or DNS Domain Name System,FQDN Fully Qualified Domain Name) with using SSL (Secure Sockets Layer).

The Context

Have you ever set up a service on a machine, say server432.mydomain.local and published it happily with that name for years? Years go by and finally that server says that it’s time for him to go and you’re faced with the task of migrating that beloved service to somewhere else. But now you’re married to that name! Do you really want to setup a new server with that exact name, no! It’s going to be a tedious task to migrate the service under a new name and remember to change all the places where that name has been hard coded over the years.

What if you’d originally planned ahead and published the service with a name of its own? Like mypreciousservice.mydomain.local? Now with that, all you had to do was to deploy the service again on some other server, retain the service’s individual name, maybe update some A records in DNS and you’re done. Wouldn’t had that been simple!?

Enabling SSL on WSUS

Let’s say we have a running and functioning WSUS deployment going on on a server named server23.mydomain.local. It’s listening on the default port 3580 at http://server23.mydomain.local:3580 and updates are going smoothly. We now want to change the URL of the service to wsus.mydomain.local and enable SSL on it. https://wsus.mydomain.local:3581 to be exact.

I won’t burden you with the details on enabling SSL in WSUS. It’s very well documented all over the web, for example here:’s written for WSUS 3.0 SP2 but it’s applicable to Windows Server 2012 version of WSUS as well.

After following the steps (installing the certificate, setting ssl requirement to the specified virtual directories in IIS, running wsusutil.exe configuressl etc.) you fire up the WSUS Administration Console and get slapped in the face with an “access denied” error message somehow indicating that you don’t have permissions to use it.

Wait a minute!? What!? You can check that the service is working fine without any errors, clients are registering and communicating with the service. It seems that only the WSUS Administration Console is not working. Digging deeper into System and Security Logs reveals that it’s actually an authentication issue.

SPNs to the rescue

As the errors imply, the admin console is using kerberos to authenticate. Now that we are using a different the name for the service, the authentication process is unable to find an SPN (Service Principal Name) for the service and therefore, the authentication fails.

Kerberos uses SPNs to determine the account that hosts the requested service. We know that the deployed WSUS service uses the built-in local account “NETWORK SERVICE“. That account represents itself with the credentials of the local machine over the network. So in this case we need to register the SPN to the machine account that is hosting the WSUS service. Open up an elevated Command Prompt or PowerShell Session and type:

setspn -s http/wsus.mydomain.local mydomain\server23

This registers an spn in Active Directory (switch s is better than a because it checks for duplicates first). Now, during authentication, kerberos looks for the SPN for http/wsus.mydomain.local, finds out that it’s provided by server23.mydomain.local, creates the tickets and stuff, provides them to the client and the client will authenticate succesfully to the service. Now, the WSUS Console launches over ssl without any errors.

So there you have it, publishing WSUS with a different URL over SSL done right.

Final Words

To this date, I have not been able to find documentation on this from Microsoft. Why it is not documented? I find it hard to believe that it’d be so strange and weird to use a specific URL with WSUS that there has not been a need to document or at least provide guidance for it. Managing SPNs is not something that all administrators do on a daily basis, and it can be a bit intimidating at first. Maybe the wsusutil configuressl could do the magic for you?

5 thoughts on “Publishing WSUS with a different URL using ssl

  1. SSL certificates poivrde two things:1) Encryption between the browser and the web server to make sure that no one can intercept the contents of the communications.2) Authentication so that an end user can be assured that the site really is who it says it is. It doesn’t allow the site to know for sure who the user is unless the user also installs a certificate (which is very rarely done.)How you install a certificate depends on who you purchase it from and what web server software you use. Most companies that sell SSL certificates poivrde you with instructions on how to import it into your web server.An example can be found at

  2. Terrific work! This is the type of information that are supposed to be shared around the web. Shame on the search engines for now not positioning this post higher! Come on over and talk over with my web site . Thanks =)

  3. Hi, Neat post. There is an issue along with your site in web explorer, might test this? IE still is the market chief and a huge portion of other people will pass over your magnificent writing because of this problem.

  4. Pingback: Configuring SharePoint 2013 Central Administration with Kerberos authentication | One After 909

Leave a Reply

Your email address will not be published. Required fields are marked *

Please, do the math and help fight spam * Time limit is exhausted. Please reload the CAPTCHA.