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).
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: http://technet.microsoft.com/dd939849.That’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.
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?