Remove installation/security warnings by using an Extended Validation Code Signing Certificate (MacOS: done, Windows: todo)

[rdeltour]

No description provided.

[danielweck]

https://www.electron.build/code-signing

[rdeltour]

Status of the Apple certificate progress

The objective is to enroll in the Apple Developer Program as an organization.

For this I need:

• an Apple ID with 2FA
  • originally I tried to bind my primary Apple ID to the DAISY organization, but this wouldn't work since this ID already was registered as an Apple Developer Program account holder (for the now-deprecated Apple Safari Extension Developer Program). Quoting the reply from Apple:

    you need to create a new Apple ID or use a different Apple ID for the new company enrollment.

    One Apple ID cannot be the Account Holder of two developer programs at one time. Since your Apple ID is already the Account Holder of your individual account it cannot be used for a new company account

  • I then created a new Apple ID with a daisy.org email address, that I would use to enroll in the ADP as an organization.
  • I enabled 2FA to this new Apple ID, by linking it to one of my devices.
• a D-U-N-S number identifying the organization
  • “US Fund for DAISY”, the public charity registered in the US for the DAISY Consortium as a D-U-N-S, which I retrieved from the Dun & Bradstreet lookup tool.
  • the idea is to enroll as “US Fund For DAISY” so that we can be eligible to the non-profit fee waiver (requires to be a non-profit in one of the eligible countries, including the US).
• legal entity status (“Your organization must be a legal entity so that it can enter into contracts with Apple.”)
  • This seem to currently not be verified. Quoting an email from Apple support:

    I was unable to determine the legal entity type of your company because your Dun & Bradstreet (D&B) profile is incomplete.

  • I filed a case to Dun & Bradstreet to check that our information is complete and see if they can update it. They're supposed to get back to me in 1-2 business days.
  • Update 2019-07-10: D&B updated our D-U-N-S info with the legal entity type (non-profit corporation). We have to wait 7 days before it reaches Apple's systems.
• legal binding authority (“you must have the legal authority to bind your organization to legal agreements”)
  • this should be OK, Apple says the application can come from a “senior lead developer” (in addition to the founder, owner, CEO, etc), and of course I got the go-ahead from the executive team at DAISY 😊.
  • if ever this cause any issue, we can ask Richard to file this for us.
• a website

Once DAISY is finally enrolled in the ADP as an organization, I will be able to add our Apple ID to it, and to get a certificate.

I'll update this comment as the process moves forward!

[danielweck]

Thanks Romain! :)
PS:
s/APD/ADP

[rdeltour]

Status of the Windows certificate progress

On Windows, according to the electron-builder doc:

To sign an app on Windows, there are two types of certificates:

• EV Code Signing Certificate
• Code Signing Certificate
  Both certificates work with auto-update. The regular (and often cheaper) Code Signing Certificate shows a warning during installation that goes away once enough users installed your application and you’ve built up trust. The EV Certificate has more trust and thus works immediately without any warnings. However, it is not possible to export the EV Certificate as it is bound to a physical USB dongle. Thus, you can’t export the certificate for signing code on a CI, such as AppVeyor.

We'd need to buy a cert from the following authorities, which are trusted by Windows: Symantec, Certum, Entrust, GlobalSign, Comodo, DigiCert. The cost seem to be around 300/400 USD per year.

Certum provides an Open Source Code Signing Certificate which is much cheaper (~30 USD). But I'm not sure it fits our needs. One of the difference with the standard certificate is that the open source one is not "cross-certified by Microsoft". Looking deeper, it seems it doesn't support Microsoft's Authenticode technology. I don't know if it's an issue for us…

Also, the Certum certificates seem to rely on a physical USB token and cryptographic smart card. So it's not ideal in our distributed environment. They do propose cloud-based certificates (a bit more expensive).

For now, I'm asking around if DAISY has any existing certificate plan or services that we could use for Ace.

I'll update this comment as the process moves forward!

[danielweck]

For Windows, a USB device is required to transport and authorize the cryptographic information related to the certificate (secure hardware token). The shipping delay may therefore be consequential. Further, using Windows virtual machines in order to build and test the Ace app (which is my current setup / workflow) might be problematic when using a USB crypto key.

Regarding costs, the base price at Certum goes from 25 EUR to 69 EUR due to the need for the hardware device, but this is still reasonably cheap (note that the certificate would only be valid for a year). However, note that a proper EV certificate costs 359 EUR per year at Certum (or a bit less when buying 3 years upfront). Such EV cert would be needed to cover "Deleting the Microsoft SmartScreen Filter® system message" (trust based on instant reputation), otherwise the non-EV certificate (for open-source software) only "Eliminates system messages like: "Unknown publisher" and "Unsafe software" (trust builds up over time ... I'm not sure how that works in practice).

https://en.sklep.certum.pl/data-safety/code-signing-certificates/open-source-code-signing-1001.html

https://www.certum.eu/en/cert_offer_cert_comparision_cs/

Note that with Certum, the Open Source option does not provide the option "Certificate cross-certified by Microsoft". This, I think, is okay, because we do not need to sign low-level kernel software. See:

https://docs.microsoft.com/en-gb/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing

[danielweck]

Ah, Romain beat me to it :)
So yes, Certum is not the only option, see:
https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate

DigiCert (ex Verisign?):
https://www.digicert.com/order/order-1.php

Symantec (which seems to rely on DigiCert authority):
https://trustcenter.websecurity.symantec.com/process/trust/productOptions?productType=EVCodeSigning&flavor=MSAuthentiCode&application_locale=VRSN_US&newLanguage=en

Comodo:
https://ssl.comodo.com/code-signing-certificates
https://comodosslstore.com/codesigning.aspx
https://comodosslstore.com/code-signing/comodo-ev-code-signing-certificate

Sectigo (replaces Comodo?):
https://sectigo.com/products/signing-certificates/code-signing

Ksoftware (Sectigo sub-CA)
https://www.ksoftware.net/code-signing-certificates/

GlobalSign:
https://www.globalsign.com/en/code-signing-certificate/microsoft-authenticode/
https://www.globalsign.com/en/code-signing-certificate/ev-code-signing-certificates/

Thawte:
https://www.thawte.com/code-signing/content-signing-certificates/microsoft-authenticode/

Resellers:
https://cheapsslsecurity.co.uk/sslproducts/codesigningcertificate.html
https://codesigningstore.com/code-signing
https://store.wotrus.com/

[DaveGunn]

Both the GlobalSign certificate types appear to offer Azure Key Vault storage options, which presumably would be much faster and would provide the central storage solution we need.
https://www.globalsign.com/en/code-signing-certificate/

[danielweck]

Romain, also note that the Ace app will need to pass Gatekeeper on recent versions of MacOS, so there are additional notarization steps in addition to code signing:
https://kilianvalkhof.com/2019/electron/notarizing-your-electron-application/
(useful article from early June 2019)

[danielweck]

Dave, good point about the Azure Key Vault. However because of 2FA (Two Factor Authentication) I wonder if a mere developer like myself will be able to access the crypto key / code signing certificate "owned" by the DAISY account.

[DaveGunn]

I've not used it before, but I would anticipate access being made available through the O365 credentials - but if it requires more I'm sure we can resolve that.

[danielweck]

Another aspect to be aware of: timestamping. We might want to make sure that code signing certificates remain valid after the duration for which they were purchased (1 to 3 years). This way, in the future, even if the Ace app has not been updated for a while (and the cert would normally have expired), users will continue to be able to install the app and use it.

[danielweck]

Also note that Lets Encrypt unfortunately cannot issue Code Signing Certificates (OV or EV) due to prioritizing automation in order to be cost effective (i.e. no human verification of identity / trust).
https://community.letsencrypt.org/t/do-you-support-code-signing/370/18

[danielweck]

Certum actually provides a cloud-based crypto service which removes the need for the USB secure token. The SimplySign app must be used to operate the system:
https://en.sklep.certum.pl/data-safety/code-signing-certificates/open-source-code-signing-on-simplysign.html

[danielweck]

I have contacted Certum. In the meantime, here are some useful reads:
https://markheath.net/post/code-signing
https://blogs.msdn.microsoft.com/ieinternals/2015/01/28/authenticode-in-2015/

[DaveGunn]

The EV certificates cost a little more, but removing the MS smart screen warning is probably worth it when we can then apply the certificate across all DAISY tools. Note the open source certificate linked above is NOT Microsoft certified - so won't achieve the intended objective.
App access to the certificate management might be too restrictive for us to fully benefit from the certificate. Centralised key storage makes a lot more sense for flexible use by a number of people.

[danielweck]

The EV Code Signing Certificate is definitely the best option in that regard: instant trust assertion, removal of all warning messages on Windows (SmartScreen when downloading, as well as UserAccountControl when installing). Caveat: this requires a hardware token (i.e. secure USB key provisioning of the crypto package) in order to offer further guarantee that the private information used to sign products cannot be used by unauthorized entities. Consequently, the certificate cannot be exported and used in Continuous Integration scenarios, or in automated build workflows locally on via virtual machines. Certum's product line now provides a cloud authentication service (and a local app named SimplySign) which is meant to be an alternative to the physical hardware device for the purpose of establishing identity. However, I am pretty sure that the same build workflow limitations apply, due to the provisioning method requiring human intervention (I have asked them for clarifications, waiting for reply).

If I understand correctly, the OV Code Signing Certificate (e.g. Certum's "standard" product) removes the UAC "unidentified publisher" warning, but the SmartScreen will continue to be triggered initially, due to trust needing to build-up over a period of time. This is compliant with Microsoft Authenticode for both user-level and kernel-level code. USB hardware token remains obligatory, or in the case of Certum there is the aforementioned cloud-based alternative.

The Certum's "Open Source" Code Signing Certificate seems to be a lightweight version of the "standard" OV Code Signing Certificate, in the sense that it is bound to an individual instead of an organisation, thereby requiring fewer checks to prove identity during the registration phase. I have asked Certum whether or not the user experience is the same as with their "standard" product (with respect to the the SmartScreen and UAC warning messages). There is some ambiguity with regards to the compliance with Microsoft Authenticode too.

[DaveGunn]

A hardware token seems to be required by most providers, with the exception of GlobalSign who support the Azure Key Vault.
The reputation building process for Standard certificates isn't clear, and we risk not having sufficient instances to build the required "reputation".
The challenge with EV will be the time it takes to pass the organization validation process for the certificate to be issued, but the longer term gain is probably worthwhile.

[rdeltour]

If I understand correctly, the decision-making is about:

1. deciding on OV vs. EV certificate
2. deciding on the certificate provider

And then each point can be broken down in smaller decisions:

1. deciding on OV vs. EV certificate means:

• do we consider that getting rid of the SmartScreen warning is important? Yes.
• do we know how long it would take to build trust with our estimate user base?
• is the cost acceptable? Yes (from what we heard from DAISY's C-level. to be confirmed before purchasing of course).

2. deciding on the certificate provider

• what are acceptable Cryptographic options? Ideally we'd like to avoid a physical cryptographic token. We then need to check if the given technology is compatible with our build workflow.
  • Certum provides EV Code Signing in the cloud. Would it fit our needs?
  • GlobalSign allows EV code signing certificates to be installed in Azure Key Vault. Would it fit our needs?
  • any other option?
• compare the cost of the various certificate providers.
  • Should we compare all the certificate authorities?
  • Some certificates can be acquired from intermediaries (i.e. not directly from the CA) at a lower cost (for instance comodosslstore, ksoftware, etc…); is that an option?
  • do we buy for 1 year or more?

It seems to me we're moving towards getting an EV certificate. But there are still a few decisions to make and offers to compare. Thoughts?

[danielweck]

Some clarifications / confirmations received:

Most Code Signing Certificate retailers or Certification Authorities (including Certum) will not provide direct access to *.p12 or *.pfx files, i.e. to the private keys used for signing resources. This is standard practice. Only the public part of the certificate can be used directly. The private part is accessed via an authentication proxy, i.e. the signing keys are provisioned via a cryptographic engine that connects to a hardware or a virtual token (a-la Azure Key Vault, or Certum's SimplySign cloud solution).

This is fine, as far as we are concerned. The DAISY Ace GUI app installers are created using the ElectronBuilder set of utilities, which connects to the key provisioning subsystem via an explicitly-specified certificateSubjectName (see https://www.electron.build/configuration/win#WindowsConfiguration-certificateSubjectName ). This is not dissimilar to MacOS's KeyChain.

[danielweck]

I have received confirmation that the only difference between Certum's "Open Source" Code Signing Certificate and the "standard" product (besides the kernel-level software option afforded by the "certificate cross-certified by Microsoft" feature) is that the former includes "Open Source Developer" in the CN, but they otherwise have the same capabilities / limitations (i.e. basic Microsoft Authenticode, building reputation over time in order to gain SmartScreen trust).

[danielweck]

Also, the certificates issued by Certum are time-stampable, using Certum's own http://time.certum.pl or any other, e.g. http://timestamp.digicert.com

[danielweck]

So, it looks like the two top options are EV Code Signing Certificates from:

• GlobalSign (key provisioning via Azure Key Vault account), costs in € are 1 year: 309, 2 year: 569, 3 year: 709 (plus taxes)
• Certum (key provisioning via cloud authentication/validation, and SimplySign local app), costs in € are 1 year: 379 (466 inc. tax), 2 year: 599 (736 inc. tax), 3 year: 825 (1015 inc. tax)

[rdeltour]

Apparently Sectigo (formerly Comodo CA) also offers a cloud option (PDF link) (called "Cloud Service Module" or "Code Signing on Demand"). The cost is 399 USD for 1 year, 897 USD for 3 years.

[danielweck]

Note that support for Azure Key Vault entails additional costs:

https://azure.microsoft.com/en-gb/pricing/details/key-vault/
https://azure.microsoft.com/en-gb/pricing/calculator/?service=key-vault

...so although GlobalSign appears to be slightly cheaper (assuming the taxes are at about the same level as Certum), there would be a financial overhead with the Azure account and the Key Vault transactions. Further, I am wondering about the potential difficulties in setting up Azure Key Vault on developers' environments, especially Virtual Machines).

[avneeshsingh]

Many times the software, especially the large software are distributed offline, and are also installed on computers without internet connection. Will this solution work for them.

[rdeltour]

Many times the software, especially the large software are distributed offline, and are also installed on computers without internet connection. Will this solution work for them.

Yes. The cloud solution is to sign the code (on the developers side), not to verify the signature (on the users side).
As long as our certificate is issued from one of the Microsoft-approved certificate authority, that would work well offline if I understand correctly.

[rdeltour]

there would be a financial overhead with the Azure account and the Key Vault transactions

that might be included in the Azure package we already have.

We can describe a shortlist of solutions which we're confident would work for us, and then inform @DaveGunn and the management so that we can pick the best option wrt cost and infrastructure.

[danielweck]

Thank you Romain for the Sectigo PDF. The step-by-step instructions reveal what I feared: in order to sign our Electron app, we would have to introduce a manual step consisting in uploading the resource to sign, or alternatively the resource hash (in which case we would then have to integrate the signature digest back into the resource ourselves).

In other words, we would not be able to rely on ElectronBuilder's built-in support for signing (i.e. in-line, as part of the installer creation process).

[rdeltour]

in order to sign our Electron app, we would have to introduce a manual step consisting in uploading the resource to sign, or alternatively the resource hash

it seems they have an API, so it should be possible to ultimately integrate that in a custom build, if not in electron-builder itself…

[DaveGunn]

Just to confirm any Azure Key Vault costs would be covered by our existing Azure infrastructure account.

[danielweck]

Good to know Dave, thanks.

[danielweck]

Romain, good to hear about the possibility of using an API to securely communicate with the GlobalSign Code Signing service.
In ElectronBuilder there is a "sign" step which can be used to invoke an external shell script (thereby bypassing the default Windows signing method which consists in automatically querying the key provisioning subsystem via the certificateSubjectName):
https://www.electron.build/tutorials/code-signing-windows-apps-on-unix

[danielweck]

Another thing to note about obtaining an EV Code Signing Certificate: the DAISY organisational identity, as well as that of the person registering, will need to be asserted by the Certificate Authority in order to establish trust. We will therefore be required by the accredited retailer to provide documents that prove identity, which usually involves a Notary.

I am not totally sure about GlobalSign, but I imagine they do business in the USA, where DAISY has representatives. I think (based on the PDF linked by Romain) that the expectation is to have somebody from the management team registering and acting as the primary contact point + platform administrator. Then, developers like myself can obtain credentials to authenticate into the secure cloud signing solution.

Certum is based in Poland. Although they accept digital scans for their lower-tier products, I imagine the prerequisites for issuing EV certs are more stringent. I have asked about their SimplySign cloud solution, so I have a better idea of the key-provisioning + resource-signing workflow (and whether it is compatible with ElectronBuilder).

[rdeltour]

Romain, good to hear about the possibility of using an API to securely communicate with the GlobalSign Code Signing service.

Just a clarification: the PDF was from Sectigo (formerly Comodo), not GlobalSign. I don't know if GlobalSign also have an API, they probably do but this would need to be verified.

[danielweck]

Ah yes thank you Romain (typo on my part).

[danielweck]

As mentioned before, the process of applying for an EV Code Signing Certificate requires providing proof of identity, either via a Notary, or remotely by sending appropriate documentation, like Romain did to setup an Apple Developer Program for an organization (not an individual), DUNS number, etc.

Here are the instructions provided by Certum:
https://www.certum.eu/en/support/cert_expertise_tsupp_cs_requaired/

[danielweck]

I now have confirmation that Certum's SimplySign cloud+app -based virtual hardware token system integrates well with the signtool command line executable (short video tutorial):
https://www.certum.eu/en/support/cert_expertise_activate_cs_certificate_on_simplysign/

This is good news, it will integrate well with ElectronBuilder's default signing process on Windows, and can even be integrated as a custom step if we face issues with the default implementation. Basically, the virtual hardware token seems to behave just like a physical USB device.

I imagine that Sectigo's ad-hoc suite of tools (Code Signing on Demand (CSoD) + CCM Comodo Certificate Manager) operates in a very similar way, and that GlobalSign's Azure Key Vault provides a similar integration path.

[danielweck]

Another technical thing to note about Certum's SimplySign: the signtool command line instructions are based on the certificate's thumbprint (whereas ElectronBuilder integrates via certificateSubjectName), which means that we might indeed have to use the custom sign step in order to invoke our own custom script. Still, the process seems very simple using a temporary token.

I had another look at Sectigo's PDF (Code Signing on Demand (CSoD) + CCM Comodo Certificate Manager), and I don't see an integration path with signtool, so this might be problematic.

[danielweck]

The MacOS app / DMG code-signed with the DAISY certificate works when launched locally without any warning messages, but the app indeed fails to launch when downloaded from an external source (GateKeeper blocks it due to not being notarized):

“Ace by DAISY.app” can’t be opened because Apple cannot check it for malicious software.

This software needs to be updated. Contact the developer for more information.

Safari downloaded this file today at 00:45.

[danielweck]

Positive progress:

spctl -a -v /Applications/Ace\ by\ DAISY.app
=>

/Applications/Ace\ by\ DAISY.app: accepted
source=Notarized Developer ID

The Gatekeeper message is now:

“Ace by DAISY.app” is an app downloaded from the Internet. Are you sure you want to open it?
Safari downloaded this file today at 01:53. Apple checked it for malicious software and none was detected.

(with the "open" button, so no need to right-click + open menu)

[danielweck]

codesign -dvvv --verbose=4 /Applications/Ace\ by\ DAISY.app

=>

Executable=/Applications/Ace by DAISY.app/Contents/MacOS/Ace by DAISY
Identifier=org.daisy.ace
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=1753 flags=0x10000(runtime) hashes=46+5 location=embedded
VersionPlatform=1
VersionMin=657920
VersionSDK=658432
Hash type=sha256 size=32
CandidateCDHash sha1=a2f037a9844147925510c5d6e2c9db64d22d78f5
CandidateCDHash sha256=ff61ac272a690ba6b2cb645a2a58b63a28d99a19
Hash choices=sha1,sha256
Page size=4096
CDHash=ff61ac272a690ba6b2cb645a2a58b63a28d99a19
Signature size=9064
Authority=Developer ID Application: US Fund for DAISY (SAMG8AWD69)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=19 Jul 2019 at 01:39:20
Info.plist entries=23
TeamIdentifier=SAMG8AWD69
Runtime Version=10.12.0
Sealed Resources version=2 rules=13 files=17520
Internal requirements count=1 size=176

[danielweck]

I tested the app with the default notarization entitlement com.apple.security.cs.allow-unsigned-executable-memory, all the features in the app seem to work fine.

[rdeltour]

Awesome! Thanks for the hard work Dan 👍🎉

[danielweck]

Related issue: #10

[ways2read]

I have a call with a Microsoft MVP on Thursday, who is helping out with code review and advice for the WordToEPUB proof of concept. I will be asking about code signing to remove the scary messages for the not so technical users of this tool. I've read this thread in preparation, and will report back. It may be that some learnings can be useful for ace-gui.

[DaveGunn]

A 3 year EV Code Signing Certificate has been ordered through GlobalSign Ltd. Verification will probably take a couple of weeks after which it will be available for use through the Azure Key Vault.

[danielweck]

This is wonderful news! Thank you for taking care of this.
Let's hope this will integrate with the Ace App build workflow! :)
Fingers crossed.

[DaveGunn]

The security around hosting a central EV certificate means it probably won't be a simple add-on process. We may need a VM build platform with access to the Vault - so obtaining the certificate is only step one in establishing a certification process.

[labsforge]

Hi Ace team! it seams we're on the same journey! what a tedious and horrible experience... It has been a good reading this issue, has we had hit the same walls too 😅
We also acquired the EV certificate from globalsign, and now we are trying to figure it out on how to integrate it with electron-builder.. if you have any progress on this would be very helpful! btw this should be featured on electron-builder docs, because it haves all the process of decision on witch certificate to buy and why, I wish I've seen this before..

[danielweck]

Hello @labsforge I am glad to hear that you managed to extract useful information from this messy / organic conversation thread! :)

We're using an ad-hoc environment variable SKIP_NOTARIZE to make sure that the afterSign NPM task (which is part of the electron-builder process) is not invoked when the app is built from the Continuous Integration server (in our case, Travis).

ace-gui/.travis.yml

Line 96 in 41c3fb5

yarn run package:mac:skip-notarize ;

ace-gui/package.json

Line 143 in 41c3fb5

"package:mac:skip-notarize": "cross-env SKIP_NOTARIZE=1 yarn run package:mac",

ace-gui/package.json

Line 50 in 41c3fb5

"afterSign": "build/notarize.js",

ace-gui/build/notarize.js

Line 6 in 41c3fb5

if (electronPlatformName !== 'darwin' || process.env.SKIP_NOTARIZE) {

Extra tip: in another project we also use the CSC_IDENTITY_AUTO_DISCOVERY=false environment variable to ensure that electron-builder does not automatically discover a locally-installed signing certificate (e.g. MacOS KeyChain) when building from a developer computer. This allows us to build production-grade apps (i.e. code-signed and notarized), as well as "preview" / test apps (not signed) on the same computer.

[danielweck]

...as for the Windows code-signing process: we are currently looking into how to make this work as part of our electron-builder workflow. Unlike our current MacOS setup which relies on KeyChain to supply the private signing certificate / key to ElectronBuilder, the Windows setup will probably involve a physical USB "token" key. Personally I hope that we will be able to use a remote / online authenticated vault instead, as this would be much more convenient (not least, because I tend to build the Electron app from a VirtualBox Windows 10 VM, rather than from a physical computer).

[labsforge]

The macOS part with notarization we figure it out too, the windows part I'm still thinking on how to...
We have the usb already.. and I'm waiting on instructions on how to setup the Azure Key Vault. Then I think I can do something like this https://github.com/jfatta/KeyBall, but will take ages to sign all the dll's because we have some native modules 😓

[danielweck]

Windows signing is implemented via a manual step (not automated through Electron Builder). Closing this issue now.

[pavlobu]

this was is a useful discussion. Thank you all !