As you can imagine being a Microsoft ConfigMgr PFE, I see a lot of ConfigMgr environments. I usually get asked the question by either the ConfigMgr team or the Security team “How difficult is it to go to HTTPS?” Maybe because I been doing this for what seems like forever BUT, it's all about the workflow and plan. The workflow I use is low risk and pretty solid. So let's just jump right in.
So the first thing we need to know is
“How many devices are HTTPS ready?”
To figure that out, let's look at the reports. Go to your reports and search for “HTTPS” you will get these 3 reports back.
Now as you look at these reports you will find, there is
for 2 of the 3 REPORTS:
of HTTPS Communications
Count of clients
of HTTPS Communications
Notice the description in the report says you need to execute the HTTPS Communication Readiness Tool.
That’s when you get this look:
Now once you recover from that confused look. The cmHttpsReadiness.exe tool is located in the path "%windir%\ccm". When you run this tool on clients, you can specify the following options:
These options map to the CCMCERTSTORE, CCMCERTISSUERS, CCMCERTSEL, and CCMFIRSTCERT Client.msi properties, respectively.
Now let's see what we need from here. If you just do that knee-jerk reaction and double-click the executable, you will notice a new log file that will show up in your logs directory cmhttpreadiness.log.
Below is a snippet from my lab of what a log file from a system that is capable of HTTPS communication.
Also, you can open a command prompt to the folder and execute the readiness tool with the /? switch (cmhttpsreadiness.exe /?) and, you will see similar to what is posted in the TechNet link about the tool.
Looking through the log file you can see that the readiness tool, looks at the certificates on the device. Apart of validating the certificate the COMPLETE chain is checked. If you would like to see that reflected in the log messages you would need to enable verbose logging.
Below is a regular log file from a device that IS capable of HTTPS Communication.
Now how do we do this on a much larger scale?
From the above information, we hopefully have figured out if we can run the readiness tool with or without additional switches. For the purpose of keeping it simple, I am going to make a package that will execute the readiness tool without additional switches and then continue to execute the tool on a repeat schedule.
Why is the repeat execution important?
The repeat execution is important because you are going to want to continue to watch the
effect. As the tool runs, you will find systems out there that are incapable of HTTPS communication. You will eventually find ways to fix those, and when the tool executes again you will see the device now report on the “Devices capable of HTTPS Communication report.”
Below is a snippet of the package I created and deployed to my systems:
Now that you have a package, a normal deployment goes out to my desired collection group(s) and from there just monitor your reports. Now you can use the
“Clients incapable of HTTPS Communications”
and formulate an action plan for remediation of those devices.
Below is a snippet of a device I intentionally broke
(removed the cert from the certificate store)
, so I can have the report list the device showing “Incapable of HTTPS Communications”
Our clients are ready for HTTPS communication and now you will just need to tie up the loose ends if any with the Management Point and Distribution Point Certificates.
Ok, well that is it for PART 1. Check out the links below and you will find some great detail on planning, certs, & design considerations. In Part 2 we will actually make the switch from
HTTPS or HTTP