Sign in to follow this  
Followers 0
Joe

Client push fails with Authenticode Signature error



14 posts in this topic

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

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

Share this post


Link to post
Share on other sites

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?

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

Thank you. I had set up SCCM 2012 SP1 about 2 weeks ago. Deployment to 15 clients went fine. In the last week I tried to add to 2 more clients and could not get to install. Nothings worked (SUP, push and manual install from client). Never would have thought an expired Cert problem.

 

Even though the CU instructions said to install prior to SCCM SP1 installation, no problems when CU applied to existing install. Client deployment now works fine.

 

You might want to PIN this for a while until MS releases an automatic update.

Share this post


Link to post
Share on other sites

Well, KB2801987 is Microsoft solution from ConfigMgr perspective. When you want to solve it from a clients' perspective via WSUS/SUP/Offline servicing then you can use KB2756872.

 

On a side-node: It says the update should be installed prior to installing the ConfigMgr 2012 SP1 client. Logically, on a site server it should be applied after installing SP1, as the issue doesn't exist before installing SP1.

Share this post


Link to post
Share on other sites

Microsoft published new bits of SCCM 2012 SP1 addressing the problem. So it should not happen if you use this new files. For early installations with original bits we need to use the workarounds described before

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0