How to configure a Software Update Point to use SSL for communicating with WSUS

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:

  • WSUS_SiteBindingsOn 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:

  • WSUS_VirtualDirectoriesOn 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:

  • WSUS_SUPConfigurationOpen 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.WSUS_WSUSCtrlLog
  • The second one is the WCM.log. This log file should show a successful connection to the WSUS server on port 8531.WSUS_WCMLog

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

What is CMHttpsReadiness.exe?

CMHttpsReadinessThis time I’ve got a short post about another executable that I’ve found very useful. It’s CMHttpsReadiness.exe, which belongs to the Configuration Manager HTTPS Readiness Assessment Tool. This tool can be used to check the ConfigMgr clients if they are ready for a switch to HTTPS communication. Basically, it simply checks the certificate requirements on a ConfigMgr client device. To be honest this tool even already existed in ConfigMgr 2007, but in those times the executable was named SCCMNativeModeReadiness.exe. As this tool hasn’t been mentioned a lot, I thought it would be worth a short blog post.

Usage

This tool is installed during the ConfigMgr client installation and can also be found in the ConfigMgr client installation directory. It can simply be started via the command line, which also makes it fairly easy to create an old-school package of it. This makes it easy to verify all the existing ConfigMgr clients. To run this tool on ConfigMgr client devices, it is possible to specify the following parameters:

Parameter Maps to client.msi property
/Store: <name> CCMCERTSTORE
/Issuers: <list> CCMCERTISSUERS
/Criteria: <criteria> CCMCERTSEL
/SelectFirstCert CCMFIRSTCERT

Result

As with almost everything ConfigMgr related, the results can be followed in a log file. The log file named CMHttpsReadiness.log will list all the activities and can be found in the ConfigMgr client log directory.LogFile_CMHttpsReadiness

It gets even better. There are two buildin reports about the state messages send by the Configuration Manager HTTPS Readiness Assessment Tool. These reports can be used to determine if the ConfigMgr clients are ready for a switch to HTTPS communication. Those reports are:

  • Report_CMHttpsReadinessCount of clients capable of HTTPS communication: This report displays detailed information about each client in site that have run the HTTPS Communication Readiness Tool and reported to be either capable or incapable of communicating over HTTPS.
  • Clients incapable of HTTPS communication: This report displays detailed information about each client in site that has run the HTTPS Communication Readiness Tool and reported to be incapable of communicating over HTTPS.

Further reading

For more information about planning a transition strategy for PKI certificates and Internet Based Client Management see: http://technet.microsoft.com/en-us/library/gg712284.aspx

How to install clients on Linux computers, when the Site Roles require HTTPS communication in ConfigMgr 2012

Linux_PKI_2About four years ago I did a post about installing the ConfigMgr client on a WORKGROUP computer, when the ConfigMgr Site is in Native Mode. On the certificate side of it, this post will have a lot of similarities with that post. Installing a ConfigMgr client on a Linux computer is a nice challenge, when the ConfigMgr site is configured to require HTTPS. I think I am not the only one working with ConfigMgr and only uses a little tiny bit of Linux. So to make this process for everyone a bit easier I wrote down these four steps for implementing the correct certificates and installing the ConfigMgr client on a Linux computer. Of course these same certificate configuration steps can also be used for WORKGROUP clients and separate forests (just keep in mind that in those cases also the root certificate is required).

Prerequisites

  1. A Microsoft public key infrastructure (PKI) has to be in place.
  2. A Linux client has to be available, including the content of the ConfigMgr Client for Linux. The latest version is available for download here: http://www.microsoft.com/en-us/download/details.aspx?id=39360 

Step 1. Create a Certificate Template for Client Authentication with exportable private key.

  1. Linux_PKI_3On the Certification Authority server, open the Certification Authority Console, right-click Certificate Templates, and click Manage to load the Certificates Templates console.
  2. Right-click the Workstation Authentication template and click Duplicate Template and the Properties of New Template dialog box will show.
  3. On the Compatibility tab, make sure the Certification Authority is set to Windows Server 2003 and the Certificate recipient is set to Windows XP / Server 2003.
  4. On the General tab, set the Template display name to ConfigMgr Client Certificate for Export.
  5. On the Request Handling tab, select Allow private key to be exported.
  6. On the Subject Name tab, select Supply in the request.
  7. Click OK to close the Properties of New Template dialog box and close the Certificates Template Console.
  8. In the Certification Authority Console, right-click Certificate Templates, click New, click Certificate Template to Issue, select ConfigMgr Client Certificate for Export and click OK.

Step 2. Request and Install the Client Certificate for the Linux client

  1. Linux_PKI_4On a Windows domain joined machine, open Notepad and copy and paste the following text into the file (replace <NetBiosName> with the name of the client/ server that has to use this certificate):

    [NewRequest]
    Subject = “CN=<NetBiosName>
    MachineKeySet = True
    Exportable = TRUE
    KeyLength = 2048
    [RequestAttributes]
    CertificateTemplate = ConfigMgrClientCertificateforExport

  2. Save the file as ConfigMgrClientCertificate.inf in a folder on the machine.
  3. Open a Command Prompt and navigate to the same folder as the saved file.
  4. Use the following command to create a certificate request: certreq –new ConfigMgrClientCertificate.inf ConfigMgrClientCertificate.req
  5. Use the following command to submit the certificate request: certreq –submit ConfigMgrClientCertificate.req ConfigMgrClientCertificate.cer
  6. In the Select Certification Authority dialog box, select the CA, and then click OK.
  7. Use the following command to accept the requested certificate: certreq –accept ConfigMgrClientCertificate.cer

Step 3. Export the client certificate for the Linux client

  1. Open the Certificates Console, right-click the certificate that is issued to <NetBiosName>, click All Tasks, and then click Export to launch the Certificate Export Wizard.
  2. On the Welcome page, click Next.
  3. On the Export Private Key page, select Yes, export the private key and click Next.
  4. On the Export File Format page, confirm that Personal Information Exchange – PKCS #12 (.PFX) is selected and click Next.
  5. On the Password page, specify a password and click Next.
  6. On the File to Export page, specify the path and name of the file and click Next.
  7. On the Summary page click Finish and click OK to close the confirmation popup.

Step 4. Install the ConfigMgr client on the Linux client

  1. On the Linux client, in my case CentOS 6.4, copy the exported certificate to the folder with ConfigMgr client installation files.
  2. Open a Terminal and navigate to the location of the ConfigMgr client installation files.
  3. Use the following, or a similar, command to install the ConfigMgr client:Linux_PKI_5
  4. This will result in the installation of the client and an imported and validated certificate.Linux_PKI_6

For a complete list of all client installation parameters, see: http://technet.microsoft.com/en-us/library/jj573939.aspx#BKMK_CmdLineInstallLnUClient

Result

The best place to look at the end result is, in this case, the ConfigMgr console. This will show information about the client, activity, edition and certificate.Linux_PKI_1

Five key configuration steps for implementing Internet-based clients in ConfigMgr 2012

This blog post is about the key configuration steps for implementing Internet-based clients in ConfigMgr 2012. By key configuration steps, I’m talking about the configuration of the web server certificate, IIS, site systems, site system roles and client installations. To understand these steps, knowledge of certificates, IIS and ConfigMgr is required, because it’s not a step-by-step configuration guide.

Prerequisites

Before going through these steps, there are a few important prerequisites that should be in place:

  • Site systems for Internet-based client management must have connectivity to the Internet and must be in an Active Directory domain.
  • A supporting public key infrastructure (PKI) has to be in place, that can deploy and manage the certificates that the clients require and that are managed on the Internet and the Internet-based site system servers.
  • The Internet fully qualified domain name (FQDN) of site systems that support Internet-based client management must be registered as host entries on public DNS servers.

Configuration 1: Web server certificate

1_CertificateOne of the most important things with Internet-based client management is the web server certificate. This certificate is used to authenticate these servers to the client and to encrypt all data transferred between the client and these servers by using Secure Sockets Layer (SSL). Based on the applicable scenario this certificate only needs the Internet FQDN, or the Internet and intranet FQDN. For Internet-based client management the following two scenario’s are possible:

  1. If the site system only accepts connections from the Internet, the Subject Name or Subject Alternative Name (SAN) must contain the Internet FQDN.
  2. If the site system accepts connections from the Internet and the intranet, both the Internet FQDN and the intranet FQDN must be specified in the SAN.

Configuration 2: Default web site

Even though I will make this a very small point for Internet-based client management, it is very important not to forget. After the certificate is created it needs to be configured, with the HTTPS Type, in the Site Bindings of the Default Web Site. In case WSUS is also running on the server, and needs to be used by the Internet-based clients, the same has to be done for the Windows Administration site.

2._SiteSystemConfiguration 3: Site system

The next key configuration for Internet-based client management is the Internet FQDN in the Site system properties of the Internet-based site system. The key here is that the Internet FQDN must be exactly the same as the Internet FQDN specified in the web server certificate. When those names don’t match, the client won’t be able to verify the identity of the site system. Of course that will keep the client for assigning to the site.

Configuration 4: Site role

3_SiteRoleAfter the Internet FQDN is configured, the Internet-based site system must be configured to accept client connections from the Internet. This is a configuration that must be done per role that’s supposed to communicate over the internet. For this configuration for Internet-based client management Allow Internet-only connections, or Allow intranet and Internet connections should be configured. The Management point, Distribution point, Fallback status point, Software update point, Application Catalog website point and Enroll proxy point are all able to be configured for accepting client connections from the Internet

Configuration 5: Client installation

imageThe last important configuration is the client installation. During the installation, clients must be directly assigned to the site and be configured with the Internet FQDN of the management point. For Internet-based client management this leaves two possible installation options:

  1. Internet-only clients: Ccmsetup.exe /UsePKICert CCMHOSTNAME=”<InternetFQDN>” SMSSITECODE=”<SiteCode>” CCMALWAYSINF=1
  2. Intranet and Internet clients: Ccmsetup.exe /UsePKICert SMSMP=”<IntrenatFQDN>” CCMHOSTNAME=”<InternetFQDN>” SMSSITECODE=”<SiteCode>”

Note: For lab environments and testing it might be easy to also us /NoCRLCheck. This prevents the client from checking the certificate revocation list (CRL), before establishing an HTTPS connection.

More information

How to Configure the WSUS Web Site to Use SSL.
Step-by-Step Example Deployment of the PKI Certificates for Configuration Manager: Windows Server 2008 Certification Authority
About Client Installation Properties in Configuration Manager