Client push fails with Authenticode Signature error

[Joe]

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?

[Simo]

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

[csimmons]

I have the same issue with SCCM 2012 SP1.

 

As a workaround before installing the SCCM 2012 SP1 client I'm installing the Microsoft Policy Platform (manually / using SCCM 2007 / using PSEXEC / etc.)

[Simo]

Unsurprisingly, cheating on the date also works, though is somewhat less practical

[narcoticmind]

Really pain in the ass actually..

 

I'm trying to do a build which worked fine yesterday, today it just stops and the reason is the same as yours...

 

Any idea how Microsoft is going to fix this?

[Simo]

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...

[narcoticmind]

Product team has been informed about the problem:

 

http://social.technet.microsoft.com/Forums/en-US/configmanagerdeployment/thread/a73233ab-0f9e-4304-ae2f-1a8aa92619b6

 

I would imagine that they'll release a fix pretty fast, 'cause this is a major issue.

[desek]

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.

 

 

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..

[Joe]

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?

[ToddMiller]

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/