Friday, December 03, 2010 9:25 AM
We have been successfully signing a patch family of installers and patches for over a year to allow least-privilege user account (LUA) patching, but have encountered a problem after the certificate expired. Patching with the renewed certificate failed and investigation showed that the public key of the new certificate was different from the public key of the expired certificate. The rules of windows installer say that LUA patching works only when the certificate used to sign the MSI file is the same as the certificate that signs the patch (MSP) file.
After some research we generated a Certificate Signing Request from the expired certificate and were able to rekey a new Go Daddy certificate that has the same public and private keys as the old certificate. In fact the new certificate is identical to the old certificate in every way except: the expiry date is in the future (which is of course essential), the "valid from" dates differ (unavoidably), the thumbprint is different (which we'd expect as the valid from and to dates are different), the serial number is different (presumably this does not affect the identity of the certificate) and, apparently crucially, the new certificate is 514 bytes smaller than the expired certificate.
The public key, private key and subject (i.e. the identity) of the new and old certificates are identical and we think that Windows Installer should therefore be able to accept that the MSP file is signed with the same certificate as MSI file.
Unfortunately, Windows Installer produces the following error when the Patch is run as a non-admin user:
"Certificate of signed file 'C:\DOCUME~1\TestUser\LOCALS~1\Temp\12b4dc3e.msp' differs in size with the certificate authored in the package."
We do not understand why the size of the certificate is relevant. The identity and keys of the expired and new certificates are the same.
Please can someone let us know how to sign a Windows Installer Patch file (MSP file) with a new certificate once the certificate that signed the original MSI file has expired ?
Thursday, December 09, 2010 7:37 AM
Have you checked this document?
Thursday, December 09, 2010 9:35 PMI had a look at this, unfortunately it makes no mention of how to renew the certificate for a patch so doesn't really address the problem. Thanks for the suggestion though.
Tuesday, January 11, 2011 1:19 PM
We had to open a support call with Microsoft to resolve this because our users must be able to renew a certificate for patching while logged in as a non-admin.
Here is a summary of the outcome:
- It is imperative to create a new patch containing the new certificate but signed by the old certificate before the old certificate expires. Failure to comply with this requirement will result in the failure of LUA patching on Windows XP.
- If you get into the situation where the old certificate has expired and your patch does not contain the new certifiate, your options for preserving LUA patching while running patches as a non-admin are very limited, though there is a potential solution: turn the clock back on the build machine to a date prior to the expiry date of the certificate ! This fix should not work due to the use of a time stamp server, however our timestamp server happily accepted any time in the past that we gave it, revealing a large hole in its security. You'd think it would independently verify the time but happily for us it did not.
- Microsoft accepted that there is no adequate information on patch certificate renewal and asked us to submit a documentation request which we duly did. As it will take a while for the documentation to go through the MSDN\Technet approval process I have supplied the information below in the next 2 posts.
- How to renew a certificate for patching
- What to do if the certificate has already expired
- Marked As Answer by Alastair00 Tuesday, January 11, 2011 2:01 PM
Tuesday, January 11, 2011 1:45 PM
How to renew a certificate for patching
The following information applies to Windows XP and requires the use of Windows Installer 4.5. I believe that UAC Patching on Windows Vista is broken because Vista removes the cab file from the msi file and then verifies the signature. Of course removing the cab file effectively tampers with the msi file causing the signature verification to fail. I was told by Microsoft support that patch certificate renewal on Windows 7 always causes a UAC admin prompt activation and there is no way round this but have not verified this for myself.
Digital certificates used to sign installers and patches expire and have to be renewed periodically, usually annually. The renewal process to maintain LUA (Least Use Authority) patching has several steps that need to be followed carefully otherwise LUA patching will stop working.
The ability to renew a certificate without breaking LUA patching DEPENDS ABSOLUTELY on making the required changes while the about-to-expire certificate HAS NOT YET EXPIRED.
The rules of LUA patching on Windows XP state that LUA patching is supported when the original MSI and subsequent patches are signed "with the same digital certificate". It is not sufficient to renew the certificate with the same public key and subject (identity) because Windows Installer does not accept that the expired and renewed certificates are the same, even though they digitally represent the same identity.
To introduce a new certificate:
- Purchase a new certificate before the expiry date of the about-to-expire certificate to give sufficient time to build and test the installer and patch. It is not necessary for the renewed certificate to have the same public key as the about-to-expire certificate. It is also not necessary for the subject field to be the same, meaning that identity information can be changed.
- Use your private key and the spc file obtained during the certificate renewal process to create a pfx file using the following command
pvkimprt.exe -pfx [CertificateName].spc [PrivateKeyname].pvk
- BEFORE the about-to-expire certificate expires:
a. Create a new MSI file, editing the msiDigitalCertificate and msiPatchCertificate tables to contain both the old and new certificates, then sign the MSI file with the about-to-expire certificate. See the appendix below for details on this.
b. Create a patch from the newly created MSI file and sign it with the about-to-expire certificate.
This patch can be used when run as a non-administrator to enable subsequent patching with MSP files that have been signed with the new certificate. The "renew-certificate patch" can't be skipped: it must be applied in order for subsequent patches to work. Subsequent msi files and patches do not need to include the expired certificate.
It is advisable to test your patch renewal process to make sure you know how to make it work before using it in a production environment. Test certificates can be created using makecert.exe before buying the real thing. You'll need to configure the certificate as a code-signing certificate.
APPENDIXYour installer creation package's table editing facilities need to be used to add the old and new certificates to the msi file so that signing of the file is successful. Using Orca to edit the msi file after it has been signed will invalidate the signature. After editing, the msiDigitalCertificate and msiPatchCertificate tables should look as follows:
DigitalCertificate CertData Cert About-ToExpire Certificate Cert02 Renewed Certificate
PatchCertificate DigitalCertificate PatchCert Cert PatchCert02 Cert02
- Marked As Answer by Alastair00 Tuesday, January 11, 2011 2:01 PM
Tuesday, January 11, 2011 1:59 PM
What to do if the certificate has already expired
If the certificate used for LUA patching has already expired there are a few options although all but one was unworkable for us.
- Alter Windows Installer security policy using Group Policy. The following two links describe the changes that need to be made. In HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer create 2 REG_DWORD keys, AllowLockdownPatch and AllowLockdownBrowse, and set their values to 1. This will allow non-administrators to run signed and unsigned patches. Subseqent patches can be run by non-administrators even when AllowLockdownPatch and AllowLockdownBrowse permissions have been revoked. This option may not be viable if you have no control over your customers’ security policy.
- Run a patch that has been signed with the new certificate while logged in as an administrator. Both the MSI file and the Patch must be signed with the same certificate. This may not be a viable option if admin permissions for your users cannot be obtained.
- Start a new patch family. This option has the same downsides as option 2 due to the need for admin rights.
- On your build machine, turn the computer’s clock back to prior to the expiry date of the expired certificate. This option should not work due to the use of a time stamp server but we found that it did solve the problem for us. After you have turned the clock back simply follow the steps in the previous post - "How to renew a certificate for patching" - signing both the MSI and MSP file with the expired certificate. Once these steps have been completed you will be able to create subsequent patches with the renewed certifcate and LUA patching will work.
- Marked As Answer by Alastair00 Tuesday, January 11, 2011 1:59 PM
Thursday, January 20, 2011 5:36 PM
Thank you very much for sharing this important information!
Wednesday, March 16, 2011 10:12 PM
There is a 2nd piece to this puzzle that you haven't yet hit upon yet.
Let's say that you released a full product version, and it was signed with the old certificate. Let's say you pack the binaries into cab files, and the cab files are signed, and the certificates are entered into the MsiDigitalCertificate table using MsiCert.
Now let us say that you got a renewed signing certificate and you wish to issue a "patch 1" or whatever you call it. You can build an installer for patch 1 - that part is no problem. But let's say you build a msp file as well. As a part of the patching process, the transforms inside of the patch will update the MsiDigitalCertificate table to have the new public keys for all of the cabinet files.
Finally let us say that you need to install the patch somewhere, and that one of the files on disk is damaged in some way or another. The patch installer only knows how to go from p0->p1, so it looks for the original cabinet file, and it finds it, but it was signed with the old signing certificate. And the msi file has the new signing certificate in the MsiDigitalCertificates table. MSI will choke on this and call it an error as the digital certificates don't match.
Thursday, November 17, 2011 10:25 AM
You are quite right, I've not run into that one and hope not to. I believe that our packaging application just signs the entire MSI file, not the individual cab files so we may be ok, but I'll certainly check and bear this in mind.