First published on MSDN on Jul 09, 2009
Certificates are becoming more and more the rage for both SCCM and OpsMgr. The documentation for both products provides a great amount of information about adding certificates to the local certificates store using the MMC certificates MMC snap-in. Follow the documentation and you should be good to go. But, depending on what is being done, the MMC approach may require lots of effort to visit all of the systems needing the certificates and importing manually. Is there an easier way? Adding certificates via group policy is one option but that likely will require involving other teams. It may be simpler to just do the work yourself.
An easy way to accomplish the certificate import in bulk without the need to manually visit each system is to use the utility certutil to handle the import. The command line used with certutil can be delivered via script or via SCCM package to target systems. So, how do you import a certificate to the local certificate store using certutil? Let’s consider an example with System Center Update Publisher (SCUP). With SCUP, the certificate used for signing updates needs to be placed in the local Trusted Publishers certificate store. If using a certificate from a 3rd party like Verisign, the certificate from the intermediate CA may need to be added as well. Regardless, to construct the command line we need to know two things – the name of the store where the certificate should be imported and the name of the certificate file.
Examples are plentiful of using certufil to add certificates to local certificate stores. The one element that isn’t widely documented (at least i didn’t find it widely documented) is where to find the name of the certificate store. But, wait – isn’t the name of the certificate store the same as what is listed in the certificates MMC snap-in? Sometimes, but not always. An example is the personal store. This store is referred to as ‘my’ by the system. If you try to use ‘personal’ with certutil, the command may complete but, check the store – no certificate is listed. This demonstrates that there are two names for each cert store – the ‘user friendly’ name in the MMC and the name used by the system. You need the name used by the system with certutil. So, how do we find the system name for a particular cert store? This is what took me some time – but it’s fairly obvious once you find it. Just check the registry – HKLM\Software\Microsoft\SystemCertificates and you will see a full list of all stores defined on the system current – as shown below.
Now, remember – there are two certificate stores – the one for the local computer (shown above) and the one for the logged in user. If you want to see the stores available for the logged in user, just go to a different registry hive - HKCU\Software\Microsoft\SystemCertificates
OK, so now that we know the system store names, what command line should we use to import the certificate. Very simple. Remember our example with SCUP. Per my previous blog entry on using Verisign certificates with SCUP and the configuration required there, we need to add the certificate to the ‘Trusted Publishers’ store – known in the registry as the TrustedPublishers store. We may also need to add the intermediate trust certificate to the ‘Intermediate Certificate Authorities’ store. On Windows 2008 systems, it seems this certificate gets added automatically when importing into Trusted Publishers. On Windows 2003 systems, this doesn’t seem to be the case. Again, looking in the registry and doing a bit of investigative work, we are able to see that the ‘Intermediate Certification Authorities’ store system name is ‘CA’. So, we have at least the first and possibly the second command line we need to run.
Certutil –addstore –f “TrustedPublisher” <pathtocertificatefile>
Certutil –addstore –f “CA” <pathtocertificatefile>
Lets break down the command line. The –addstore option is self-explanatory. The –f option force overwrites any certs currently in the store and in conflict. The system name of the certificate store is next followed by the certificate file to be imported – generally in .cer format. There are other options too, such as –user to use the local users certificate store.
OK, with the certificates added to the local store and continuing with your SCUP example, now we have to modify local policy via command line to enable the ‘allow signed updates from an intranet Microsoft update service location’. Like many policies, this setting is just a registry entry. When enabled, the value AcceptTrustedPubliserCerts is added to the registry with a value of 1. So, setting this policy is really just a matter of importing this registry value to desired systems. Again, something easily done with a command line which can be executed by script or through an SCCM package. The registry entry in question is located at HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate as shown
When setting the policy through the MMC this setting is added also under the HKCU hive but, in my testing, setting the value as shown above is sufficient. A further note of caution – setting this value will only remain in effect so long as the policy is NOT overwritten from the domain or direct edit in local policy MMC. Further, it appears from my testing that if you make this registry edit directly the change will NOT show up in the local policy UI. Use this method for setting this or any other local policy only when the traditional methods are not workable.