Patching with renewed certificate fails

[Alastair]

Hi

We have been signing our product's msi and msp files for a year now so that non admin users can apply patches and this has worked well. However after renewing the expired digital certificate, patches fail with the error "The system administrator has set policies to prevent this installation" when run by a non admin user, though the patch works fine when run by an admin.

When run by a non admin user, the patch's log file has the following entries:
Machine policy value 'DisablePatch' is 0
Machine policy value 'AllowLockdownPatch' is 0
Machine policy value 'DisableMsi' is 0
Machine policy value 'AlwaysInstallElevated' is 0
User policy value 'AlwaysInstallElevated' is 0
Product {6DD3EAAF-0320-46E0-815D-386226C1465D} is admin assigned: LocalSystem owns the publish key.
Product {6DD3EAAF-0320-46E0-815D-386226C1465D} is managed.
Running product '{6DD3EAAF-0320-46E0-815D-386226C1465D}' with elevated privileges: Product is assigned.
MSI (c) (CC:44) [08:48:08:449]: Machine policy value 'DisableLUAPatching' is 0
MSI (c) (CC:44) [08:48:08:449]: Machine policy value 'DisableFlyWeightPatching' is 0
Validating digital signature of file 'C:\DOCUME~1\TestUser\LOCALS~1\Temp\1891e5d.msp'
Certificate of signed file 'C:\..\1891e5d.msp' differs in size with the certificate authored in the package. This installation is forbidden by system policy. Contact your system administrator.

We noticed that the public keys in the old and renewed certificates are different and also that the old and new certificates are indeed different sizes. I expected that since the certificate is valid and belongs to the same organisation that it would all "just work" but that seems to be a naive view! I also expected that the renewed certificate would have the same public and private keys but this expectation may be incorrect too.

Reading around the problem, one suggestion is to create a patch which has the sole purpose of adding a new certificate to the MsiDigitalCertificate table and a new entry to MsiPatchCertificate table that points to the new certificate. Unfortunately, this procedure will only work for non admin users if the certificate to be upgraded has not expired yet which is no longer the case for us, meaning that this option is a last resort for us.

We are also asking our Certificate supplier (Go Daddy) to renew the certificate with the same public key, though we are still waiting for a response on that.

I'd be grateful if you would respond to the following:-

• Should a renewed certificate for patching have the same public and private keys as the expired certificate ?
• What is the recommended procedure for managing the renewal of certificates for patching once a certificate has expired ?
• What is the best practice for renewal of certificates for patching ?

Thanks,
Alastair

[GabrielBarbu]

Hi Alastair,

The following MSDN page lists having a valid un-revoked digital certificate as a prerequisite for a successful UAC patching.
The following list item seems to be relevant to our case:

"The signer certificate used to verify the digital signature on the patch package is valid and has not been revoked."

Should a renewed certificate for patching have the same public and private keys as the expired certificate ?

Based on the MSDN's article, I believe so.

What is the recommended procedure for managing the renewal of certificates for patching once a certificate has expired ?

MSDN doesn't seem to have a recommended procedure for this situation, as far as I can tell.
The only solution I can find is to release a full automatic update instead of a patch. This will contain (be signed with) your new certificate. Of course, it will require
administrative privileges.

What is the best practice for renewal of certificates for patching ?

I couldn't find any suggestions on MSDN regarding this. However, MSDN does say:

"A patch can add new certificates to the MsiPatchCertificate table to evaluate patches sequenced after the current patch."

From what I understand, this enables you to take the following approach:
- once you know your certificate (let's call it certificate A) is about to expire, apply for a new certificate (certificate B)
- release a new patch signed with certificate A. This patch adds certificate B to the MsiPatchCertificate table.
- certificate A expires. Use certificate B for your packages from now on.

Best regards,
Gabriel

[Alastair]

Hi Gabriel,

Thank you for your reply, I wish it was better news !

Kind regards,
Alastair

[Alastair]

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 in the next 2 posts.
  1) How to renew a certificate for patching
  2) What to do if the certificate has already expired

Best Wishes,
Alastair

[Alastair]

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:
1. 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.
2. Use your private key and the spc file obtained during the certificate renewal process to create a pfx file using the following command

Code: Select all

pvkimprt.exe -pfx [CertificateName].spc [PrivateKeyname].pvk  

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

APPENDIX
Advanced Installer'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:

msiDigitalCertificate Table

Code: Select all

DigitalCertificate     CertData 
Cert                       About-ToExpire Certificate 
Cert02                   Renewed Certificate 

msiPatchCertificate Table

Code: Select all

PatchCertificate     DigitalCertificate 
PatchCert              Cert 
PatchCert02           Cert02

Best Wishes,
Alastair

[Alastair]

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.

Kind regards,
Alastair