One of the challenges that some customers face when configuring AMT support in SCCM is certificates. There are two types of certificates needed.
Provisioning certificate – This certificate is used to connect with AMT capable systems in preparation for provisioning. AMT systems with firmware 2.2.x, 2.6.x and 3.2.1 or higher all support the use of the provisioning certificate. Provisioning certificates are normally obtained from a provider such as Verisign, Comodo, GoDaddy or StarField. The BIOS of AMT systems is preconfigured to support certificates from these providers so no additional work is needed. You can also use a certificate generated by a Microsoft Certificate Authority but that requires additional work and is only supported by AMT 3.2.1 or higher.
AMT client certificate – This certificate is generated during the provisioning process, is specific to each AMT client and is used for ongoing management of the AMT client. This certificate is generated by a Microsoft Certificate Authority and is an automated process.
Obtaining and setting up these certificates requires specific steps which I won’t go into here. Once the certificates are configured, however, it is useful to have a way to verify they are configured correctly. I wrote the attached tool to address this need. CertValidator.vbs is a vbscript that will check both the provisioning certificate and perform a test request of the client certificate to ensure all is configured properly.
The CertValidator.vbs utility is designed to run on Windows 2003 and Windows 2008 servers and uses the following command lines:
Provisioning certificate check:
cscript CertValidator.vbs 1 <certificatefile> <certificatepasswod>
Client certificate check:
cscript CertValidator.vbs 2 <name of CA in format server\CA>
If all command line variables are correct, testing proceeds. The screenshot below shows sample output from certificate checking. Note that not all checks pass but a failure does not necessarily indicate an invalid certificate. Depending on the certificate provider, the structure of the certificate may cause some tests to fail yet, the certificate is valid due to the result of other checks.
Note: During script testing I ran the provisioning certificate check mostly on the computer hosting the certificate authority itself and this is the system where I would recommend running the tool when checking for provisioning certificate health.
The following screenshots show the CertValidator.vbs being used to connect to and perform a test request of a client web certificate for AMT use:
If all of the command line options are correct then checking begins. During this process the script will connect to the specified certificate authority, request a test web certificate, retrieve the certificate from the certificate authority and check the certificate for validity.
Note: During script testing I ran the client certificate check mostly on the computer hosting the certificate authority itself and this is the system where I would recommend running the tool when checking for provisioning certificate health.
When the SCCM server requests a web certificate on behalf of an AMT client it does so in the context of the SCCM computer account. The documentation for configuring security on the certificate authority discuss how to setup security on the AMT web template to allow for this to work. For SCCM, template security should allow the SCCM site server computer account read, enroll and autoenroll permissions. This is generally done by group. If you are using groups, ensure the SCCM site server in question is a member of the group. The is shown in the screenshot below
For this version of the CertValidator utility, the context of the user running the tool is used to interact with the certificate authority so a temporary change to security on the AMT web template is required. To make the change, open your certificate authority console, right-click on certificate templates and select manage. Locate your ConfigMgr AMT Web Server Certificate, right-click and select properties. Add your user account or a group containing your user account to have Read, Write and Enroll permissions. In my lab I’ve granted these permissions to the Authenticated Users group.
Error checking is built into the script but likely doesn’t catch everything. There may be timing issues in some environments so if the script fails the first time, run it a few times to make sure you aren’t affected by timing problems. Screenshots of other errors you may encounter are below
Please send in your feedback as I want to make sure this tool is usable for the community.