How can I configure System Center Configuration Manager in HTTPS mode (PKI) - Part 2

[anyweb]

In a previous series of guides I showed you how to configure PKI in a lab on Windows Server 2016. In another series, I also showed you how to install System Center Configuration Manager (Current Branch) version 1802 on Windows Server 2016 with SQL Server 2017. In this lab, I will show you how to configure SCCM to utilize that PKI environment.

This series is based upon an excellent video by the talented former Microsoft Premier Field Engineer Justin Chalfant here. If you haven't seen it yet, do check it out.

The intention here is that after you've completed this PKI enabled SCCM lab you can then use this in future guides, and to dig deeper into new technologies from Microsoft, for example enabling a Cloud Management Gateway and/or Cloud Distribution Point and using later on, using Co-Management.

Note: To complete this lab you must first complete the PKI Lab series (8 parts) and then install a new virtual machine within that PKI lab running System Center Configuration Manager (Current Branch) version 1802 utilizing this series (4 parts), that installation of Configuration Manager will be in HTTP mode. In addition, you must configure the Software Update Point role (in HTTP mode) on CM01 See this guide (step 2 onward) for details. For details how to configure that, see this post. It will take some time to setup but you'll be glad you did. Also, don't do this in production without consulting with a PKI Expert. I don't claim to be one, I'm just helping you get it up and running in a lab. This is intended for use in a lab only.

In part 1 of this series you created an Active Directory Security Group to contain your SCCM servers that host IIS based roles such as Distribution Point, Management Point and Software Update Point, you then rebooted that server after adding it (CM01) to the group. You then created 3 certificate templates for SCCM on the Issuing CA server (IssuingCA) and issued them so that they could be available to applicable computers. You verified that you had a GPO in place for AutoEnrollment before requesting the IIS and DP/OSD Certificates on the IIS Site System (CM01) using certlm.msc.

Step 1. Edit bindings in IIS for the Default Web Site and WSUS Administration Websites

On the SCCM server (CM01), start Internet Information Services (IIS) Manager, expand Sites so that you can see the Default Web Site and the WSUS Administration websites listed. Select the Default Web Site, this web site is where the management point, distribution point and other SCCM roles such as Application Catalog can be found (if they are installed).

Edit bindings on the Default Web Site

Right click on the Default Web Site and choose Edit Bindings from the options available.

In the window that appears, select the https section (port 443) and choose Edit.

In the SSL certificate dropdown menu, select SCCM IIS Cert.

Click OK and then click Close.

Verify changes made

Once done, you can open up Internet Explorer and verify that it's reporting back in HTTPS mode for the default web site by browsing to the following addresses to verify the Netbios name and FQDN resolve in HTTPS mode. Click on the Lock in the address bar to get info about the connection.

• https://cm01
• https://cm01.windowsnoob.lab.local/

Edit bindings on the WSUS Administration Web Site

Repeat the above operation, on the WSUS Administration website (note that it uses port 8531 for https mode).

click OK and Close when done.

Step 2. Modify WSUS Administration SSL Settings

WSUS itself requires some additional changes documented here (1) that we need to configure to allow WSUS to use HTTPS. In the Internet Information Services (IIS) Manager, expand sites and selct WSUS Administration. Select ApiRemoting30 under the WSUS Administration web site, in the right pane, click on SSL Settings and select Require SSL and verify that Ignore is selected before clicking Apply.

Next, select ClientWebService under the WSUS Administration web site, in the right pane, click on SSL Settings and select Require SSL and verify that Ignore is selected before clicking Apply.

Next, select DSSAuthWebService under the WSUS Administration web site, in the right pane, click on SSL Settings and select Require SSL and verify that Ignore is selected before clicking Apply.

Next, select ServerSyncWebService under the WSUS Administration web site, in the right pane, click on SSL Settings and select Require SSL and verify that Ignore is selected before clicking Apply.

Finally, select SimpleAuthWebService under the WSUS Administration web site, in the right pane, click on SSL Settings and select Require SSL and verify that Ignore is selected before clicking Apply.

Step 3. Configure WSUS to require SSL

In an administrative command prompt on CM01, browse to the location of WSUS installation files.

cd C:\Program Files\Update Services\Tools

Next issue the following command where CM01.windowsnoob.lab.local is the Fully qualified domain name of your ConfigMgr server hosting WSUS.

WsusUtil.exe configuressl cm01.windowsnoob.lab.local

The results are shown below:

Step 4. Configure SCCM to use HTTPS

In this step you will configure SCCM to operate in HTTPS mode. To do that, first bring up the site properties in the SCCM Console on CM01. To bring up the site properties, select the Administration workspace, select Site Configuration, select your site and in the ribbon choose Properties. Next, click on Client Computer Configuration, select HTTPS only from the options and then select Apply.

Note: If you have both HTTP and HTTPS site systems in your environment, keep the second box checked (HTTPS or HTTP) and enable the Use PKI client certificate (client authentication capability) when available check box.

Step 5. Configure Trusted Root Certification Authorities

Note: If you fail to add the Root CA (ROOTCA_windows noob Root CA.crt) specified here, PXE boot will fail to download policy after entering the PXE password.

In the site properties screen, click on Communication Security and then click on Set beside Trusted Root Certification Authorities, and click on the yellow star to add your Root CA, in this case, the Root CA for your lab (from the offline root ca), in other words point it to the ROOTCA_windows noob Root CA.crt file which is the Trusted Root Certificate for this site (the Root CA cert).

 

Step 6. Verify that the Distribution Point, Management Point and Software Update Point are using SSL

Next you need to verify the DP (and perform some additional configuration), MP and SUP roles are using SSL. To do this, select the Administration workspace in the console, click Site Configuration, select Servers and Site System roles, and select the Distribution Point role.

Right click it and choose Properties to bring up the Distribution Point role properties. You should see that it is already configured for HTTPS.

Next you need to add the certificate used by clients being imaged by operating system deployment in WinPE or for WorkGroup based clients, to do so, click on Import Certificate and select Browse, browse to the location where you saved the OSD Cert.pfx file (which you created in Step 5 of part 1 here), enter the password you specified, and click Apply.

Click OK to close the Distribution Point role properties.

For more info on the DP Cert requirements see - https://docs.microsoft.com/en-us/sccm/core/plan-design/network/pki-certificate-requirements

Next, select the Management Point role properties, they are shown below, again, HTTPS is selected by default as you set it site wide with the HTTPS only option.

When you selected HTTPS Only in the Client Computer Communication of the site properties, this initiated the Management Point to reinstall itself with the new settings, as you can see here in the sitecomp.log.

In addition in the mpsetup.log you can see that it's configured for SSL

Finally you can check mpcontrol.log this log logs the status of your Management Point, and in there you can verify that the Management Point is up and running and communicating OK in HTTPS mode and that it has successfully performed Management Point availability checks.

Next, double click the Software Update Point role to review it's properties. Place a check in the Require SSL communication to the WSUS Server check box.

Click Apply and click OK to close the Software Update Point properties. At this point open the WCM.log and look for a line that reads

Quote

Setting new configuration state to 2 (WSUS_CONFIG_SUCCESS)

Step 7. Verify Client Received Client Certificate and SCCM Client Changes to SSL

Logon to the Windows 10 1803 client and start and administrative command prompt, from there launch certlm.msc to bring up Certificates on the Local Machine. Browse to Personal and Certificates, and you should see the SCCM Client Certificate listed.

Note: I assume you've already installed the ConfigMgr client agent using whatever method your prefer on the Windows 10 1803 virtual machine.

Next, open the Control Panel and locate the Configuration Manager client agent in System and Security, and open it.

If the client was just installed the Client Certificate will probably state Self-Signed (or None if you have just installed the client..).

After a couple of minutes, close and then reopen the client and you should see that the Client Certificate states PKI.

At this point, open the ClientIDManagerStartup.log in C:\Windows\CCM\Logs and you can see Client PKI cert is available.

You can also verify client communication to the Management Point in the CCMMessaging.log and we can see it's successful in that communication.

Job done ! You've successfully converted SCCM from HTTP to HTTPS using your PKI lab, and you've verified that the client is operating in HTTPS mode. In the next parts we'll look at the Cloud Management Gateway and Cloud Distribution Point.

Recommended reading

(1) - https://technet.microsoft.com/en-us/library/bb633246.aspx

• https://docs.microsoft.com/en-us/sccm/core/plan-design/network/pki-certificate-requirements
• https://www.enhansoft.com/how-to-setup-ssrs-to-use-https-part-1/

 

 

[chaosisbliss]

These are fantastic articles.  I've compiled a 40 page document from various YouTube videos including Justin's. I have referenced multiple official Microsoft documents on top of the videos as well. Nowhere did any of those mention anything about your Step 5 Configure Trusted Root Certificates. I even went back to Justin's video to confirm lol.  So, thank you for that.  I have updated my documentation to include this particular step. 

I do have custom boot images as we use Adaptiva. I'll have to update it with the OSDCert.crt manually.  They provide a wonderful powershell script to accomplish this task. 

 

Thanks for your work. 

[anyweb]

glad to hear it, and thank you for the thanks

[Rasmond33]

Nice Guide.?

[ajp]

Great post, thanks for this!

Just a question for if you are running SQL on a separate box - what cert do you need in this situation?

Thanks,

AJP

[anyweb]

remote sql is not recommended,

but if you are using it, see here https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/network/pki-certificate-requirements

 

Site system servers that run Microsoft SQL Server

This certificate is used for server-to-server authentication.

Certificate requirements:

• Certificate purpose: Server authentication

• Microsoft certificate template: Web Server

• The Enhanced Key Usage value must contain Server Authentication (1.3.6.1.5.5.7.3.1)

• The Subject Name must contain the intranet fully qualified domain name (FQDN)

• Maximum supported key length is 2,048 bits.

This certificate must be in the Personal store in the Computer certificate store. Configuration Manager automatically copies it to the Trusted People Store for servers in the Configuration Manager hierarchy that might have to establish trust with the server.

[eavenhuang]

I'm running in HTTPS with PKIs but I think I'm missing something when it comes to PXE as I'm getting the following messages spammed in my SMSPXE.log file whenever a machine tries to PXE boot: 7096 0x1bb8 in ssl but with no client cert.

I went to Administration, Security and then Certificates. In there I had 2 out of 3 blocked DP certificates and the issued to fields were showing as GUIDs rather than actual FQDNs.

 

im using CB 2309 and I could find one cert being expired since March 2023 if I searched via certlm.msc and indicated it was in Persona folder but I didn't see it if browsed to the folder in the mmc. I have no idea what this expired cert is and how to renew it. 
 

in your article, to my understanding it seems to be something to do with the DP certificate, do I simply export a new certificate from certlm.msc and import it again to the DP properties on SCCM console?

Any ideas?

Edited February 10 by eavenhuang