Answer:
This section guides you through the connection properties and requirements of the connection and overall integration of the Software Vulnerability Manager with WSUS/SCCM for the creation and publishing of security updates and custom patches.
Connectivity
A connection to WSUS API is permanently saved after the first successful attempt.
Software Vulnerability Manager saves it with the local user profile’s cookie, and it will re-establish it automatically each time the user logs into the Software Vulnerability Manager user account that made the connection. Software Vulnerability Manager can save up to one connection to WSUS API per profile.
The last successfully connection remains saved and previous ones are ignored. The Software Vulnerability Manager Daemon will ensure that your Web UI connects to WSUS API as soon as a user is logged in to the account. The Daemon is installed and configured in advance.
HTTP Connection
The connection to WSUS API can either be on default port 80/8530 via HTTP, or it can be done using SSL, depending on your WSUS configuration. When using HTTP, it will usually work out-of-the-box as long as the logged-in user has all required permissions and the port and server name are specified correctly.
SSL Connection
Connecting to WSUS via SSL can be a little tricky. Here we list some good practices to remember when enabling SSL on the WSUS server, to be able to successfully establish a connection without any errors:
- Run the Internet Explorer as Administrator before performing a connection to WSUS API.
- Provide the same server name as it appears under Issued to the field of the SSL certificate. Usually, this would be the Fully Qualified Domain Name (FQDN) of the target server.
- Avoid connections to DNS Alias names. If you maintain DNS Alias name for the WSUS Server and your SSL certificate is named after the Alias name, re-issue the certificate and remove the DNS Alias pointer for the WSUS API server, or else you might encounter technical problems that are hard to diagnose.
- Configure SSL at the WSUS following best practices from Microsoft, or use this KB Support Article.
Digital Certificate Package Signing
Each package is signed with a code-signing digital certificate to be able to pass WSUS security checks for package data integrity and trust validity. The code-signing process is the last step in the Patch Creation process, and the last step before your patch is published to WSUS/ System Center Configuration Manager.
Code-Signing Certificate Requirements
For security reasons and best practices, we strongly suggest using your CA-issued code-signing certificate or purchasing one from a trusted CA vendor. SVM can help you issue and install the WSUS Self-Signed certificate which is good for testing purposes, but it is not perfectly secure for the production network. In all cases, the following certificate requirements must be met disregarding of what cert you will choose:
- The digital certificate must be issued with code-signing purpose PKCS#12 format.
- The certificate may have many purposes, and it will work as long as code-signing is one of them.
- The certificate must be issued as a .PFX copy that includes public and private keys.
- The Signature hash algorithm of this certificate must be minimum SHA256.
- The certificate can be a WSUS Self-signed, CA-issued, or from commercial public CA.
- The private-key certificate copy should be installed at certlm.msc > WSUS folder.
- The public key copy at Trusted Publishers and Trusted Root Certification Authorities.
WSUS Self-Signed Certificate
Default WSUS Self-Signed certificate can be issued by any Windows Server host with WSUS Server Role installed on it. This certificate is easy to set up and easy to use. Windows Server 2012 and above editions require registry change to successfully issue WSUS Self-Signed copy. Follow this Microsoft KB for more. The integration page of SVM lets users install the WSUS Code-Signing certificate with few clicks.
Password-protected certificates cannot be imported into WSUS via the Software Vulnerability Manager interface, as it does not support the import of password-protected certificates. SVM interface would allow you to import certificates which are not password-protected, only when WSUS is SSL-enabled.
Manual Certificate Import via MMC Snap-In
Type certlm.msc at Run and it will open MMC snap-in for the Local Machine certificates store where you can import your WSUS Self-Signed code-signing certificate, as follows:
- Private-key certificate copy (.PFX) must be imported at certlm.msc/WSUS folder.
- Public-key copy (X509) shall be imported at certlm.msc/Trusted Root Certification Authorities.
- Public-key copy (X509) shall be imported at certlm.msc/Trusted Publishers certificate stores.
Password-protected certificates can be imported through MMC snap-in, but this is not ideal practice since sometimes it may not work great in environments with too many user restrictions and system hardening.
Note: You should another method for such important tasks. Best practice to import any CA-issued code-signing certificates into WSUS is to use the Powershell import method provided in the next sections.
Chained CA-Issued Certificate Import
Chained certificates would usually be company CA-issued. In many cases where the CA ladder includes intermediate subordinate CA steps, the CA code-signing certificate will be shipped in three different copies, one of which containing the private key and the other 2 containing the only public certificate keys.
Private CA’s Chained Code-Signing Certificate that includes subordinate CA certificate and Root CA certificate chain links must be installed correctly to work as intended. The following installation requirements will help you facilitate the correct installation scenario:
- Private-key certificate copy (.PFX) must be imported at certlm.msc/WSUS folder.
- Public-key copy (X509) shall be imported at certlm.msc/Trusted Root Certification Authorities.
- Public-key copy (X509) shall be imported at certlm.msc/Trusted Publishers certificate stores.
Elevated Powershell Import of Password-Protected Certificates
Follow this KB article on importing your code-signing certificate to WSUS via Powershell.
Required Group Policy Object
The Group Policy Object takes the available at WSUS public-key code-signing certificate copies and transfers it to domain systems covered by the GPO. The Group Policy Object will configure settings that enable domain systems to install the third-party updates being deployed by WSUS/SCCM. Third-party updates are not installable by default unless Group Policy explicitly enables Windows Update to do so.
Create the GPO Manually
Instructions on how to create the Group Policy Object can be found if you follow this link.
Downstream WSUS Replication
Downstream WSUS that is configured in Replica mode will only require public certificate copy to handle updates published to the Upstream server. A Downstream Replica server does not perform any digital signing of packages. The publishing, signing, and approval of packages is done by the Upstream server. Package metadata and applied Approvals are synced by the Downstream server and advertised to clients that were approved to install the updates before the synchronization at the Upstream server.
The Configure Downstream Servers option will remain disabled as long as the interface is connected to another server. This configuration menu has the sole purpose of installing a public-copy of the code-signing certificate you have previously created to any Downstream server you connect to.
Note: It is a best practice to distribute the code-signing certificate to Downstream servers using a GPO.
