[feat] Improve support for Windows code signing with hardware tokens and HSM

[hckhanh]

Describe the problem

Some providers like SSL.com now require dedicated code storage for code signing certificate. As a result, extracting the key material from the certificate or the PFX File is no longer possible.

They offer two alternative options for dedicated key storage: YUBIKEY or eSigner.

I received some announcements from other provider (Comodo)``

Describe the solution you'd like

So the built-in support for code signing for Windows no longer works.

Alternatives considered

Is there any kind of change can be made to adapt this change.

Additional context

No response

[FabianLars]

And of course i forgot to update the docs as always. I'll add a warning to the docs today, thanks for the reminder.

Now about the issue itself, basically guides for EV code signing now apply for "standard" code signing certificates too. This also means that there are no official guides from our side yet and that the cli experience may not be perfect, because we couldn't get our hands on an EV certificate before. The only Tauri specifc guide i have on hand right now is this one https://merlingough.co.uk/posts/ev-sign-tauri-app but it uses cloud storage (HSM) for the key instead of an usb token. This guide is imo pretty good too but not tauri specfici and also uses HSM https://melatonin.dev/blog/how-to-code-sign-windows-installers-with-an-ev-cert-on-github-actions/

[hckhanh]

Hi @FabianLars,

Do I have to sign the exe file before bundling? I only see in the article only the msi file is signed, not the executable file after installing.

[FabianLars]

I don't think it is as much as a requirement as signing the msi, but looking at answers to questions like these https://stackoverflow.com/questions/42893957/should-executables-and-dynamic-libraries-be-signed-when-inside-an-msi-that-is-si i think i'd tend to signing the .exe too. I am aware that this is currently a bit tricky without proper token support in tauri's bundler, so if the beforeBundleCommand config in tauri.conf.json, which runs inbetween building the .exe and bundling the .msi, is not enough, you may have to run the WiX bundler manually again for now.

[hckhanh]

Yeah, I have the same idea with you. Luckily, Tauri still has some way to work around the limitations.

-c, --config <CONFIG>
          JSON string or path to JSON file to merge with tauri.conf.json

I think that I can work around with tauri config by using another file such as window.conf.json with custom beforeBundleCommand to merge with based tauri config. And i have to sign the msi again, of course.

[FabianLars]

I think that I can work around with tauri config by using another file such as window.conf.json with custom beforeBundleCommand to merge with based tauri config

If you name it tauri.windows.conf.json and place it next to the normal tauri conf, tauri will automatically pick it up so you don't even need the -c flag

[hckhanh]

Thank you for your tips. @FabianLars

[tr3ysmith]

#8718

[kalvkusk]

This would be much appreciated. Yubikey EV Code Signing feature.

[FlippingBinary]

I just went through the build process with a new OV certificate, which should be the same as for an EV certificate. After making sure I could manually sign with signtool.exe, I modified the existing properties in tauri.bundle.windows of the config to match the certificate on my YubiKey. It initially failed the build because the tsp property was missing, so I set it to true and the build succeeded. There was one annoyance of being prompted for my pin multiple times, but I'm looking into a few solutions for that. One related suggestion was to provide the password with a special syntax as a parameter passed to signtool.exe, but that is for SafeNet eTokens, not YubiKeys and I'm not sure what the correct parameters should be for the YubiKey (if it's even possible). There is also the risk of being forced to factory reset the YubiKey if invalid credentials are entered too many times in a row, so experimenting with that will require a BIOS update level of concentration.

But if something like that works, it may be helpful for tauri.bundle.windows to have some extra properties for /k and /csp if nothing else. Also, maybe tauri.bundle.windows.tsp should be set to true in the default config? I'm not sure why someone would want that set to false.

I hope this info helps. I'm very interested in this feature and want to help as much as I can.