Some notes about certificates when deploying the Configuration Manager Client to Windows workgroup computers.
There are two approaches for configuring certificates used on workgroup computers:
A unique certificate for each workgroup computer:
- The certificate deployment is more complex, but it’s more secure, and it’s the recommended approach, especially when you have access to the computers.
- The Common Name (CN) property of each certificate’s Subject will match up with the computer’s hostname.
- Ccmsetup.exe will automatically find and use the certificate based on the computer’s hostname.
- Each certificate will have its own expiration date.
The same certificate for each workgroup computer:
- The certificate deployment is easier, but it’s less secure, and it’s not really recommended. However, it’s a good approach when you have a large number of computers, or you don’t know the hostnames of the computers.
- The Common Name (CN) property of the certificate’s Subject will not match up with a computer’s hostname.
- Requires a custom ccmsetup.exe property to tell the installer which certificate to use.
- The certificate will expire on all computers at the same time.
Regardless of which approach you choose to use, the ConfigMgr Client certificate requirements are basically the same as an internal HTTPS deployment for domain-joined clients.
When creating the Certificate Template:
- Duplicate the Workstation Authentication template with Windows Server 2003 and Windows XP compatibility.
- On the Security tab, remove Domain Computers, and then add the computer account that will be used to request the certificates, and give it Enroll permissions.
- The template only needs to have the Client Authentication EKU (Application Policy).
- Allow the private key to be exported (.PFX file).
- The Subject Name is supplied in the request, not built from Active Directory information.
- Do not publish the certificate in Active Directory.
When requesting a certificate:
- A Common Name (CN) is included in the Subject Name of the certificate.
- The value of the Common Name (CN) is the hostname of the workgroup computer, or in the case of using a single certificate, a name that identifies the purpose of the certificate. For example: CN=ConfigMgrClient
- Subject Alternate Name (SAN) DNS entries are not needed, but they can be included.
When installing a certificate on a Windows workgroup computer:
- The certificate’s private key needs to be included (.PFX file).
- The certificate is installed into the local computer’s Personal container.
- All certificates in the chain are required (Root and any Intermediate certificates).
- A Root certificate should go into the workgroup computer’s Trusted Root Certification Authorities container.
- All Intermediate certificates should go into the workgroup computer’s Intermediate Certification Authorities container.
If the workgroup computers are running Windows 8.1 or newer, you can use PowerShell to import the PFX file.
Import-PfxCertificate -FilePath "C:\Path\to\ConfigMgr-Workgroup-Cert.pfx" -CertStoreLocation Cert:\LocalMachine\My -Password (ConvertTo-SecureString -AsPlainText 'Password' -Force)
Here are the PowerShell commands to import the Root & Intermediate certificates.
Import-Certificate -FilePath "C:\Path\to\RootCertFile.cer" -CertStoreLocation Cert:\LocalMachine\Root Import-Certificate -FilePath "C:\Path\to\IntermediateCertFile.cer" -CertStoreLocation Cert:\LocalMachine\CA
Installing the ConfigMgr Client
Normally, the ConfigMgr Client will select a certificate that matches the computer’s hostname. If you have a certificate that does not match the hostname, you have to tell the installer which certificate to use. This is done with the CCMCERTSEL property, and the value of this property will be used as a search string.
Here’s an example installation command for an Internet Only client:
CCMSetup.exe /UsePKICert /NoCRLCheck /Retry:1 /MP:https://ibcm.contoso.com CCMCERTSEL="SubjectStr:ConfigMgrClient" CCMFIRSTCERT=1 CCMALWAYSINF=1 SMSSITECODE=PS1 CCMHOSTNAME=ibcm.contoso.com
Note that the CCMCERTSEL property is searching the Subject of the certificate for a string that contains ConfigMgrClient, which is the value of the Common Name (CN) in my example above. Keep in mind that you could do a search for anything in the Subject of a certificate. For example, if the certificate’s Subject contained an Organization (O=Contoso), you could search for “Contoso” instead.
The CCMFIRSTCERT property tells the ConfigMgr Client to choose the certificate with the longest validity period. This will occur during installation, and each time the ConfigMgr Client checks its location. The location check process is logged in ClientLocation.log.
All ConfigMgr Client installation properties can be found here: https://technet.microsoft.com/en-us/library/gg699356.aspx
Updating the Certificate
Based on my testing, if the ConfigMgr Client is installed without the CCMFIRSTCERT property set to 1 (one), it won’t try to use a new certificate until its current certificate has expired. Additionally, the ConfigMgr Client won’t automatically scan for a new certificate when the old one expires. You will have to restart the SMS Agent Host service to trigger the scan.
Therefore, make sure you include the CCMFIRSTCERT property when you run CCMSetup.exe. Otherwise, when you deploy a new certificate, you will need to delete the old certificate, and restart the SMS Agent Host service.
My test environment included:
- A Primary Site server and an IBCM server running Configuration Manager 1706 with Hotfix Rollup (KB4042949) on Windows Server 2012 R2.
- The ConfigMgr Client was v5.00.8540.1611 installed on Windows 10 (1703).