Mat’s Techblog

A code signing certificate is a security measure designed to assist in the prevention of malicious code execution. The intention is that code must be “signed” with a certificate that is trusted by the machine on which the code is executed. The trust is verified by contacting the certification authority for the certificate, which could be either a local (on the machine itself, such as a self-signed certificate), internal (on the domain, such as an enterprise certification authority) or external certification authority (third party, such as Verisign or Thawte).

For an Active Directory domain with an enterprise root certification authority, the enterprise root certification authority infrastructure is trusted by all machines that are a member of the Active Directory domain, and therefore any certificates issued by this certification authority are automatically trusted.

In the case of code signing, it may be necessary also for the issued certificate to be in the “Trusted Publishers” store of the local machine in order to avoid any prompts upon executing code, even if the certificate was issued by a trusted certification authority. Therefore, it is required to ensure that certificates are added to this store where user interaction is unavailable, such as running automated processes that call signed code.

A certificate can be assigned to a user or a computer, which will then be the “publisher” of the code in question. Generally, this should be the user, and the user will then become the trusted publisher. As an example, members of the development team in your organisation will probably each have their own code signing certificate, which would all be added to the “Trusted Publishers” store on the domain machines. Alternatively, a special domain account might exist specifically for signing code, although one of the advantages of code signing is to be able to determine the person who signed it.

The processes below details the steps required to generate a code signing certificate, export the certificate and private key, and import the certificate to a local machine or to a group of machines through the use of group policy.

Creating the Code Signing Certificate Template

1. Open the “Certification Authority” console on the enterprise root certification authority
2. Click on “Certificate Templates” and check if a template called “Code Signing” exists (if it already exists, there are no further steps required for this section)
3. If the “Code Signing” template does not exist, right click on the “Certificate Templates” node and select “New” -> “Certificate Template to Issue”
4. Select “Code Signing” and click OK

Generating the Code Signing Certificate

1. Open MMC under administrative context
2. Add the “Certificates” snap-in to the MMC console (select “My user account” when prompted)
3. Expand “Personal”, right click on “Certificates” and select “All Tasks” -> “Request New Certificate”
4. Select “Active Directory Enrollment Policy”
5. Tick “Code Signing” and then click on the “Details” button to the right hand side of the “Code Signing” option
6. Click on “Properties”
7. Click on the “Private Key” tab, and then expand the “Key Options” section
8. Tick “Make private key exportable” and “Strong private key protection”
9. Click OK and then click the “Enroll” button (a message may appear stating that an application is creating a protected item – click OK to acknowledge this message)

Exporting the Certificate for Publishing

1. Open MMC under administrative context
2. Add the “Certificates” snap-in to the MMC console (select “My user account” when prompted)
3. Expand “Personal”, right click on the appropriate code signing certificate and select “All Tasks” -> “Export…”
4. Choose the option “Yes, export the private key” when prompted
5. Accept the default options on the “Export File Format” screen
6. Enter a password for the private key, which will need to be entered when importing the certificate
7. Save the certificate to an appropriate location

Importing the Certificate for Trusting

Local Machines

1. Open MMC under administrative context
2. Add the “Certificates” snap-in to the MMC console (select “Computer account” and select the local machine when prompted)
3. Right click “Trusted Publishers” and select “All Tasks” -> “Import…”
4. Follow the wizard to import the exported certificate, and enter in the accompanying password that was used when the certificate was exported
5. If the certificate is no longer required to be imported by other machines, it is highly recommended that the exported file is deleted  

Group Policy

1. Open the appropriate group policy for editing
2. Expand “Computer Management” -> “Policies” -> “Windows Settings” -> “Security Settings” -> “Public Key Policies”
3. Right click on “Trusted Publishers” and select “Import…”
4. Follow the wizard to import the exported certificate, and enter in the accompanying password that was used when the certificate was exported
5. If the certificate is no longer required to be imported by other machines, it is highly recommended that the exported file is deleted

After promoting or demoting a domain controller, you might have difficulties with WSUS, namely the Windows Internal Database. This occurs because the Windows Internal Database (essentially based on the SQL 2005 database engine) has recorded the SID (security identifier) for the SQL groups it creates when the database was installed, and the domain controller operation has now rendered them invalid.

When you try re-installing WSUS, you get this error: -

"Failed to connect to SQL server

SERVER\MICROSOFT##SSEE

[DBNETLIB]ConnectionOpen (Connect()).]SQL Server does not exist or access

denied."

Additionally, Application event ID’s 17204 & 17207 and System event ID 7024 may also be logged.

Attempts to start the “Windows Internal Database (MICROSOFT##SSEE)” service also fail, as well as attempting to uninstall the Windows Internal Database from Add/Remove Programs.

In order to resolve this issue, you’ll need to follow these instructions: -

1. Open the Registry Editor
2. Expand HKLM\SOFTARE\Microsoft\Microsoft SQL Server\MSSQL.2005\Setup
3. Export all configuration of this key in case a restore is required
4. Remove the “SQLGroup” and “FTSGroup” values
5. Uninstall the Windows Internal Database from Add/Remove Programs
6. Restart the WSUS 3.0 installation

Seems that everyone is talking about McAfee today, after their software inadvertently identifies svchost.exe on Windows XP SP3 machines (only) as W32/Wecorl.a (McAfee knowledge base article KB68780 regarding the 5958 DAT update on April 21, 2010).

Workarounds have been posted both by McAfee and by the information technology community, however the following might help speed things up if you have a large line of machines to fix by hand: -

1. Download the EXTRA.DAT file from Mcafee here – https://kc.mcafee.com/resources/sites/MCAFEE/content/live/CORP_KNOWLEDGEBASE/68000/KB68780/en_US/EXTRA.zip
2. Copy the EXTRA.DAT file to a USB key
3. Create a batch file with the following content, and save it to the USB key: -

echo off
echo Copying extra.dat…
copy extra.dat “%programfiles%\Common Files\McAfee\Engine”
echo Copying svchost.exe…
copy “%systemroot%\System32\dllcache\svchost.exe” “%systemroot%\System32″
pause
echo Restarting machine…
shutdown -r -t 0

Running this batch file will copy the EXTRA.DAT file in to place, and restore the svchost.exe from the dllcache directory (if it was quarantined) and then automatically restart.

This may not work in all cases, but I have seen a fairly high success rate with machines that I have done this on.