Add support for signing ClickOnce manifests

[kauppine]

Currently, Azure Trusted Signing does not support signing ClickOnce manifests.

It would be a great improvement and increase the usability of the service, if it could be used to sign ClickOnce manifests in a similar manner as with dotnet Sign: https://github.com/dotnet/sign

[Jaxelr]

hi @kauppine thanks for reaching out on requesting this integration. As of now, the team is still evaluating & discussing how to proceed with support for ClickOnce.

[JaapMosselman]

I am currently evaluating the Trusted Siging service and it looks very promising.
Signing exe and msi files is no problem.
But I also need to sign ClickOnce manifest files.
Direct support for this would be very helpful.
Or some guidance how this service can be used with mage.exe.

[JaapMosselman]

@kauppine For the case you missed it: dotnet Sign prereleased last week a version with support for Trusted Signing.
Works fine, but not yet with Clickonce, but there is already a PR waiting to be completed to fix the bug.

[Jaxelr]

For awareness, keep in mind that the even with the dotnet/sign integration working as expected, we still have some limitations on the way that clickonce handles trust by pinning to a certificate thumbprint. Given that trusted signing manages short lived keys, the experience could be subpar for users.

[JaapMosselman]

@Jaxelr In which way could the experience be subpar for users? I have tested it now for some days. I have tested several situations.

• Clickonce created and signed a week ago and installed it. Started it today again, it did the update check (but there was no new version) and started correctly.
• Clickonce created every night (but no new version of binaries and so version of clickonce remains also the same). I installed that yesterday and now started it today again. Update check went well, no new version, so no update, although the current clickonce is signed with newer certificate.

So as for now I don't see problems for my scenario's.

[kauppine]

@JaapMosselman Thanks for notification! We were already using dotnet Sign, but had missed it.
@Jaxelr would this results in a subpar experience also in the case where the ClickOnce manifests have been properly timestamped?

[Jaxelr]

Whenever an update is performed, the certificate used for futures versions will be different, hence you will need to grant trust on each subsequent update, instead of it being seamlessly. This is because ClickOnce pins trust to the thumbprint instead of other relevant properties of the certificate (ekus, subject). Functionality wise, yes, it would work. Even timestamped, it will follow the same behavior.

[JaapMosselman]

Ah, clear. So the difference is that on an update the user has now to press the Install button, while when the certificate is not changed, the update whould be installed fully automatically without user interaction.
That would in the old situation also have happened when your code signing certificate was renewed after one or three years.
Curious about the thoughts from your team about this.
But for the time being, we can live with it, I think, because our users are already used to an expired certificate for more than a year 😳and have to hit the install button even with a red shield beside it. So now with a yellow shield is already better.

[Jaxelr]

Curious about the thoughts from your team about this.

I can't speak for the team but personally I would, of course, prefer this experience would be seamless for everyone, allowing us the ability to leverage short lived keys while also maintaining our trust posture.

On a more positive note, it's a good data point to understand that it is still usable in certain aspects. I'll also mention this to the team, since we've seen interest on having this formally supported as well.