Implementing Ivanti Patch for SCCM (Part 2): WSUS Code Signing Certificate

Implementing Ivanti Patch for SCCM (Part 1): Introduction, Planning and Installation
Implementing Ivanti Patch for SCCM (Part 2): WSUS Code Signing Certificate
Implementing Ivanti Patch for SCCM (Part 3): Ivanti Settings
Implementing Ivanti Patch for SCCM (Part 4): Publishing a Third-Party Update
Implementing Ivanti Patch for SCCM (Part 5): End-to-end Demonstration

Part 2 of this guide is a pretty beefy one, as we prepare a code signing certificate for WSUS to use to sign the third-party patches. If you are going to use your own internal PKI, you must also be using WSUS over SSL, which I also explain how to configure in the first half of this part. If you are not going to use an internal PKI and just want to use a self-signed certificate, skip down to the second half of this page. At the end of this page there is one more setting that must be configured in GPO – don’t miss it!

In order to follow the steps in this part of the guide, your account needs to be a member of the WSUS Administrators group on your WSUS server.

Code signing using your internal PKI to generate a certificate

This guide assumes you already have a functional internal PKI powered by Active Directory Certificate Services. If your internal PKI is powered by a different PKI provider, you will need to follow guidance from them (or another blogger!) If you do not have an internal PKI, you should consider implementing one, or use the next section of this blog post to use a self-signed certificate.

First things first. In order to import a certificate from your internal PKI to WSUS, you must connect to WSUS over SSL. This is because you will be sending a private key from Ivanti to WSUS, and if this was captured in transit by a bad guy it could be used to sign code that would be trusted by all clients in your organisation. If you already have an internal PKI up and running, you may have already configured this. However, as it is not a requirement for using WSUS (or using WSUS with SCCM) it is also possible that you have not. These next few paragraphs explain how to configure WSUS over SSL (if you have already configured this, skip ahead a bit).

Log on to your WSUS server and open IIS Manager (or open IIS Manager on a management server and connect to your WSUS server). Select the server name on the left and find the Server Certificates icon among the sea of icons on the right. Double click on it, and then select Create Domain Certificate from the list of Actions. Fill in the information (make sure the common name is the name of the WSUS server).

Distinguished Name Properties

Click Next. On the next screen, click select and chose your issuing certificate authority. Give it a friendly name such as WSUS SSL Certificate. Click Finish and a certificate should be issued and added to the list of available server certificates.

Now expand Sites on the left and select WSUS Administration. Click on Bindings in the list of Actions on the right, select https and click Edit. On the SSL certificate drop down select the certificate you just issued and click OK. Click Close to close the Site Bindings window. Now expand the WSUS Administration site and select ApiRemoting30. Double click on the SSL Settings icon and tick Require SSL. Click Apply on the right. Repeat that that process for the following directories: ApiRemoting30, ClientWebService, DssAuthWebService, ServerSyncWebService and SimpleAuthWebService.

Require SSL on WSUS Directories

Open an administrative CMD prompt and change the directory to C:\Program Files\Update Services\Tools using the following command:

cd "C:\Program Files\Update Services\Tools"

Execute the following command to tell WSUS to start using SSL (replacing WSUS_SERVER with the fully qualified domain name of your WSUS server):

WSUSUtil.exe configuressl WSUS_SERVER 

Configure WSUS SSL

Finally, restart the WSUS Service to make sure these settings are effective. To test that it is working, open the WSUS Management Console and make sure you can connect (you should now be connecting to it on the SSL port, 8531).

Okay, now onto the work for the WSUS code signing certificate.

On a management server, open an MMC window and load the Certificate Authority snap-in. Connect to your issuing CA and expand the certificate authority so that you can select Certificate Templates.

Issuing Certificate Authority

Right click on Certificate Templates and click Manage. This will open the Certificate Templates Console. Highlight the Code Signing template and right click and select Duplicate Template.

Code Signing Template

This will allow you to modify the properties of the new Code Signing template that we are creating. Go to the General tab and give it a name; something like WSUS Code Signing or a similarly descriptive name will do nicely. You should also change the validity period from the default of 1 year to something a little more reasonable, like 3 years. You may wish to keep the validity period short, but just bear in mind that the shorter it is, the more often you will need to generate a new one. Remember that all clients must trust the new certificate before the old one expires!

WSUS Code Signing Template

Head over to the Request Handling tab and tick Allow private key to be exported. We need this so that we can import this certificate into WSUS a bit later. Go to the Subject Name tab and select Supply in the request (rather than the default to build from Active Directory information). Finally, go to the Security tab and make sure the correct user(s) have Read and Enrol permissions. This will depend on how your environment is set up. If you have a WSUS Administrators group, or a SCCM Administrators group, or even just a group for your team, you should add this group here and assign it Read and Enrol permissions. Alternatively, you can add individual accounts, such as your own, and assign these permissions. Whatever the case, if you are responsible for this piece of work, make sure you have permissions to Read and Enrol certificates from this template!

That’s all the changes we need to make, so click OK and close the Certificate Templates Console. Back in the Certificate Authority MMC, right click on Certificate Templates again and select New > Certificate Template to Issue. Find the WSUS Code Signing template among the list, select it and click OK. This template will now appear among your list of available certificate templates!

WSUS Code Signing Template Available

Next up is enrolling a code signing certificate for WSUS using this template. You can do this from any workstation connected to your domain. Open MMC and load the Certificates snap-in. Select My user account and click Finish. Expand Certificates – Current user and right click on Personal and select All Tasks > Request New Certificate. Click Next, and Next again to see the list of certificates that are available from Active Directory Certificate Services. You should see the WSUS Code Signing certificate template amongst the list, along with a message informing you that more information is required.

Certificate Enrollment

Tick the WSUS Code Signing template and then click on the More information is required link. Change the Subject name from Full DN to Common name and give it a value that describes what this certificate is being used for. Something similar to the name of the template, like WSUS Code Signing Certificate. Click Add to add this common name to the certificate. Although not mandatory, you can also go to the General tab and give the certificate a Friendly name and description (these are what will appear when you view this certificate in the Certificates snap-in in MMC). I went ahead and used the same value as I used for the common name here.

Certificate Properties

That’s all that needs to be configured here, so click OK to close the Certificate Properties window. Click Enroll, and then click Finish. Now expand Personal and click on Certificates, and you should see the newly enrolled certificate on the right, with the friendly name you set (if you did).

Now that the certificate has been enrolled, we need to export it so that we can use it in WSUS and deploy it out to workstations. Right click on the certificate and select All Tasks > Export. Click Next, and select Yes, export the private key. Click Next again, and Next again, and give the exported certificate a password. Make sure this password is strong! You do not want bad guys to have the ability to sign code using a certificate that all of your workstations will trust. Click Next again and give this certificate a name such as WSUSCodeSigningCertificate.pfx. Click Next again and Finish to complete the export.

If you want, you can delete this certificate from your personal certificate store. It no longer needs to be there now that you have exported it.

Next we need to import this certificate into WSUS so that it can be used to sign the third-party update that Ivanti provides.

Switch over to the management server where you have access to the SCCM console and installed Ivanti Patch for SCCM in Part 1 of this guide. Navigate to Software Library > Software Updates and click on Ivanti Patch. The Settings window should automatically appear once again – if it does not, simply click Settings in the ribbon. Go to the WSUS Server tab and enter the hostname of your WSUS server (in my case this is the same as my WSUS server) and the port number it is available on (this is likely 8531 if you are configured for WSUS over SSL, which you have to be). Click Test Connection to ensure the details you entered are correct.  Hopefully you will get a message informing you the connection to your WSUS server was successful. Click OK to accept the message.

Test SSL WSUS Server Connection

Under WSUS signing certificate, click Import. Select the certificate you exported earlier and enter the password you assigned it and click OK. The certificate will be imported into WSUS and you will get a message informing you of the next steps you need to take.

Actions you must take

So, here’s what we need to do next:

  1. Review the certificate that has been created. You can do this in a moment when you acknowledge the message.
  2. Add the certificate to the Trusted Root and Trusted Publishers stores on the WSUS server.
  3. Add the certificate to the Trusted Publishers store on every workstation you want to install third-party updates.

Okay let’s get on with these tasks. The first, to review the certificate, can be done immediately after you click OK. The certificate details will be displayed in the Current certificate section, and you can click View certificate to bring up the full details for this certificate. It will be valid for 3 years if you took my advice earlier, or whatever you set the validity period to. Remember to set a reminder in your calendar to generate a new certificate nearer the time this one will expire, with enough time to deploy it out to all of your clients!

To do the second action, click Export under WSUS signing certificate and save the certificate somewhere, giving it a name such as WSUSCodeSigningCertificate.cer (this is different from WSUSCodeSigningCertificate.pfx as it does not contain the private key). Next, log on to your WSUS server and open MMC and load the Certificates snap-in. Select Computer account, click next and then Finish. Expand Certificates (Local Computer) and right click on Trusted Root Certification Authorities and select All Tasks > Import. Click Next and enter the path to WSUSCodeSigningCertificate.cer. Click Next again and ensure that Place all certificates in the following store is selected, with Trusted Root Certification Authorities being the selected store. Click Next and then Finish and then click OK to close the success message. Expand Trusted Root Certification Authorities > Certificates and check to see your WSUS code signing certificate is listed.

Trusted Root Certification Authorities

You need to repeat these steps to also import the certificate into the Trusted Publishers store.

Finally, this same certificate must be added to the Trusted Publishers store of every client you want to install third-party updates on. The simplest way to do this is to deploy it with Group Policy. Open the Group Policy Editor and select the most appropriate GPO to add this too or create a new one. It must apply to machine objects and must be high enough in your Active Directory OU hierarchy to apply to every device you want installing these updates. In the Group Policy Editor window, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies and select Trusted Publishers. Right click on Trusted Publishers and select Import. Click Next and enter the path to WSUSCodeSigningCertificate.cer. Click Next again and ensure that Trusted Publishers is the selected store. Click Next and then Finish and click OK to the success message. You should see your WSUS code signing certificate listed on the right.

Deploy certificate to Trusted Publishers

Close the Group Policy Editor. Test that this is working by finding a client and updating Group Policy on it. Open the Certificates MMC add-in and check in Trusted Publishers to see if it’s been deployed to it.

Code signing using an Ivanti-generated self-signed certificate

If you do not have an internal PKI up and running, Ivanti offers you a very simple way to generate a self-signed certificate, which it will import into WSUS for you. Once that is done, you must distribute the certificate to every workstation you want to install third-party updates.

Open the SCCM console on the server that you installed Ivanti on in Part 1 of this guide and navigate to Software Library > Software Updates and click on Ivanti Patch. The Settings window should automatically appear once again – if it does not, simply click Settings in the ribbon. Go to the WSUS Server tab and enter the hostname of your WSUS server (in my case this is the same as my WSUS server) and the port number it is available on. Click Test Connection to ensure the details you entered are correct.  Hopefully you will get a message informing you the connection to your WSUS server was successful. Click OK to accept the message.

Test WSUS Server Connection

Under WSUS signing certificate, click Create a self-signed certificate, and read the message that instructs you on the actions you must take next. They are:

  1. Review the certificate that has been created. You can do this in a moment when you acknowledge the message.
  2. Add the certificate to the Trusted Root and Trusted Publishers stores on the WSUS server.
  3. Add the certificate to the Trusted Publishers store on every workstation you want to install third-party updates.

Actions you must take

Okay let’s get on with these tasks. The first, to review the certificate, can be done immediately after you click OK. The certificate details will be displayed in the Current certificate section, and you can click View certificate to bring up the full details for this certificate. Note that it has a 5 year life and will have to be renewed before that expiration date. If this certificate expires before you have renewed it and deployed the updated certificate, clients will no longer install the third-party updates.

To do the second action, click Export under WSUS signing certificate and save the certificate somewhere, giving it a descriptive name such as WSUSCodeSigningCertificate.cer. Next, log on to your WSUS server and open MMC and load the Certificates snap-in. Select Computer account, click next and then Finish. Expand Certificates (Local Computer) and right click on Trusted Root Certification Authorities and select All Tasks > Import. Click Next and enter the path to WSUSCodeSigningCertificate.cer. Click Next again and ensure that Place all certificates in the follow store is selected, with Trusted Root Certification Authorities being the selected store. Click Next and then Finish and then click OK to close the success message. Expand Trusted Root Certification Authorities > Certificates and check to see that WSUS Publishers Self-signed is listed.

Trusted Root Certification Authorities

You need to repeat these steps to also import the certificate into the Trusted Publishers store.

Finally, this same certificate must be added to the Trusted Publishers store of every client you want to install third-party updates on. The simplest way to do this is to deploy it with Group Policy. Open the Group Policy Editor and select the most appropriate GPO to add this too or create a new one. It must apply to machine objects and must be high enough in your Active Directory OU hierarchy to apply to every device you want installing these updates. In the Group Policy Editor window, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies and select Trusted Publishers. Right click on Trusted Publishers and select Import. Click Next and enter the path to WSUSCodeSigningCertificate.cer. Click Next again and ensure that Trusted Publishers is the selected store. Click Next and then Finish and click OK to the success message. You should see the WSUS Publishers Self-signed listed on the right.

Deploy certificate to Trusted Publishers

Close the Group Policy Editor. Test that this is working by finding a client and updating Group Policy on it. Open the Certificates MMC add-in and check in Trusted Publishers to see if it’s been deployed to it.

Configurating Windows Update on clients to install updates not signed by Microsoft

By default, the Windows Update client will only install updates signed by Microsoft. To configure it to install updates signed by other Trusted Publishers you must configure a setting in GPO. Select the GPO you will use to deploy this setting and in the Group Policy Editor window, navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update and find the setting Allow signed updates from an intranet Microsoft update service location. Open it and set it to Enabled.

Phew! That was a lot of work… in Part 3 we will be configuring the rest of the settings for Ivanti Patch for SCCM.

 

Buy Me A Coffee

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s