none
VSTO Unknown Publisher workaround? RRS feed

  • Question

  • Hi,

    I know this has been mentioned a few times before, but I'm having issues with signing our Excel Add-In with a Thawte code signing certificate.

    I understand this is an issue with VSTO not completing the certificate chain correctly, and as such when the ClickOnce installation is done on a client machine, we're regarded as an Unknown Publisher.

    I tried creating a Setup project to install the VSTO instead, but I'm still getting the same problems.
    From what I've read, getting a certificate from a vendor that doesn't use intermediate certificates would make this issue go away, but given that we only bought the certificate a few weeks ago that wouldn't be ideal!

    Also, I have seen suggestions to edit the registry on machines, or to install the intermediate certificates so that the installation would be trusted, but given that most of our users don't have admin rights on their machines, this isn't a good solution either.

    I was wondering if there are ANY other workarounds anybody knows for this problem, other than the ones I've mentioned?
    I'd really like to get this fixed without purchasing a new certificate!

    Thanks,

    Ian

    Thursday, January 3, 2013 5:28 PM

Answers

  • no, this custom action should be invoked as elevated, using TrustedInstaller process. From developer point of view, just create custom action that add inclusion list entry and do not modify anything, it should be invoked as elevated action.
    Friday, January 4, 2013 5:54 PM
  • Eventually we managed to get a working installer, but this did take a couple of extra steps.
    We couldn't use a ClickOnce deployment, had to create a setup and deployment project.
    In this project we added a Custom Action to install the intermediate certificates into the users personal store.
    We had issues with this at first, as the installer was running as NT AUTHORITY, and not the actual user. To get around this we had to add a post build event to flip the impersonation bit to stop this happening. (Link for the script here: http://integr8consulting.blogspot.co.uk/2012/04/microsoft-installer-custom-actions-user.html)
    The other issue we had was that installing on devices running Vista onwards, demanded that you log in as an Admin otherwise you couldn't continue with the installation. Windows XP prompted you, but let you continue as the current user. To fix this issue, we had to edit the MSI with Orca to turn on UAC Compliance, under View->Summary Information (but only on the later versions of Orca!).

    When the deployment project was built, we signed the MSI and .exe files (this always got recognised anyway, it was just the office add-in part that didn't). So now when they ran the setup file it was recognised, and as part of that installation the intermediate certificates got installed so when Excel was opened the add-in was recognised too!

    Bit of a workaround, but glad it's working!
    Thanks for your help!

    Ian

    • Marked as answer by Ian Rufus Friday, January 18, 2013 12:56 PM
    Friday, January 18, 2013 12:56 PM

All replies

  • do you add entry in inclusion list when installing add-in via msi?
    Thursday, January 3, 2013 5:43 PM
  • From what I gather adding an entry to the inclusion list would require the end user to have admin rights on their machine wouldn't it?

    If so, it doesn't really help as most of our users don't have admin rights on their machines. We also don't want to make any major changes to the security of their machines, so I don't want to make it so that any and all other VSTO applications could be installed regardless...

    Friday, January 4, 2013 10:26 AM
  • no, this custom action should be invoked as elevated, using TrustedInstaller process. From developer point of view, just create custom action that add inclusion list entry and do not modify anything, it should be invoked as elevated action.
    Friday, January 4, 2013 5:54 PM
  • Eventually we managed to get a working installer, but this did take a couple of extra steps.
    We couldn't use a ClickOnce deployment, had to create a setup and deployment project.
    In this project we added a Custom Action to install the intermediate certificates into the users personal store.
    We had issues with this at first, as the installer was running as NT AUTHORITY, and not the actual user. To get around this we had to add a post build event to flip the impersonation bit to stop this happening. (Link for the script here: http://integr8consulting.blogspot.co.uk/2012/04/microsoft-installer-custom-actions-user.html)
    The other issue we had was that installing on devices running Vista onwards, demanded that you log in as an Admin otherwise you couldn't continue with the installation. Windows XP prompted you, but let you continue as the current user. To fix this issue, we had to edit the MSI with Orca to turn on UAC Compliance, under View->Summary Information (but only on the later versions of Orca!).

    When the deployment project was built, we signed the MSI and .exe files (this always got recognised anyway, it was just the office add-in part that didn't). So now when they ran the setup file it was recognised, and as part of that installation the intermediate certificates got installed so when Excel was opened the add-in was recognised too!

    Bit of a workaround, but glad it's working!
    Thanks for your help!

    Ian

    • Marked as answer by Ian Rufus Friday, January 18, 2013 12:56 PM
    Friday, January 18, 2013 12:56 PM