Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Root Certificate install fails with code 26352 #4875

Closed
wixbot opened this issue Aug 27, 2015 · 16 comments
Closed

Root Certificate install fails with code 26352 #4875

wixbot opened this issue Aug 27, 2015 · 16 comments
Assignees
Milestone

Comments

@wixbot
Copy link

wixbot commented Aug 27, 2015

I have created a WIX installation MSI that installs certificates to machine store. It is supposed to install a root certificate, but the installation fails if the cert already exists in the store.

I'm using Wix 3.9 R2.

This seems to have been a long running issue.

It was raised back in 2008:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Certificate-install-to-local-machine-fails-with-code-26352-td1121050.html

and again in 2010:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-cannot-install-certificate-Error-26352-installing-certificate-td4864389.html

and other people have been having the problem more recently:
http://stackoverflow.com/questions/26932405/wix-installation-fails-to-install-certificate-to-root-certification-authorities

What (if anything) is the fix for this. In all those enormous threads, there doesn't seem to be an actual fix at all - it certainly isn't working in Wix 3.9? Some people seem to suggest that it was working with Wix 3.5? Do I need to revert back to that version to get this to work? Or was it never actually fixed at all?

Can anyone suggest a specific version of Wix which will not cause this issue, or any other workaround. This is causing a significant headache for my organisation at present - users are having to manually go in and delete the root cert before installing our product - not good...

Thanks in advance for any help...

Originally opened by jon34

@wixbot
Copy link
Author

wixbot commented Sep 1, 2015

Please provide a minimal example and a verbose log showing the error.

Area changed from installer to extensions
Release changed from v3.9 to v3.x

@wixbot
Copy link
Author

wixbot commented Sep 14, 2015

Relevant code from Product.wxs:

            <iis:Certificate Id="Certificate.RootCA"
               Name="Prod RootCA"
               Request="no"
              StoreLocation="localMachine"
              StoreName="root"
              Overwrite="yes"
              BinaryKey="Certificate1" />

Relevant section of verbose log file:

MSI (s) (A4:F8) [09:42:31:023]: Executing op: ActionStart(Name=RollbackAddMachineCertificate,,)
Action 09:42:31: RollbackAddMachineCertificate. 
MSI (s) (A4:F8) [09:42:31:025]: Executing op:               CustomActionSchedule(Action=RollbackAddMachineCertificate,ActionType=11521,Source=BinaryData,Target=**********,CustomActionData=**********)
MSI (s) (A4:F8) [09:42:31:046]: Executing op: ActionStart(Name=AddMachineCertificate,,) Action 09:42:31: AddMachineCertificate. 
MSI (s) (A4:F8) [09:42:31:047]: Executing op: CustomActionSchedule(Action=AddMachineCertificate,ActionType=11265,Source=BinaryData,Target=**********,CustomActionData=**********)
MSI (s) (A4:7C) [09:42:31:050]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI3603.tmp, Entrypoint: AddMachineCertificate
MSI (s) (A4:80) [09:42:31:050]: Generating random cookie.
MSI (s) (A4:80) [09:42:31:058]: Created Custom Action Server with PID 812 (0x32C).
MSI (s) (A4:CC) [09:42:31:206]: Running as a service.
MSI (s) (A4:CC) [09:42:31:217]: Hello, I'm your 32bit Elevated Non-remapped custom action server.
AddMachineCertificate:  Deleting certificate that begin with friendly name: Prod RootCA_wixCert_
AddMachineCertificate:  Adding certificate: Prod RootCA_wixCert_1
AddMachineCertificate:  Error 0x80070005: Failed to add certificate to the store.
MSI (s) (A4!A0) [09:42:31:298]: Note: 1: 2205 2:  3: Error 
MSI (s) (A4!A0) [09:42:31:298]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 26352 
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 26352. The arguments are: -2147024891, , 
MSI (s) (A4!A0) [09:42:32:744]: Note: 1: 2205 2:  3: Error 
MSI (s) (A4!A0) [09:42:32:744]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 
MSI (s) (A4!A0) [09:42:32:744]: Product: MyTest -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 26352. The arguments are: -2147024891, , 

AddMachineCertificate:  Error 0x80070005: Failed to install certificate.
AddMachineCertificate:  Error 0x80070005: Failed to install per-machine certificate.
CustomAction AddMachineCertificate returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 09:42:32: InstallFinalize. Return value 3.
MSI (s) (A4:F8) [09:42:32:762]: User policy value 'DisableRollback' is 0
MSI (s) (A4:F8) [09:42:32:762]: Machine policy value 'DisableRollback' is 0
MSI (s) (A4:F8) [09:42:32:772]: Executing op:           Header(Signature=1397708873,Version=500,Timestamp=1194216784,LangId=1033,Platform=0,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
MSI (s) (A4:F8) [09:42:32:772]: Executing op: DialogInfo(Type=0,Argument=1033)
MSI (s) (A4:F8) [09:42:32:772]: Executing op: DialogInfo(Type=1,Argument=MyTest)
MSI (s) (A4:F8) [09:42:32:772]: Executing op: RollbackInfo(,RollbackAction=Rollback,RollbackDescription=Rolling back action:,RollbackTemplate=[1],CleanupAction=RollbackCleanup,CleanupDescription=Removing backup files,CleanupTemplate=File: [1])
Action 09:42:32: Rollback. Rolling back action:
Rollback: AddMachineCertificate
MSI (s) (A4:F8) [09:42:32:775]: Executing op: ActionStart(Name=AddMachineCertificate,,)
MSI (s) (A4:F8) [09:42:32:776]: Executing op: ProductInfo(ProductKey={961D8F5A-603C-40E9-BEDD-91F6990C43F0},ProductName=MyTest,PackageName=MyTest-Release-x86_2.0_V497.msi,Language=1033,Version=33560127,Assignment=1,ObsoleteArg=0,ProductIcon=icon.ico,,PackageCode={537043EE-E5C7-4C6E-87E7-294CEB6BCC9B},,,InstanceType=0,LUASetting=0,RemoteURTInstalls=0,ProductDeploymentFlags=3)
Rollback: RollbackAddMachineCertificate
MSI (s) (A4:F8) [09:42:32:778]: Executing op: ActionStart(Name=RollbackAddMachineCertificate,,)
MSI (s) (A4:F8) [09:42:32:779]: Executing op:   CustomActionRollback(Action=RollbackAddMachineCertificate,ActionType=11521,Source=BinaryData,Target=**********,CustomActionData=**********)
MSI (s) (A4:24) [09:42:32:781]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI3CC7.tmp, Entrypoint: DeleteMachineCertificate
DeleteMachineCertificate:  Deleting certificate that begin with friendly name: Prod RootCA_wixCert_
Rollback: Copying new files

Originally posted by jon34

@wixbot
Copy link
Author

wixbot commented Sep 28, 2015

The same issue with 3.10
link text

Originally posted by alexey.larsky

@wixbot wixbot added this to the v3.x milestone Dec 20, 2015
@wahajali
Copy link

wahajali commented Nov 3, 2016

@wixbot any update on this? This is still reproducible with v3.9

@robmen
Copy link
Member

robmen commented Nov 3, 2016

The bug is open and waiting for someone to start working on a solution. Perhaps you would like to start doing so?

@briandrennan
Copy link

@robmen, who can I, or where should I, ask about the relevant area of WiX? I wouldn't mind giving this a go, if it's in C#. I unfortunately am not very comfortable in C++, but if it's in C#, I think this should be as simple as just checking to see if the certificate is in the store, and if so, moving on?

I'm happy to work on it if someone points me to the appropriate area in the source folder.

Thanks!

@robmen
Copy link
Member

robmen commented Nov 5, 2016

It'll need to be in C++. Too many problems using managed custom actions in platform custom actions. Take a look at: src\ext\ca\serverca\scasched\scacert.cpp and src\ext\ca\serverca\scaexec\scacertexec.cpp

@kirillkovalenko
Copy link

Is this bug expected to be fixed anytime soon?

@barnson
Copy link
Member

barnson commented May 10, 2017

The bug is open and waiting for someone to start working on a solution. Perhaps you would like to start doing so?

@HimanshuNandu
Copy link

is this resolved?

@robmen
Copy link
Member

robmen commented Nov 1, 2018

This issue is open and unassigned. That means it is waiting for someone to investigate the root problem, discuss possible solutions to that problem then implement the decided solution.

If you are interested in doing so yourself, our developer documentation provides a great checklist for getting started.

If you are not interested then you are waiting for someone else to become interested. If this issue has been open for a long time then there probably isn't much interest in this particular issue. In that case, you'll want to consider how to motivate others to fix it for you. This is a pretty good list of support options.

@JasonStephenson
Copy link

I have bumped into this issue and have extracted the failing code path out of dutil.lib. I can consistently reproduce this using a simple.exe (https://pastebin.com/b0RJZANN)

Steps to reproduce:

  1. Manually import a CA certificate into the Group Policy or Enterprise physical stores within Trusted Root Certification Authority virtual store.
  2. Run the aforementioned simple.exe and watch it fail.

The crux of this problem is that if a certificate already exists in these locations then the ::CertAddCertificateContextToStore(CERT_STORE_ADD_REPLACE_EXISTING) call fails with ACCESS_DENIED, even when ran as Administrator. But the call will not fail if executed with CERT_STORE_ADD_USE_EXISTING.

Should this be the case? I don't think so. Would it ever be fixed if raised as a MS issue? Unlikely.

Given the following facts:

  1. dutil.lib (and therefore simple.exe) imports to the Registry physical store of TRCA
  2. mmc.exe -> Certificates snapin will import into the Registry physical store by default
  3. mmc.exe -> Certificates snapin always uses CERT_STORE_ADD_USE_EXISTING
  • I have confirmed this by analysing the winapi calls that occur during certificate import for:
    ** A CA that was never present in the stores
    ** A CA that was present in the Registry (default) store
    ** A CA that was present in any other physical store

I believe it is safe to use CERT_STORE_ADD_USE_EXISTING instead of CERT_STORE_ADD_REPLACE_EXISTING in all cases. However, if one wanted to reduce risk the following (pseudo) could work:

If(::CertAddCertificateContextToStore(CERT_STORE_ADD_REPLACE_EXISTING) == ACCESS_DENIED)
   ::CertAddCertificateContextToStore(CERT_STORE_ADD_USE_EXISTING)

To this end I have spent most of the weekend and all of today trying to get WiX running with my own dutil.lib code. Sadly, to no avail.I have got as far as compiling (dutil.lib + wcautil.lib) --> iisca.dll --> iis.wixlib --> WixToolset.Iis.wixext.dll.

However, I'm at a loss on how to proceed further as if I attempt to reference WixToolset.Iis.wixext.dll from within my .wixproj I get:

candle.exe(0,0): error CNDL0307: Either 'Microsoft.Tools.WindowsInstallerXml.AssemblyDefaultWixExtensionAttribute' was not defined in the assembly or the type defined in extension.

Ideally if someone is able to provide guidance on how to proceed I may be able to put this issue to bed once and for all.

Failing that, if someone with a working build system could compile me a test WixIIsExtension.dll with my aforementioned change I could confirm whether my fix works.

Many thanks,
Jason Stephenson

@JasonStephenson
Copy link

So, an update. I've managed to figure out how to build the correct WixIIsExtension.dll using MSBuild and this repo.. I made my change, then referenced this dll in my project instead of the production dll.

To my surprise the issue was still present. What is more surprising is that even if I change the error log lines they appear unaltered in the MSI log.

My changes:

..\wix3\src\ext\ca\serverca\scaexec\scacertexec.cpp:278
MessageExitOnFailure(hr, msierrCERTFailedAdd, "JST0: Failed to add certificate to the store.");
..\wix3\src\ext\ca\serverca\scaexec\scacertexec.cpp:294
MessageExitOnFailure(hr, msierrCERTFailedAdd, "JST1: Failed to add certificate to the store.");
..\wix3\src\libs\dutil\certutil.cpp:286
ExitWithLastError(hr, "JST JST JST JST JST. Failed to add certificate to the store.");

And the log output still shows:

MSI (s) (08:7C) [20:36:56:099]: Hello, I'm your 32bit Elevated Non-remapped custom action server.
AddMachineCertificate:  Entering AddMachineCertificate in C:\Windows\Installer\MSI1B92.tmp, version 3.11.4516.0
AddMachineCertificate:  Deleting certificate that begin with friendly name: Mimecast Root CA_wixCert_
AddMachineCertificate:  Adding certificate: Mimecast Root CA_wixCert_1
AddMachineCertificate:  Error 0x80070005: Failed to add certificate to the store.

Anyone any idea's why this may be the case? @robmen ?

@rseanhall
Copy link
Contributor

Please move these questions to the wix-devs mailing list.

How is CertAddCertificateContextToStore telling whether the given certificate matches the existing one? In other words, are you sure that CERT_STORE_ADD_USE_EXISTING will always either end up with your certificate in the store or give an error?

The v3 build system sometimes has problems with incremental builds. You should clean and then build again.

Once again, please move this discussion to wix-devs.

@JasonStephenson
Copy link

JasonStephenson commented Mar 24, 2020

  1. I have emailed the list from my work address but it is "held until it can be approved". Sadly I'm operating under some time constraints and given that my email was pertinent to this bug, I thought I would continue the discussion here. Approve my email and I'll happily use the list.
  2. I don't know how CertAddCertificateContextToStore as I'm not a windows dev and have limited RE capability. I would assume by the certificates thumbprint (hash).
  3. Yes I am sure, my simple.exe example demonstrates this if you tweak it to use CERT_STORE_ADD_USE_EXISTING instead. A one line change.
    4.I don't think it is an incremental build problem as I have nuked my workspace and rebuilt it multiple times.

Given that:

  • I'm using Production Wix dlls + my own altered WixIIsExtension.dll
  • I'm seeing no changed to the log output

I can only conclude that it's not as simple as changing dutil.lib and compiling WixIIsExtension. The production dutil.lib must reside in some of the production dlls and it is that that is being called at runtime during install. I'll do some digging to confirm this.

@JasonStephenson
Copy link

Pull requests here and here

@barnson barnson modified the milestones: v3.x, v4.x Apr 1, 2020
@rseanhall rseanhall modified the milestones: v4.x, v3.14 May 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants