Showing results for 
Show  only  | Search instead for 
Did you mean: 

1.0         Code Signing Certificates.

The purpose of code signing is a method to prove the origin of an item of software that came from a trusted source and that it has not been tampered since it was released by applying a digital signing to the software package.

In the case of Windows updates, the update files that sync from Microsoft to your WSUS Server are already digitally signed by the vendor, as is all device drivers from hardware vendors, and all software that you may download from other trusted software vendors.  The Windows operating requires that these items are all digitally signed before it will permit their installation.

How this applies to the Software Vulnerability Manager System is all patches that are delivered to your SVM console are delivered as an SPS Package ready to be created into an install package for deployment, with certain configuration options. 

During the creation of an installation package that is to be deployed to your client machines, the WSUS Server digitally signs the packages that are created before publishing them to your WSUS server, ready for deployment 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 to which a package was created using has expired the software will fail to install.

It is quite critical for the functionality of the SVM System that certificates are created and applied to the WSUS correctly to prevent publishing issues.

There are three ways of doing this, the first being is to obtain a code signing certificate from an external Trusted Certificate issuer, but this can be expensive, and this would only be required if you were wanting to make your WSUS Server public on the Internet.  We will not cover this scenario in this document as it is a highly unlikely scenario.

The second is on Windows enterprise networks that run a root Certification Authority to request a code signing certificate from the Root CA.  We will cover this scenario in this document.

The third method is to use a WSUS self-signed certificate generated by the WSUS server itself using the SVM connection tool contained in the console plugin.

Note:  If using a self-signed certificate, you will need to distribute the certificate to the client machines using a GPO, this is covered later in this document.

Important Note:

Creation and management of certificates will require a user with Administrative Privileges on the domain.

2.0         How to generate a Windows CA Code Signing Certificate for WSUS Code Signing Purposes.

The process of creating a Code Signing Certificate is in two parts, the first part is the configuration that will need to be undertaken is on the Windows RootCA Server, and the second part is the requesting of the certificate from the RootCA on the WSUS Server.  Please ensure you have administrative access to both of these servers before continuing.

2.1         Windows Root CA Server

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


The first thing we need to do is to create a code signing certificate template, we achieve this by selecting certificate templates in the left-hand pane and right-clicking to bring up the menu.


Now click on “Manage” and this will bring up the Certificate Templates Console

3.0         Certificate Template Console

Once the Template console has loaded look for the Code Signing template that is in the Templates list



Right Click on the Code Signing Template, and select “Duplicate Template” as shown below


Once you click Duplicate Template, the template configuration will display.

3.1         Certificate Template Configuration

There are several tabs within the template configuration that you need to set the first tab to pop up will be the compatibility tab as below:-


Compatibility Tab

  • No changes are required on this tab, please click on the general tab and see below
  • Click on the “General” tab


General Tab

  • Give the certificate template a name, in this case, I have just used “WSUSCert” as the name.
  • Set the validity period. I have used 5 years, but this can be set to a period of your choice, it makes sense to use a long validity time as this ensures all your published patches will continue to work for a long period.

  • Click on Apply


Request Handling

  • Check Allow Private Key to be exported, this is very important that it is ticked.

  • And select “Prompt the user during enrollment”

  • Click on Apply

Subject Name

  • Select “Common Name” in “Subject name format”

  • Only select UPN in the checkboxes below

  • Click on Apply


Security Tab

  • Make sure you allocate permissions for a specific user or user group to be able to Read & Enroll, this example shows authenticated users with these permissions.

  • Click Apply

Extensions Tab

  • Select Key Usage and then edit and see the next screen.



Edit Key Usage

  • Make sure that “Digital Signature” & “Make this Extension Critical” are both checked

  • Click Ok on the box, or cancel if no changes need to be made.

  • Click on Apply on the Extensions Tab


Once this part is complete you can now close the Certificate Templates console, and return to the CA Console, the next part is we need to issue the template so that it becomes available to the users to be able to request a certificate.

3.2         Certificate Authority Console – Issuing Template.

Right click on the Certificate Templates, Select New then select Certificate Template to Issue



Once you have selected New Certificate Template to Issue, the list of available templates will be displayed as per below, in the list find the name of the template you have just created, select it and click ok.


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


This completes what needs to be done on the CA, you can now log off your CA Server as you should not 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.

4.0         Requesting a WSUS Code Signing Certificate

The next part needs you to log on to your WSUS Server, the first thing that we need to do is to open an MMC Console.

Right Click on the Start menu and select run. 



When the MMC Console has started, select File then Add/Remove Snap-in


Add the Certificates snap-in



Check “My User Account” and click “Finish”


To request the certificate, first select the “Personal” folder in the left-hand pane of the Certificates console.


Right click on the “Personal” folder and select “Request New Certificate”


The certificate enrollment Wizard will now start, once the following screen appears click “Next”


By default the Active Directory Enrollment Policy is present, you should not need to make any changes on this section, please click “Next



When the types of certificates box appear, look for the Certificate Template you created earlier on the CA, and Check the Template, it should be showing as per the box below. Click on “Enroll”


When you have clicked Enroll you will be shown the results of your request, it should show succeeded.


Your new Code Signing Certificate will now appear in the “Personal\Certificates” folder as below


5.0         Exporting the Certificate.

The next part of the process we need to export the certificate to a file along with its private key, click on certificate to select it then right click, and select “All Tasks” then “Export”


5.1         Certificate Export Wizard.


  • To continue, click “Next”


  • Select “Yes, export the Private Key”

  • Click “Next”


  • Make sure “Include all certificates in the certification path” is selected.

  • Make sure “Export all Extended Properties is selected.


  • Type a password and confirm it and Click “Next”


  • Click “Browse”


  • Select a location to save the certificate, I would suggest creating a folder on C:\ and saving it there.

  • With the filename and path completed click “Next”


  • Check what is displayed looks ok and click “Finish”

  • You should now get a message saying that your Certificate Export was successful

6.0         Importing Certificate into WSUS / SCUP

PKI generated certificates can only be imported into WSUS using a PowerShell Script.  Open Powershell as Administrator on your WSUS Server.

1. Open up PowerShell as Administrator on your Upstream (Primary) WSUS server, or Software Update Point of SCCM.

2. Run the following to set the WSUS server and its configuration to an object.

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

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

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

Bear in mind, this will be a file with both the public and private keys (pfx usually). You'll need to replace the path and private key password within the placeholder values in quotes.

4. Now save the changes.


You will need to resync your Software Update Point to make the certificate display in the Software Update Point Configuration.

7.0         Troubleshooting

Certificate Stores (WSUS Server)

If you have been running with a WSUS Self Signed Certificate and are looking to move to use a PKI Certificate generated from your Enterprise Windows CA, once you have installed the certificate as above, please check the WSUS Certificate Store for the Local Computer Account, to make sure you are only showing the one certificate in the WSUS Certificate in this store and this should be the Certificate you have generated from your CA this Certificate should show you have the Private Key that corresponds to the certificate, there should be no other certificates in this store, also check that the certificate is appearing in Trusted Publishers without the Private Key.


WSUS Certificate store for Local Computer Account


Showing Private Key

Software Update Point

If you are having difficulties with synchronisation, sometimes this can be caused by the software update point not importing the certificate into the SCUP which it does during synchronisation.

To resolve this you need to open the SUP and remove all the classifications, then resync the SUP it might take a couple of goes to get it to work,  it will start a sync import the certificate as there are no classifications to sync.

You can check that the certificate is the correct one by checking the Third Party Updates tab in the SCUP configuration to see if the certificate has changed to the correct one.

Once it appears re-enable your classification and resync the SCUP.

The two logs to check for the above issues are “wsyncmgr.log” and “wcm.log”


SUP Showing PKI Certificate after Software Update Synchronisation

Was this article helpful? Yes No
100% helpful (1/1)
Version history
Last update:
‎Jun 11, 2020 10:14 AM
Updated by: