Electron-builder: NSIS code signing and SmartScreen

[sagorshkov]

• 12.0.0:

• Windows 8.1:

Hello. I'm trying to sign my NSIS installer. But the Windows SmartScreen blocked it after download. It's interesting that the installer was signing successfully with the electron-builder (using the certificateFile link to .pfx in package.json and password for it in the environment). I've verified my installer with the Windows SDK signtool. All right there.

Also, when SmartScreen filter window shown there is correct Company info (looks like signed correctly).

Have you any ideas what is wrong there in my app? Probably something wrong with certificate or timestamp?

[develar]

Probably because of https://github.com/electron-userland/electron-builder/issues/1182#issuecomment-275711019

[sagorshkov]

Omg. Looks like Microsoft banned s3 domains. More info here. @develar Thanks for your help.

[develar]

F* MS. Instead of fixing security model as Apple did (code sign doesn't work on MS due to obvious reasons and corrupted/hacked/untrusted exe can be installed by user) they ban domains. Ridiculous.

It is the reason why we are going to implement own check of downloaded exe in the auto update — because system check just sucks and doesn't work as must.

I will update docs to be sure that users are aware of that. Thanks for the link.

[develar]

@sagorshkov do you just use cloud front URL or custom Domain?

[sagorshkov]

@develar No, I haven't got permissions to Route 53 and Cloud Front right now. I'll try it tomorrow. At first will try DNS with Route 53. I'll report results here.

[sagorshkov]

Hey, @develar I've tested SmartScreen blocking.
Unfortunately, it doesn't work for me((( I've tested DNS via AWS Route 53. After tried with Cloud Front. I've used Route 53 to redirect my domain URL to CDN. The URL was like "appname.com/download/appname.exe". After, I tried the direct address to CDN like "d1qy...it.cloudfront.net/download/appname.exe". In both cases I've got the browser blocking:

If I select save anyway the behavior will be as in a case below:

When I'm trying "https://s3-eu-west-1.amazonaws.com/appname.com/download/appname.exe" it downloads correctly but blocking by SmartScreen when I start the installer .exe

Also, I've tested Google Drive and Dropbox. There is the same SmartScreen blocking there.
It's awful case for me((( I'll think about it tomorrow. It's possible I'm doing something wrong. But I don't know what)

[develar]

Yeah, MS as always only introduces new troubles without any added value.

Is https://github.com/develar/onshape-desktop-shell/releases/download/v0.5.6/Onshape-Setup-0.5.6.exe blocked by smart screen?

Is https://onshape-download.develar.org/download blocked by smart screen?

Is https://docs.npmjs.com/files/package.json#homepage is set to your company domain?

[develar]

@consense Do you use custom domain for cloud front? As CNAME?

[consense]

@develar yes, using a custom domain as CNAME and not seeing the problems described by @sagorshkov

[sagorshkov]

@develar No, both yours .exe are not blocking.

Yes, my homepage field is: "https://appname.com/" in package.json

Ok, I'll try it tomorrow, thanks @consense. I'm using ALIAS ( A - IPv4).

@develar is it OK that my homepage in package.json contains protocol?

[develar]

is it OK that my homepage in package.json contains protocol?

Yes, full url including protocol is expected.

[consense]

Also: in my experience both Windows Smartscreen as well as Chrome need a few hours/days to consider an exe as safe (used small custom nodejs script as a simple squirrel-server before).
After electron-builder switched to NSIS we dumped the custom nodejs server and instead directly used S3. Here Windows Smartscreen also didnt complain anymore after a few hours, but Chrome didnt stop complaining. There using a custom domain as CNAME for cloudfront in front of S3 helped.

[NTag]

I am facing the same problem.

I can download my .exe using Chrome, either from Github releases (which redirect to AWS) or from my dedicated server with a custom domain. This part works without any problem. Chrome displays no warning.

But when I try to execute it, SmartScreen appears "Unrecognized application", whereas, like @sagorshkov, my app is correctly signed (SmartScreen correctly shows the details of my organization). I also set the homepage to my custom domain in package.json.

[develar]

@NTag EV cert will solve your issue, as far I know, otherwise you have to wait several days. Say thanks to MS :(

[ErraticFox]

How does one get a EV Cert?

[tresf]

@NTag EV cert will solve your issue, as far I know, otherwise you have to wait several days. Say thanks to MS :(

Correct, the first few downloads will be prompted with SmartScreen until enough people have click allow.

How does one get a EV Cert?

It's just like a normal code-signing cert, but requires a hardware dongle and a few more interview questions/validation before issuance. DigiCert offers them as well as a few others. https://www.digicert.com/ev-ssl-certification/

I'm not affiliated with DigiCert, but I've successfully used the EV Cert and can confirm it immediately fixes the IE11 and Edge download issues.

https://www.digicert.com/ev-setup

Our public bug report which may offer more information for others stumbling across this thread on the internet: https://github.com/qzind/tray/issues/40

Admins - sorry to necrobump this, wanted to make the thread complete. :)

[peturh]

@NTag EV cert will solve your issue, as far I know, otherwise you have to wait several days. Say thanks to MS :(

Correct, the first few downloads will be prompted with SmartScreen until enough people have click allow.

How does one get a EV Cert?

It's just like a normal code-signing cert, but requires a hardware dongle and a few more interview questions/validation before issuance. DigiCert offers them as well as a few others. https://www.digicert.com/ev-ssl-certification/

I'm not affiliated with DigiCert, but I've successfully used the EV Cert and can confirm it immediately fixes the IE11 and Edge download issues.

https://www.digicert.com/ev-setup

So, if we use EV Cert, that means everytime we need to sign our app, we have to break it out of our CI solution, sign it on a dedicated Mac machine with a dongle and then jack it into the CI again?

There must be a better solution for updating and maintaining signed Electron apps.

[consense]

well - you can automate the process to some degree by e.g. having your CI-runner inside a container/VM on self-hosted hardware and having the USB patched through from baremetal into the VM.
See e.g. https://www.mgtek.com/smartcard for stuff to look out for

Nonetheless you are correct - super painful and definitely wont work with a SaaS CI system such as circleCI.

[peturh]

well - you can automate the process to some degree by e.g. having your CI-runner inside a container/VM on self-hosted hardware and having the USB patched through from baremetal into the VM.
See e.g. https://www.mgtek.com/smartcard for stuff to look out for

Nonetheless you are correct - super painful and definitely wont work with a SaaS CI system such as circleCI.

The mgtek thing is interesting but since we will have to build it on Mac (because of signing mac only works on mac). Anyhow, thanks!

[tresf]

So, if we use EV Cert, that means everytime we need to sign our app, we have to break it out of our CI solution, sign it on a dedicated Mac machine with a dongle and then jack it into the CI again?

There must be a better solution for updating and maintaining signed Electron apps.

Correct and the CAs state that this is intentional.

On another project we entertained USB-over-WAN and an "expect" style script for handing the password prompt and it seemed possible. Note, it does remove a large part of the CA's intent of EV. :) (e.g. RaspberryPi at one person's house using DuckDNS for FQDN accessible by whitelist to the VM environments creating the build).

Large corporations use a form of dedicated appliance for the signing but that generally requires on-site infrastructure for the entire process.

The software emulators are tempting. My research showed that the smartcard hardware compatibility was very limited.