WSUS and Secunia CSI – Deployment Hurdles

After many years of saying that we should do it, we have purchased a third-party patch management solution.   The good folks at Secunia cut us a great deal, and we are not in the process of deploying Secunia CSI, which will be integrated with our existing WSUS (Windows Server Update Service) instance.  Here are some notes on the installation process:

WSUS SSL Configuration:

Secunia CSI uses the “System Center Update Publisher” (SCUP) API to publish third-party update packages into WSUS.  SCUP requires that SSL be implemented in WSUS.  Unfortunately, we had not done that yet, so there was some work to be done before we could even connect the CSI console to our WSUS server.

  1. Group Policy for Windows Update needed to be updated point clients to the HTTPS version of our WSUS host.
  2. The WSUS host had to be reconfigured to require SSL for the “ApiRemoting30″, “ClientWebService”, “DssAuthWebService”, “ServerSyncWebService”, and “SimpleAuthWebService” IIS virtual directories.  Also, WSUSUtil needs to be run to signal the update service to use SSL, as documented here:
    http://technet.microsoft.com/en-us/library/bb633246.aspx
  3. After making these changes, we found that the WSUS management console and Secunia WSUS integration utilities were failing to connect to WSUS (fontunately, Windows Update clients were not having this problem).  The management utilities were reporting “access denied” messages, which apparently were related to authentication failures.  This fix for this was not obvious, not did we find it documented anywhere.  Since our WSUS server is using an externally-refereneable “Internet” DNS name, we found that we also needed to set an SPN for the service that was running WSUS (in this case, the Network Service).  The command follows:
    setspn.exe -A http/[wsusDnsName] [wsusHostName]
    (where wsusDnsName is the DNS name on the WSUS server SSL certificate, and wsusHostName is the short computer name of the WSUS server Active Directory account.  You can verify that the SPN was added successfully using “setspn -L [wsusHostName]

Secunia CSI Signing Certificate Configuration:

Microsoft’s SCUP API requires that a code signing certificate is present in WSUS for the signing of packages imported into WSUS.  The Secunia CSI console will create a self-signed certificate for this purpose, but the cert will have a non-configurable 512-bit key length, and this cert will have to be pushed to the “Trusted Publishers” store of every WSUS client.  I prefer to use our AD CA Servers to generate a Code Signing cert.  This scenario is supported by Secunia, but it is not well documented.  Here is what we needed to do… it was not fun:

  1. On our CA server, create a new Certificate Template by cloning the “Computer” template, and making the following selections:
    1. Select “Server 2003″ as the compatibility level for the template.  “Server 2008″ templates apparently are not compatible with the SCUP API (or so I have read, and I see no reason to take chances).
    2. Set the minimum key size to “2048″ or longer.
    3. Set “Subject Name” to “Supply in the request”.  Corresponsingly, you should set “Issuance Requirements” to “CA certificate manager approval”.  Under “Extensions”, select “Application Policies”, and add “Code Signing”.  Remove all other policies.
    4. Under “Security”, add the computer account of the WSUS server, with Read and Enroll rights.
    5. Configure the CA to issue certs from this new template.
  2. Use the Certificates MMC on the WSUS server to request a code signing cert for the local computer account.  Failing this, you can assign rights to the template to a user account, then use the CA web interface to request a certificate.  You then can transfer the cert to the local computer account cert store.
  3. The CSI certificate import tool is pretty fussy about the certificate format, and the requirements of the tool are not documented.  We found the following requiments, once met, allowed for successful signing of packages:
    1. The certificate needs to be exported to a “pfx” file (PKCS #12 format) before import via CSI
    2. The PFX file must contain only the signing cert, and no other certificates in the signing cert chain.
    3. The PFX file must not be passphrase protected.

    So what are we to do? The certificate management GUI on windows does not allow the export of PFX files with no passphrase! The solution is found in “CertUtil.exe”:

    1. Use “certutil -store” to list the certs in the system account personal certificates store. Identify the serial number of the code signing certificate.
    2. Use “certutil -exportpfx My [CertSerialNumber] [exportFileName] NoChain,NoRoot”
  4. Now import the PFX file  that you just created using the CSI Console.  It should work, unless I have missed something else important.

CSI Console Configuration on Server 2008:

Server 2008 / 2008 R2 security settings will cause some problems for the CSI console, unless you make the following configuration changes, as documented in the CSI FAQ, here:
http://secunia.com/vulnerability_scanning/corporate/faq40/#Technical-General11
and here:
http://secunia.com/vulnerability_scanning/corporate/faq40/#Technical-Miscellaneous14

To summarize:

  1. Add https://csi.secunia.com to your “Trusted Sites” intenet security zones (in the Internet Settings control panel).
  2. In Internet Options → Advanced → Scroll to Security → Uncheck ‘Do not save encrypted pages to disk.

Comments are closed.