[Solved] Load certificate without entering a password

Topics: Misc.
Jun 26, 2013 at 5:37 AM
Hi all,

is there a way to load an existing code signing certificate which is not password protected?

As long as no password is entered, the "Load a certificate" button is disabled. Is there any other change to manually configure WSUS package publisher to use such a certificate - e.g. by editing the "options.xml"?
Editor
Jun 26, 2013 at 8:32 AM
As you need a certificate together with it's private key, there is no way to import such into Windows other than importing an certficate as pfx-file. And a pfx file always has a Password. If you don't have a pfx, you can convert such certificates using openssl.

HTH
Norbert
Jun 26, 2013 at 9:13 AM
Hi Norbert,

I'm trying to import a pfx file and it is not password secured, because our outsources did not specify any password when generating the pfx file.

I'm using the same .pfx file for WSUS integration of Secunia to publish updates that way. And this works without any issues. The WSUS package publisher simply does not allow me to load a certificate without specifying a password.

Since publishing itself seems to work, but the published update always shows the status "not applicable" I thought it might have to do with the missing specification of the certificate to be used. But as long as publishing works, package publisher seems to use the already installed correct certificate.

Do you have any other idea what might be the reason for the clients reporting "Not applicable", even if I remove all the installation and already installed checks or specify only e.g. checking the processor type?

I'm not able to see any reason for this in the clients WindowsUpdate.Log. Furthermore revising the published package also does not end up being synced to the downstream WSUS server - based on the sync log.

Any idea what might be wrong? Is it due to WSUS package publisher does not know which certificate to use and I'm not able to load it due to missing password? If so, is there a way to manually specify the certificate inside the "options.xml" or not?

Any suggestions are welcome.

Thanks
Editor
Jun 26, 2013 at 12:56 PM
Try importing it manually with the mmc. If this succeeds try exporting it again with private key and specify a password.
If you already have a correct installed certificate it's like you said. WPP just works. I do not have an idea what the error message means. Can you post a screenshot please?

Regards
Norbert
Jun 26, 2013 at 2:06 PM
I've turned on tracing on the WSUS client and going through the windowsupdate.log, checking for the published package, I can see that it is always identified as being "Not Applicable".

I'm not quite sure whether this is related to the certificate. It sounds more like a publishing issue itself, since neither for the check whether the package is already installed or whether it is allowed to be installed, any additionally configured checks (like file exists or file version or processor architecture or any other one I tried) are listed inside the windowsupdate.log - which means they are not executed.

But such checks are listed and verified for some MS Updates. Hence this looks like WSUS package publisher is somehow able to publish the package, but not the configured checks to identify whether an installation is allowed or not.

Could this be certificate related - it does not sound to me like this.

Revising the published package I can modify all the configured settings, but they are simply ignored (not executed based on windowsupdate trace output) when the WSUS client checks the package for installation.

Do you have any other idea what could be the reason for this behavior?
Coordinator
Jun 26, 2013 at 7:13 PM
Edited Jun 26, 2013 at 7:15 PM
Hi JackT2,
First, you shouldn't use non-password protected pfx file. Did you ever writes your credit card code on a paper with your card? ;-)
is there a way to load an existing code signing certificate which is not password protected?
No, WPP is not design to allow that, because I never imagine that someone can have to use such pfx file.
the published update always shows the status "not applicable" I thought it might have to do with the missing specification of the certificate to be used
No, the certificate is used by the Wsus server to sign the package, and by the client to verify the integrity of the package. But the client don't have to use the certificate to evaluate Isinstalled and IsInstallable rules.
But as long as publishing works, package publisher seems to use the already installed correct certificate.
That's right, Wsus has a valid certificate and use it, otherwise Wsus would generate an error when signing the package and the publication would fail.
Do you have any other idea what might be the reason for the clients reporting "Not applicable"
If clients report "Not Applicable", that mean :
  • The package is successfully published in Wsus.
  • Clients 'see' the package.
  • Clients are able to download the metedata of the package.
  • Clients are able to evaluate rules.
  • Clients are able to report there status to the server.
What type of file do you publish ? EXE, MSI, MSP ?
Is it due to WSUS package publisher does not know which certificate
No, in any case. WPP doesn't use the certificate. Only the Wsus server use it to sign the package.
is there a way to manually specify the certificate inside the "options.xml"
No, Options.xml doesn't store any informations on the certificate. The only thing that WPP do with the certificate is to tell to the Wsus server : 'Hey this is the certificate you have to use now'. And this is said only when you import the certificate.
Hence this looks like WSUS package publisher is somehow able to publish the package, but not the configured checks to identify whether an installation is allowed or not.
If when you revise an update, you can see the Isinstalled and Isinstallable rules you have set, so rules are correctly publish with the update. When you revise an update, WPP ask Wsus server for the MetaData corresponding to this update and show it to you.
  • Does this happen with one published update or every updates ?
  • Does all clients reports 'Not Applicable' ?
  • What is the type of the file you have published? .EXE, .MSI, .MSP ?
On one client, try to :
  • Stop the wuauclt service.
  • Stop Bits service.
  • Delete folder c:\Windows\SoftwareDistribution.
  • Start the WuauClt service.
  • Start the Bits service.
Marked as answer by DCourtel on 10/5/2013 at 5:33 AM
Coordinator
Jun 26, 2013 at 7:22 PM
You can turn on 'Extended Logging' from the WuAgent. See the bottom of this article :

http://support.microsoft.com/kb/902093/en-us

Do not forget to turn back off when finished !
Jun 27, 2013 at 11:03 AM
HI DCourtel,

the .pfx file does not have a password since it has been issued by our own CA. Please don't ask me why our data center outsourcer issued it without specifiying a password, but due to the fact that it is only published to company owned computers and its only purpose is the code signing for WSUS, this is ok for me.

I've turned on extended logging already during my tests yesterday noon. Based on this I noticed that the package is always identified as "Not applicable" and all the rules for "IsInstalled" and "IsInstallable" are not recorded in the log at all. For other packages, where such rules are configured, I can see such e.g. FileVersion, FileExist or Reg.Key checks in the log. But all these other packages have either been published by MS or by using Secunia.

I'm trying to install an .msp file and I've tried to publish this package several times, using some different rules and also with and without checking "Delete Rules at Package Level". Does "Delete Rules at Package Level" remove rules included inside the .MSP / .MSI file - or what else is the intention of it?

BTW - by manually executing the .MSP file I found the reason why it did not work. It was due to different GUIDs of the installed program and the one configured inside the .MSP to proceed with the update. Due to lack of a tool for reconfiguring the included .MST files I reinstalled the test computer with a suitable product to fit the update .msp package.

It looks like in the windowsupdate.log you'll find only entries for the additional configured rules, as long as the .msp package itself (and the contained .mst) files itself are valid and identified as installable. As soon as this prerequisites are met, additional rules are executed and logged.

Can you confirm that this is the usual behavior?