Nov 06, 2020
07:24 AM
1 Kudo
Video walk-through for SVM on-premises customers who need to check their Vulnerability Manager Tracking database has synchronized with Flexera.
Commands mentioned in the video:-
Connecting to the Database console
mysql -u root -p
Listing the Databases
show databases;
Selecting the "vuln_track" database
use vuln_track
The query
select max(vuln_create_date) from vuln;
... View more
Sep 23, 2020
06:33 AM
1 Kudo
The subject of PKI Certification is quite extensive and the cryptography behind it is the realms of mathematics and science and can seem like a mystical black art to most, but to make use of certification and understand how it applies and how to use it within your environments does not require an understanding of cryptography or a computer science degree, this article aims to provide some general understanding of the of where certificates apply to Software Vulnerability Manager.
So what is certification used for?
Certification is used to ensure a level of trust between one point and another and is used for encryption of data traffic between two points, you will be familiar with SSL/TLS and the lock in your browser when you access a trusted website. Most modern browsers will not let you access websites that are not secured with a valid certificate.
Certification is also used as a proof of trusted identity, most commercial software will be code signed so that your PC can guarantee the software has come from a trusted source, and also software such as hardware devices drivers, in Windows 10 these have to be signed or you cannot install them.
Certification Authorities
A certificate authority is the holder of the “root certificate” by which all certificates generated by the authority is based upon, and by which all certificates that have been issued can be verified against. It is also where you request and obtain a certificate. The certification authority also maintains the “Certificate Revocation List” which as it states is a list of certificates that have been revoked by the authority for whatever reason.
There are public certificate authorities that exist on the internet, and there are private certificate authorities that exist on a corporate enterprise network.
Public Certification Authority needs to be used when you want a certificate to secure a connection to a publicly accessible website. These authorities verify the identity of the certificates applicant (you or me, or the company) and issue a certificate that is publicly verifiable, which means that the third party accessing your website can check that the certificate is valid and has not been revoked. The verification process is automatically done by your browser before the website loads. Software developers will also request Code Signing Certificates from these public authorities for signing their installer packages that it intends to make available to the public.
A private Certification Authority usually exists within a corporate enterprise network, it is responsible for the issuance of certificates for various purposes, such as securing internal intranet sites, securing access to internal web-based devices, client authentication, and lots of other purposes where an encrypted secure connection is required between one to one and one to many scenarios, or where a trusted identity is required.
Within a corporate network it is quite common to find a certificate authority hierarchy, meaning there is a Root Certification Authority (Root CA), and Subordinate Certificate Authority (Intermediate) the subordinate certificate authority issues certificates on behalf of the Root Certification Authority. In Windows-based domain networks, the Root Authority is generally shutdown with the subordinate issuing all of the certificates.
If a Certificate Authority exists on your corporate network, copies of any root certificates and intermediate certificates are generally distributed to all the computers on the network by a group policy, the reason for distributing the root and intermediate certificates is so that computers on your network know to trust any certificates issued by the root or intermediate authority. These certificates will exist in the Trusted Root Authority & Intermediate Certificate Authority containers in the certificate store for the local computer account on all of the corporate machines.
What is the difference between a PKI Certificate and a Self Signed Certificate?
You will come across the term self-signed certificates within the documentation so to help you understand the main differences.
Self-Signed Certificates
Self Signed certificates are generated on the computer that you are intending to secure, there is no certification authority issuing the certificate, they cannot be renewed, they cannot be revoked, Self-signed certificates must be distributed to all the other computers Trusted Root Certification Authority stores in order for them to be trusted by any other computer or device. They are fine to use and where a Certificate Authority does not exist and is indeed required.
PKI Issued Certificates
These are issued by your enterprise Certificate Authority, they can be renewed when they expire, they can be revoked by your administrator if required, and provided the RootCA Certificate and any intermediate CA certificates have been distributed to devices are automatically trusted. So no need to separately distribute the certificates. The only caveat in Windows networks that if you have a Code Signing Certificate issued by your PKI Certificate Authority the public key certificate must be distributed to the client computers “Trusted Publishers” store for the local computer account.
So how does all this apply to Software Vulnerability Manager ?
In SVM we use certificates in 3 ways:-
SSL Certificate for the SVM Console (On-Premises SVM Server) to secure the browser connection between the SVM Server and the console operators computer
Code Signing Certificate, used for signing packages delivered to WSUS from SVM so the packages can be trusted by the client PC’s and are allowed to be installed.
Certificate Authority Root Certificate, so that the SVM Server can trust certificates on the local domain, required when configuring LDAPS
SSL Certificate for SVM Console (On-Prem Only)
To secure access to the SVM Web Console and your PC, you will need to acquire and install a Web Server SSL Certificate that has been issued by your internal certificate authority to the web address that you intend to use for your SVM Server, the web address (svmservername.domain.local) is applied to the certificates common name field in the certificate request. T he certificate will need to be supplied to you by your certificate administrator in PFX format (PKCS#12) which is a file that contains both the Private and Public Keys.
To install the certificate on your on-premises SVM Server please see our current product documentation
This document tells you how to import your PKF File into your Linux Server
https://docs.flexera.com/csionpremredhat/Content/helplibrary/Import_Your_Own_SSL_Certificate.htm#rhel_ssl_ldap_2379745888_1047666
This document covers how to configure SVM to use SSL
https://docs.flexera.com/csionpremredhat/Content/helplibrary/RHEL_7_2.htm#rhel_ssl_ldap_2379745888_1048375
Code Signing Certificates
As mentioned earlier in this article, Code Signing Certificates are used to sign software installation packages so that they can be trusted by the computers to which the software packages are to be installed.
When a patching package becomes available within the SVM console to fix and patch discovered software vulnerabilities these packages must be published to your local WSUS Server so that they become available within your System Centre Software Update Point, so they can be subsequently deployed to computers.
Part of the publishing process is to sign the packages using a code signing certificate before the package is delivered to the WSUS Content Store and appears in the WSUS Database.
I have covered creating an installing a Windows Certificate Authority Code Signing Certificate in another KB article, which gives you guidance on how to successfully create and install a Code Signing Certificate for your WSUS Server.
https://community.flexera.com/t5/Software-Vulnerability-Manager/Creating-Windows-CA-Code-Signing-Certificate-for-WSUS/ta-p/149698
Although the above article mainly covers creating the Code Signing certificate, it contains the information on how to successfully install the certificate even if this has been obtained from a non-Windows CA
Root Certificate for LDAPS
The SVM Console can be set up to verify logins using your Windows Active Directory or another type of LDAP server, as this is the exchange of login information between your AD and the SVM Server it is recommended that you configure LDAPS (LDAP Secure). For LDAPS to work you will need to copy your Root Certificate Authority Certificates and if applicable any Intermediate Certificate Authority Certificates to your on-premises SVM Server.
These need to be copied to the directory “/etc/pki/ca-trust/source/anchors” on your SVM Server, then you need to run the command “update-ca-trust” which will update the CA Trust bundle and this will allow the SVM server to trust the LDAPS server on your local network the SVM Server is querying for logon information.
... View more
Sep 21, 2020
07:30 AM
1 Kudo
Summary
This document reviews the functionality of Cloud Management Gateway and if it supports third-party patches published by vendors like Flexera Software Vulnerability Management.
A recent request by one of our Partners as to whether the scenario of using Software Vulnerability Manager to deploy patches and updates to remote machines via Microsoft’s Cloud Management Gateway product for Microsoft Endpoint Configuration Manager (SCCM).
An initial review of the Cloud Management Gateway documentation was undertaken to find out what exactly CMG was and what it did, this led to the opinion of “Yes” and that our SVM product can deploy updates and patches to remote client machines via CMG. But without actually testing it and proving the concept we were not in a position to say “Yes” for definite, but that we believe that it would and that we would test and prove it for ourselves.
Cloud Management Gateway
For those familiar with SCCM and how it works you will also be very familiar with Distribution Points and Management Points, well to put it plain and simple it is a Management Point and Distribution Point in the Microsoft Azure Cloud for deploying software, updates, and patches to remote machines that are part of your enterprise network but are not connected to the network directly or connected via VPN. This takes the headache, the risk, and the cost out of having to try and expose your Enterprises internal SCCM infrastructure to the internet.
Why do I need it?
The requirement for this has become greatly highlighted in the recent situation where employees are having to Work from their home, by deploying CMG Enterprise Administrators can still manage these remote machines, deploy software to them, deploy updates and patches, and also Compliance & Configuration settings without having to provide VPN’s or exposure the internal infrastructure as mentioned above.
What we did
In order to prove that CMG would work with Software Vulnerability Manager, we created a mini enterprise environment consisting of a DC, CA, SCCM/WSUS/SQL, and a selection of Windows 10 clients.
We also required a cloud subscription to Software Vulnerability Manager**, a Microsoft Azure Active Directory account which is free.
To implement CMG we needed to upgrade to Azure Active Directory P2 Premium so we are able to configure Device accounts with the Azure Active Directory (AAD) , this is termed as a Hybrid Azure AD Joined account, this means that your machines are both joined to your Windows Domain and to your Azure AD at the same time.
The purpose for this is to give your remote machines an identity in Azure that corresponds to the on-premises computer account, the reason for the auto-enrolment is so that domain-joined machines will do this automatically when you add them to your Windows domain.
We also need a subscription for Azure Services and that the subscription is enabled to purchase other cloud services, as part of the CMG deployment process is the creation of a resource group, a virtual machine which hosts the CMG Web Service, and storage (for Updates to be stored and to host the VM), the two services that need to be enabled within the Azure subscription are Microsoft.ClassicCompute & Microsoft.Storage. The services don’t need to be created manually the subscription just needs to have them enabled so that the services can be created in Azure during the CMG deployment process.
The use of an internal PKI Infrastructure is required for the setup, in our test environment we have a Root domain and our root Domain uses PKI and has a certification authority (CA) configured as ROOT CA, A certificate authority server has been created in our child domain and this has been configured as a subordinate (intermediate) certificate authority of the Root Domain this means we have a certificate chain to consider.
Part of the configuration process of the CMG requires the use of our Domain Enterprise PKI, as we need to issue a web server certificate which will be applied to the CMG Web Service that the remote clients will connect to and you will also need the Root certificates and the immediate certificates in the chain that apply to your environment, Client Authentication certificates will be required to be issued to the client machines on the domain, this is a requirement of SCCM anyway, so if you are already using SCCM this should already be done, the client machines should already have the Root Certificate and the Intermediaries already deployed to them as part of them being set up for Client Authentication certificates, I would always check to be sure.
We also needed an external public domain name to work with so that we could create some DNS Server entries for the cloud services. For our test domain, we purchased a new domain for this purpose the domain is “secuniacmg.co.uk” and we have configured the DNS Servers for this domain to be the Microsoft DNS Servers the reason we used MS DNS is mainly for ease as using Microsoft DNS means that all the domain configuration DNS entries that are needed for the Microsoft Services such as Enterprise Enrolment are created automatically as part of adding the public domain to Azure, and also we can manage the domain within the portal this also means will be only 1 entry that we need to create manually for the CMG Service, which will be a CNAME record that points to the Azure CMG Web Service URL (yourcmg.cloudapp.net) that is automatically created by the CMG service deployment to Azure.
In regard to what changes are required for the configuration for our Software Vulnerability Manager product to support CMG, well the answer to this is nothing, provided your SVM Solution is currently able to publish updates to WSUS/SCCM and is working, there are no changes that need to be made to the configuration of SVM.
** CMG can work with an on-premises SVM Server, but in order for the SVM Agent that is installed on the client machines to communicate scan results back to the on-premises SVM server a VPN would be required, or alternatively use the SCCM Inventory Import Function within Software Vulnerability Manager to collect client machine software inventories.
The Lab Environment
The Domain we have created in our mini enterprise environment, our test environment domain is a child domain of a root Enterprise Domain called “flexdev.com”, our child domain is “secunia.flexdev.com”
This domain consists of:-
svmsup-dc-01.secunia.flexdev.com
· Domain Controller
· DNS
· Global Catalog
svmsup-ca-01.secunia.flexdev.com
· CA Authority – secunia.flexdev.com
svmsup-sccm-01.secunia.flexdev.com
· SCCM Site Server
· WSUS Server
· Software Update Point
· Distribution Point
· Management Point etc.
svmsup-fs-01.secunia.flexdev.com
· To run Azure AD Connect
Microsoft Azure Tennant
For this lab test we also have created a tenancy in Microsoft Azure, with a subscription to Microsoft Azure AD P2 Premium.
Domain Name & DNS Records
If your domain already exists and is hosted on external DNS Servers, and not Microsoft DNS Servers you will need to configure all of the DNS records required for Enterprise Enrolment.
Please see this article: -
https://docs.microsoft.com/en-us/microsoft-365/admin/get-help-with-domains/create-dns-records-at-any-dns-hosting-provider?view=o365-worldwide
Once your domain DNS records are configured for Microsoft 365 services and that the domain has been set up correctly within Azure.
This article explains further the configuration to configure your domain name for Azure AD
https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domain#:~:text=Add%20your%20custom%20domain%20name%20to%20Azure%20AD,-After%20you%20create&text=Search%20for%20and%20select%20Azure,Select%20Add%20domain.
Once the domain is configured in Azure, the next stage is to create a synchronization between your on-premises enterprise Active Directory and Azure AD
Azure AD Connect
Azure AD Connect tool creates a regular synchronization of on-premises Active Directory Objects to the Azure AD, the first stage is to install the tool on a member server, in our lab environment a server has been created specifically for this purpose, do not install AD connect on a Domain Controller as you will not be able to amend the AD Connect configuration afterward which you will need to do later to configure Hybrid Domain joins.
The Microsoft article below explains further details for Azure AD Connect along with some “how to’s”, but for the first stage is getting the user's synced
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/whatis-azure-ad-connect
Once you have configured AD connect and it has done its first synchronization you will be able to see the synchronized users in the Azure Portal.
Azure AD Connect – Hybrid Domain Join
The next part is to get the machine accounts synchronized, where machine accounts are concerned they are not actually synchronized they are registered (enrolled) within Azure AD as Hybrid Joined. To configure this you will need to revisit the AD Connect configuration as per this article:
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-device-options
Once configured and figured and synced (which will take some time) your devices should appear in the Azure AD as below:-
To summarise, the Azure Active Directory and Device Hybrid Domain join must be configured correctly and in place before you configure CMG components within SCCM
PKI Pre-requisites.
All machines must have Client Authentication Certificates issued by their enterprise CA
All machines must have the Enterprise CA root certificate, and any intermediate certificates that may apply to your environment deployed to the relevant stores.
A Web Server certificate will need to be generated from the Enterprise CA which will be applied to the CMG Web Service.
https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/certificates-for-cloud-management-gateway
You can use a public certification authority for the CMG Web Service Server certificate, but in our test environment we have used our internal PKI
IMPORTANT NOTE: If you are using your internal PKI it is unlikely that your Certification Revocation Lists will be publicly available. During the setup of CMG there is a checkbox which is checked by default for Verify Certificate Revocation, this must be unticked.
Also during the CMG setup you will be asked for the Enterprise Root Certificate and any intermediate certificates that are applicable.
Azure Subscription
Within your Azure tenant, you will need to create a subscription, this article explains how to create a subscription
https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription
Once the subscription is live, you will need to enable two Azure Services within resource providers, the two services that are required are Microsoft.ClassicComputer & Microsoft.Storage
This article gives you some guidance on enabling these resources.
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-providers-and-types
IMPORTANT
For the CMG to deploy successfully, the Azure user account used to create the CMG Service within SCCM must be the same user account that is the owner of the subscription, this user also needs to be a Global Administrator within Azure.
You can add additional owners to the subscription to do this, this article explains how to make changes to the subscription administrator.
https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/add-change-subscription-administrator
Setup CMG
This is the main article from Microsoft for setting up Cloud Management Gateway, it does cover several of the points that I have mentioned in this document.
https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/setup-cloud-management-gateway
... View more
Aug 06, 2020
05:54 AM
1 Kudo
Hi Gerry
The easiest way for you to confirm the difference between SCCM Inventory import scans and using the agent, is to run the agent on an affected machine and compare.
Firstly make a note or export a report on the affected machine first from the SVM Console, then download the agent with Token to the affected machines desktop from the SVM Console and using a command prompt as an administrative user run the CSIA.EXE from the command prompt, using the following command csia.exe -c -v -v -v -d "c:\scanlog.log" This will perform a scan with verbose logging. The logging will show all of the software detections and their file paths.
You can then compare the scanlog against the report you produced earlier.
Regards
Simon Edwards Senior Technical Support Engineer SVM Support
... View more
Aug 03, 2020
10:11 AM
1 Kudo
HI Gerry
Thank you for your community posting.
Could I ask if you are using SCCM Inventory import? If you are using SCCM import SVM will report based on the last inventory scan for the machine which could still show a machine that has been offline for days as it will take the last inventory.
We would recommend deploying the agent as this gives a more accurate scan.
Regards
Simon Edwards Senior Technical Support Engineer SVM SUpport
... View more
Jul 25, 2020
05:33 AM
1 Kudo
HI Martin,
Thank you for posting in the customer community.
The CSI agent does not currently support Web Proxy Auto Discovery Protocol, you will have to deploy a new agent to the client machines with the proxy configured. The link below shows how you add the proxy during the creation of the Agent Deployment Package.
https://docs.flexera.com/csi/Content/helplibrary/Add_Proxy_Settings.htm#svm_cloud_edition_patching_4187474106_1036004
Regards
Simon Edwards Senior Technical Support Engineer SVM Support
... View more
Jun 26, 2020
09:08 AM
2 Kudos
Hi Fawad
Also in regard to your certificates on the SVM Server
The Root Certificate and an Intermediate Certificates need to be in *.crt format needs to be placed in this folder /etc/pki/ca-trust/source/anchors/
Once the certificates are copied into this folder, run the follow commands:-
update-ca-trust
update-ca-trust extract
This will update the Root Certificate Bundle.
Regards
Simon Edwards
Senior Technical Support Engineer
SVM Support
... View more
Jun 26, 2020
08:59 AM
2 Kudos
Hi Fawad
You first need to verify that you can access LDAP on 636 using the LDP tool on the Active Directory server Domain controller that you are attempting to query. To access the tool select Run from the Start menu and type "ldp" complete the server name using the full FQDN type in port 636 and Check the SSL Checkbox
Once you have clicked OK the tool will attempt to connect and if successful will look like this below:-
In order to query the Active Directory you will need to create a user account to use to create the BIND between the SVM Server and the AD, you can also test this using the tool to make sure it authenticates successfully.
In the LDP tool "Connection" menu select "BIND" and complete the tool with the user account you have created to use for the BIND then select the "bind with credentials" option in Windows environment it is best if you use the username@domain format as I have below:
Click on the "OK" button you should see an output similar to below confirming authentication.
So now we know we can connect to the AD using Port 636 SSL and we can successfully BIND the credentials.
The next part we need to find out is where do we collect a list of user accounts from, these may be in a specific OU (Organisation Unit) to find out what the location of this is open your active directory Users and Computers and look for the OU that contains your users accounts:-
In the left-hand pane select the OU which contains your users, right-click on the folder and select "Properties" and select the Attribute Editor, scroll down till you come to "distinguishedName" as below:-
Double Click on the "distinguishedName" attribute and you will get this as below:-
This is the path you will need to enter into the SVM LDAP configuration process.
The next parameter we need to find out is the what is the distinguishing attribute that defines each user, in the Windows LDAP environment we will use the "sAMAccountName" attribute as the UID for SVM, so enter in sAMAccountName in the SVM LDAP Configuration process.
Below is a screenshot of a user account showing the sAMAccountName parameter that this is the Username
Notes:
If you are unable to connect to the AD using the LDAP Tool on Port 636 it may be that you are not using a Windows CA Certification authority in the domain issuing Server Certificates to domain controllers, if you are not using Windows PKI in your environment you will have to either look at using Active Directory Lightweight Directory Services Role and configure this with SSL.
... View more
Jun 26, 2020
06:18 AM
3 Kudos
Hi Dennis
Please find a list of the URL's required below:-
http://crl.rootca1.amazontrust.com http://crl.sca1b.amazontrust.com http://crl.rootg2.amazontrust.com http://s.ss2.us
https://csi7.secunia.com https://agent.csi7.secunia.com https://dl.csi7.secunia.com https://sync.secunia.com
Regards
Simon
... View more
Jun 11, 2020
10:15 AM
1 Kudo
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.
[Reflection.Assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$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.
$config.Save()
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
... View more
About
Senior Technical Support Engineer
Cheshire, UK
Latest posts by SimonEdwards
Subject | Views | Posted |
---|---|---|
279 | Nov 06, 2020 07:24 AM | |
6268 | Sep 23, 2020 06:33 AM | |
2572 | Sep 21, 2020 07:30 AM | |
552 | Aug 06, 2020 05:54 AM | |
581 | Aug 03, 2020 10:11 AM | |
469 | Jul 25, 2020 05:33 AM | |
792 | Jun 26, 2020 09:08 AM | |
796 | Jun 26, 2020 08:59 AM | |
602 | Jun 26, 2020 06:18 AM | |
3371 | Jun 11, 2020 10:15 AM |
Activity Feed
- Posted Coffee Break Series #1 - Checking the Vulnerability Database is up to date on Software Vulnerability Manager Knowledge Base. Nov 06, 2020 07:24 AM
- Posted The usage of PKI Certification (Certificates) within the SVM configuration. on Software Vulnerability Manager Knowledge Base. Sep 23, 2020 06:33 AM
- Posted Software Vulnerability Manager & Cloud Management Gateway (CMG) on Software Vulnerability Manager Knowledge Base. Sep 21, 2020 07:30 AM
- Got a Kudo for Re: Anomalies with endpoint scans. Aug 10, 2020 12:17 PM
- Posted Re: Anomalies with endpoint scans on Software Vulnerability Management Forum. Aug 06, 2020 05:54 AM
- Got a Kudo for Re: Anomalies with endpoint scans. Aug 03, 2020 10:13 AM
- Posted Re: Anomalies with endpoint scans on Software Vulnerability Management Forum. Aug 03, 2020 10:11 AM
- Got a Kudo for Re: CSI-Agent and use of proxy via WPAD not possible?. Jul 27, 2020 10:40 AM
- Posted Re: CSI-Agent and use of proxy via WPAD not possible? on Software Vulnerability Management Forum. Jul 25, 2020 05:33 AM
- Got a Kudo for Re: Whitelisting wildcard addresses in firewall configuraiton. Jul 09, 2020 06:29 PM
- Got a Kudo for Re: SVM on-prem Server ldaps Configuration. Jul 03, 2020 05:45 AM
- Got a Kudo for Re: SVM on-prem Server ldaps Configuration. Jul 03, 2020 05:44 AM
- Got a Kudo for Re: SVM on-prem Server ldaps Configuration. Jun 26, 2020 10:23 AM
- Got a Kudo for Re: SVM on-prem Server ldaps Configuration. Jun 26, 2020 10:23 AM
- Kudoed Failed to publish package. Code: -2146233088 Publishing operation failed, too many locally published categories for arodziewicz. Jun 26, 2020 09:48 AM
- Tagged Re: SVM on-prem Server ldaps Configuration on Software Vulnerability Management Forum. Jun 26, 2020 09:10 AM
- Tagged Re: SVM on-prem Server ldaps Configuration on Software Vulnerability Management Forum. Jun 26, 2020 09:10 AM
- Tagged Re: SVM on-prem Server ldaps Configuration on Software Vulnerability Management Forum. Jun 26, 2020 09:10 AM
- Tagged Re: SVM on-prem Server ldaps Configuration on Software Vulnerability Management Forum. Jun 26, 2020 09:10 AM
- Posted Re: SVM on-prem Server ldaps Configuration on Software Vulnerability Management Forum. Jun 26, 2020 09:08 AM