Jump to content


Joe

Client push fails with Authenticode Signature error

Recommended Posts

Greetings:

 

I'm rolling out a new SCCM 2012 environment. I have 81 clients that I'm trying to bring into my environment from an existing 2007 environment. I configured discovery so they were identified by configuration manager, and then pushed the client to all of them. About 20% of the machines are failing to install the client, and they're all getting the same error:

 

c:\windows\ccmsetup\logs\ccmsetup.log:

Couldn't verify 'C:\Windows\ccmsetup\MicrosoftPolicyPlatformSetup.msi' authenticode signature. Return code 0x800b0101

 

It appears that the installation isn't liking the MicorsoftPolicyPlatformSetup.msi authenticode signature, and I'm not quite sure what to do about it.

 

Since the majority of my clients installed without problems, I'm pretty sure the problem isn't with the source files. To make sure something wasn't getting corrupt data copied over, I did a file compare (fc <file1> <file2>) from a command prompt. The files are identical.

 

I thought maybe an error message might be getting hidden during the install, so I decided to run the microsoftPolicyPlatformSetup.msi manually and see what happened. No errors were generated. However, after installing this manually, I was able to push the client successfully from the console.

 

 

 

Any ideas?

Share this post


Link to post
Share on other sites

Howdy,

 

By any chance are you running SCCM 2012 SP1? Either way - have a look at the expiry date of the code-signing certificate on the MSI, I'd guess it expires today... I suspect any clients you try to create now will fail.

 

I've got a case logged with Microsoft about this issue as well.

 

Cheers,

Simo

Share this post


Link to post
Share on other sites

My case hasn't really gone anywhere yet - we've been back and forward with logs... It's not going to be easy for many people to work around (though as noted above, there are some ways to get past it).

 

It will be interesting to see whether they'll hang fire on more widespread availability of SCCM SP1 - because unless the problem occurs only with some pre-condition, it has the potential to make SCCM SP1 a fairly messy release.

 

Guess we'll have to wait and see...

Share this post


Link to post
Share on other sites

As Simo said it works by changing the date.

 

I solved this on my OSD TSes by changing dates between "Setup Windows and ConfigMgr" step.

Since I'm running Native Mode I couldn't set the date too far back since it would break the ceritifcate verification.

 

changedate.jpg

 

Client Push installations are still not working. At the moment we're pushing clients through a script that changes the date before and after installing the client.

 

Hopefulle there will be a fix soon..

Share this post


Link to post
Share on other sites

By any chance are you running SCCM 2012 SP1? Either way - have a look at the expiry date of the code-signing certificate on the MSI, I'd guess it expires today... I suspect any clients you try to create now will fail.

 

I am using SP1.

 

Since it's a known issue and Microsoft is working on a fix, I guess I can just manually install on these machines to get the client going.

 

It's odd, though -- shouldn't the expiration prevent (or at least generate a warning) the installation of the MSI manually?

Share this post


Link to post
Share on other sites

There are other MSIs in my client setup folder with even older expiration dates, I suppose those will be a problem as well. While the Microsoft PolicyPlatforSetup cert expied yesterday, the client.msi expires in March 2013 and the MSXML expired 10/4/2007!! and the windowsfirewallconfigurationprovider.msi expired in 10/2011. It seems like something new is not allowing expired authenticode certificates. Why does it make a different for one MSI and not the others?

 

Being currious, I started looking at other MSIs I use to install software. My Flash Installer MSI is signed by an Adobe certificate that expired in Dec 2012, but that seems to install just fine. Whats special about this one particular MSI where the others don't fail. Is something in the clientsetup routine telling it to strictly enforce signatures?

 

Edit: After some internet searching - it looks like the MSI may just be signed incorrectly. They would have had the option to sign the MSI for "eternity" if done correclty.

 

http://gunsh.com/blog/2011/02/02/authenticode-signature-becomes-invalid-after-certificate-expires/

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.