WSUS SSL Configuration

Question

_{Wednesday, February 25, 2009 5:57 PM}

I have enabled SSL on the WSUS IIS for port 8531, and machines are correctly updating using SSL, however, I can no longer manage WSUS using the console on the local server or from a remote server with the management components installed.

Furthermore, I am using SSL to successfully update machines on my perimeter network through ISA 2006 with no problems at all.

The difference is that I created an DNS record for update.mydomain.com, so I am not using    computername.mydomain.local. Is this a problem?

The errors that I can when trying to connect are:

Server name: update.mydomain.com
Port number: 8531

Cannot connect to 'update.mydomain.com'. The server may be using another port or different Secure Sockets Layer setting.

As expected, I receive the following error with the following settings (due to subject name mismatch):

Server name: computername.mydomain.local
Port number: 8531

Cannot connect to 'computername.mydomain.local'. The Secure Sockets Layer (SSL) certificate for this server could not be validated.

Any ideas as to why I can no longer manage WSUS with SSL enabled using a different DNS name?

Regards,

James

All replies (4)

_{Thursday, February 26, 2009 4:28 PM ✅Answered}

The actual hostname used to access the ISA-published server is irrelevant, as long as ISA is properly configured to support the SSL publishing, and the WSUS Server's IIS is properly configured to respond to requests coming from the ISA Server. From my understanding, this was all working correctly for you.

Your issue, as I understand it, was that you could no longer connect from the MMC Admin Console after implementing SSL, but it appears you've resolved that issue by modifying the SSL certificate to support both hostname identifiers, which is essentially the remediation required from my point that changing the name of the server likely had an adverse impact on your pre-existing connections.

So, to your question, there's nothing wrong with your configuration. As you've noted, and resolved, you simply needed to provide an SSL certificate for the identifier computername.mydomain.local to support connections from your Admin Console.

I'm still doubtful that you needed to create a new naming scheme, but what's done is done, and there's no pressing reason to 'undo' it if it's working now.Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

_{Wednesday, February 25, 2009 11:18 PM}

 1. Verify that you've properly excluded the necessary virtual directories from SSL-required connections, as documented in the WSUS Deployment Guide. One of the directories that requires SSL is the APIRemoting30 webservice. Since this is where the Admin console connects, it stands to reason you'll need to reconfigure the console to connect on SSL (HTTPS), rather than the standard non-SSL connection.

2. Why you found it necessary to create a DNS record for update.mydomain.com to permit machines on your perimeter network to update is something I'm confused about. Your perimeter network, if being granted to LAN (private) resources, ought to be able to resolve the mydomain.local machine names just the same. Furthermore, even more significant, all internal resources should still be able to connect on computername.mydomain.local.

However, if you did change the name all over the place, then it begs the question of what domain you created the SSL certificate for, =AND=, have you installed this certificate on the machine(s) running the Admin Console, so they can use SSL. The fact that you're getting a 'could not be validate' error on the computername.mydomain.local indicates that you created the certificate for update.mydomain.com -- the fact that you cannot connect on update.mydomain.com suggest that the WSUS Server is still configured to connect on computername.mydomain.local -- except it doesn't have a valid SSL cert for that domain name.

Which brings us full circle back to what should be the first question: Why did you feel the need to create a new naming scenario?

Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

_{Thursday, February 26, 2009 9:45 AM}

Sorry for not making the set up clear.

As it stands, the servers that are located on the perimeter network are in a seperate forest (has it's own DNS, AD etc), and the requirement is that they must not have a direct connection to the internal network. Because of this requirement, I've had to publish WSUS through the ISA to the Perimeter's interface, as if I were managing remote clients.

I have ensured that the Virtual Directories required for WSUS to use SSL are configured so that the SelfUpdate and Content virtual directories do NOT have "Require SSL" enabled, and that the other Virtual Directories DO.

I have also run the following command line:

    wsusutil configuressl update.mydomain.com

Note that the Perimeter network machines DO have the Root and Sub CA certificates (internal network PKI), which is working as they can connect to WSUS and other published services with no problems.

By the way, I actually got the management console connecting by creating a certificate with a SAN of:
dns=update.mydomain.com&dns=computername.mydomain.local

The easiest way to understand my network is to assume that the perimeter network are remote clients coming in through an ISA server. So really the new question is, am I setting up internet-based WSUS correctly?

Regards,

James

_{Thursday, February 26, 2009 5:04 PM}

  Thank you for your response.

By the way, the naming scheme is not actually new, its the same scheme we use on the internet for many other services already. I'd guess we will be using the same "update." record externally to provide update services to remote machines in the future.

Due to the requirements of the untrusted forest on the perimeter network, any services required must act as if they were internet-based (as secure as possible!).

Kind Regards,

James