When software is downloaded, the operating system checks for the digital certificate created through code signing to assure the safety of the software attempting to be downloaded. Code signing provides proof that software came from a trusted source and hasn’t been tampered with since its release by applying digital signing to the software package.

All patches delivered to your Software Vulnerability Manager console are delivered as SPS packages ready to be created into an install package for deployment. During the creation of an installation package, the WSUS (Windows Server Update Services) server digitally signs the packages before publishing them to your WSUS server using either WSUS or SCCM. When an update or a patch is installed, the client machine verifies that the software has come from a trusted source by checking its digital signature. If it isn’t digitally signed or if the certificate has expired, the software will fail to install.

It’s critical for the functionality of Software Vulnerability Manager that certificates are created and applied to WSUS correctly to prevent publishing issues. There are three ways of doing this:

• Use a WSUS self-signed certificate generated by the WSUS server using the Software Vulnerability Manager connection tool contained in the console plugin.
• On Windows enterprise networks that run a root Certification Authority you can request a code signing certificate from the Root CA. 
• Obtain a code signing certificate from an external Trusted Certificate issuer. This can be expensive and is only required if you want to make your WSUS server public on the internet. This will not be covered in this article, as it’s an unlikely scenario.

Generate a Windows CA code signing certificate for WSUS

The process of creating a code signing certificate requires two parts. The first is the configuration that’s done on the Windows RootCA Server, and the second is requesting the certificate from the RootCA on the WSUS Server.  Ensure you have administrative access to both servers before continuing.

Configuration in Windows RootCA server

1. Connect to your Windows RootCA server and navigate to the Certificate Authority Console.

   

2. Create a code signing certificate template by selecting Certificate Templates in the left pane.

   

3. Right-click Certificate Templates and select Manage. This will open the Certificate Templates Console.

4. In the Certificate Templates Console find the Code Signing template in the templates list.

   

5. Right-click on Code Signing Template and select Duplicate Template. The template configuration will display.

   

6. There are several tabs you’ll update within the template configuration.
   1. First, select the General tab. Give the certificate template a name. In this example, it’s “WSUSCert.”
   2. Set the validity period to a period of your choice. It may be best to use a long validity time, as this ensures all your published patches will continue to work for a long period.
   3. Select Apply.

7. Select Request Handling.
   1. Check Allow Private Key to be exported.
   2. Select Prompt the user during enrollment.
   3. Select Apply.

8. Select Subject Name.

1. In the Subject name format drop-down, select Common Name.
2. Select only the User principal name (UPN) checkbox.
3. Select Apply.

9. Select Security.
   1. Provide Read and Enroll permissions for a user or user group.
   2. Select Apply.

10. Select the Extensions tab.

1. Select the Key Usage extension, then select the Edit button.

11. In the Edit Key Usage Extension tab:

1. Ensure that Digital Signature and Make this Extension Critical are both checked.
2. Select Apply and OK if any changes were made or Cancel if no changes need to be made.

12. Close the Certificate Templates console and return to the CA Console. Next, you’ll issue the template so that it becomes available for uses to request a certificate.
13. Right-click on the Certificate Templates and select New > Certificate Template to Issue.

14. A list of available templates will be displayed. In the list, select the name of the template you just created and click OK.

Your new template will now appear in the Certificate Templates container in the main Certification Authority Console.

This completes the process on the Certificate Authority. You can now log off your CA server. You shouldn’t need to connect to it again during this process unless you have a domain certificate policy that requires Certificates to be approved on the CA.

Request a WSUS code signing certificate

Next, you’ll log on to your WSUS Server.

1. Open an MMC Console by right-clicking on the Start menu and selecting Run. 

   

2. In MMC Console, select File > Add/Remove Snap-in…

3. Select Certificates, then select Add.

4. Select My User Account, then select Finish.

5. To request the certificate, right-click the Personal folder in the left pane of the Certificates console. Then select All Tasks > Request New Certificate.

   

6. The Certificate Enrollment wizard will now start. Select Next.

7. By default, the Active Directory Enrollment Policy is selected. You should not need to make any changes to this section. Select Next.

8. In the Request Certificates menu, select the checkbox next to the certificate template you created earlier on the CA, then select Enroll.

9. You will then be shown the results of your request. It should show Status: Succeeded.

Your new Code Signing Certificate will now appear in the Personal\Certificates folder.

Export the certificate

1. Next, you’ll export the certificate and its private key. Right-click on the certificate and select All Tasks > Export.

2. This will open the Certificate Export Wizard. Select Next.

   

3. Select Yes, export the Private Key then select Next.

   

4. Ensure Include all certificates in the certification path and Export all Extended Properties are selected. Then click Next.

   

5. Enter a password, then select Next.

   

6. Select Browse to select a location to save the certificate. Once the filename and file path are entered, click Next.

7. Verify the information you’ve entered is correct, then select Finish.

   

Import the certificate into WSUS/SCUP

PKI-generated certificates can only be imported into WSUS using a PowerShell Script. Follow the steps below to import the certificate.

1. Open PowerShell as Administrator on your upstream (primary) WSUS server or Software Update Point of SCCM.
2. Run the following script to set the WSUS server and its configuration to an object.

[Reflection.Assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$updateServer = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer()
$config = $updateServer.GetConfiguration()

3. Next, run the snippet below to set the new code signing certificate.

$config.SetSigningCertificate("<Path to pfxFile>", "<PFX file password>")

This will be a file with both the public and private keys (often a PFX file). You'll need to replace the path and private key password within the placeholder values in quotes.

4. Save the changes.

$config.Save()

Resync your Software Update Point to make the certificate display in the Software Update Point Configuration.

Troubleshooting

If you’re having difficulties after following this process, check the items mentioned below.

Check the WSUS certificate stores (WSUS Server)

If you’ve been using a WSUS self-signed certificate and are moving to a PKI certificate generated from your Enterprise Windows CA, once you have installed the certificate, check the WSUS Certificate Store for the Local Computer Account to ensure you’re only showing the one certificate in the WSUS Certificate in this store. This should be the certificate you generated from your CA and should show that you have the private key that corresponds to the certificate. There should be no other certificates in this store.

Also, verify that the certificate is appearing in the Trusted Publishers folder without the private key.

Software Update Point not importing certificate

If you are having difficulties with synchronization, sometimes this can be caused by the Software Update Point (SUP) not importing the certificate into the SCUP during synchronization.

To resolve this:

1. Open the SUP and remove all the classifications, then resync the SUP.  This will start a sync to import the certificate as there are no classifications to sync.
2. Check that the correct certificate is in use by reviewing the Third-Party Updates tab in the SCUP configuration (Software Update Point Component Properties > Third Party Updates).
3. Once the certificate appears, re-enable your classification, and resync the SCUP.

If you are having issues importing the certificate check wsyncmgr.log and wcm.log for errors regarding the import.