EV Code Signing certificates

[pb_man]

The entire security world is forcing EV, or token based certificate signing beginning in November of this year. What is the plan to allow InstallAware to work with this method of authentication? Right now I see no updates, only a topic from 5 years ago saying you had no plans to udpate for this technology. But now we are being forced to use it, so what is the plan for InstallAware?

[FrancescoT]

I suppose you are missing that EV code signing is already supported.
https://www.installaware.com/right-edition.htm (SHA 256 Authenticode Code Signing, EV Certificates)

[castorus]

Could you please guide on how to EV Code Signing with Installaware X13?

[JohnGaver]

Please upgrade to InstallAware X14 (or newer) for built-in extended verification certificate support.

You may also use Build Events as an alternative, if you would not like to upgrade at this time:

www.installaware.com/build-events.htm

[BartWilson]

Please upgrade to InstallAware X14 (or newer) for built-in extended verification certificate support.

You may also use Build Events as an alternative, if you would not like to upgrade at this time:

http://www.installaware.com/build-events.htm

John, I'm curious if there is documentation in how we can use InstallAware for Extended Verification? I have an EV cert that is stored in an Azure Key Store currently and the only way I have it working is through the Build Events. However if I need to build and sign a new application runtime for hosting on the internet, that isn't as easy to do through Build Events (although I haven't tried) than if the hooks are done through the Authenticode Signature.

I see the Key Container Name and CER mentioned but haven't found any documentation how to hook everything together for talking to something like Azure.

[JohnGaver]

Great to hear from you, Bart!

It would be awesome to have your command line(s) shared. It may not be too much more effort than what you've already accomplished for signing the final package binaries.

To clarify, you're not using Azure Code Signing / Trusted Signing Integration, but some kind of other Azure service to store your EV certificate online - or are these one and the same thing?

From what I understand, EV certificates always require some sort of dongle and thus are the public enemy of build automation across devices, as the dongle needs to be plugged in physically to the build device. However Azure Code Signing works around this limitation, while providing a level of trust that even exceeds that obtained via EV certificates.

[axisuser]

I have InstallAware 16, does the extended verification tab get around the need for a token? We do our install builds in automation and there is no way to apply a usb dongle.

How does Install Aware works with the extended verification requirement?
Do I need to purchase my ssl cert a specific way?

[JohnGaver]

I have InstallAware 16, does the extended verification tab get around the need for a token? We do our install builds in automation and there is no way to apply a usb dongle.

How does Install Aware works with the extended verification requirement?
Do I need to purchase my ssl cert a specific way?

There's unfortunately nothing we can do to rewrite the physical requirements of the EV technology stack. That'd break the entire EV technology foundation, something it was designed to prevent.

BTW you shouldn't buy an SSL certificate, but an EV code signing certificate - if you want an EV one, that is. You could also get an OV one, of course.

[BartWilson]

Great to hear from you, Bart!

It would be awesome to have your command line(s) shared. It may not be too much more effort than what you've already accomplished for signing the final package binaries.

To clarify, you're not using Azure Code Signing / Trusted Signing Integration, but some kind of other Azure service to store your EV certificate online - or are these one and the same thing?

From what I understand, EV certificates always require some sort of dongle and thus are the public enemy of build automation across devices, as the dongle needs to be plugged in physically to the build device. However Azure Code Signing works around this limitation, while providing a level of trust that even exceeds that obtained via EV certificates.

We have our EV Certificate in an Azure Key Vault and thus I'm calling the azuresigntool.exe to do signing of certain files outside of the Installers right now as they require an EV certificate. Obviously the command line for the usage of the signtool is very similar to using the signtool that gets installed with InstallAware but requires a bunch of keys that allow connecting to the Azure Key Vault:
azuresigntool.exe sign -kvu <vault> -tr <timestampURL> -td sha256 -fd sha256 -kvi <kvclientid> -kvs <kvclientsecret> -kvc <kvcert> -kvt <kvTenantId> file

I asked my question as it would be great if InstallAware would have the ability to put this type of configuration inside of it to do signing. Otherwise when our current cert that doesn't require the dongle expires, we are going to have to do all build events in the installers to do signing as we have multiple build systems that do InstallAware builds and are in DataCenters which makes using a dongle difficult.

It seems like the Azure Key Vault acts like a HSM.

[JohnGaver]

Thanks for the details!

How many data centers are you supporting right now?

This helps us internally justify and escalate your Azure Key Vault request, among other things.

[axisuser]

What code sign certificate vendor did you go with? I've look at SSL.com (hidden fees), DigiCert, and GlobalSign.
What is Azure's HSM cost structure?

[BartWilson]

Sorry for the delay here as I've been busy.

So I'm no expert here but it seems like the Premier pricing Azure Key Vault (not the full HSM application) will allow for creating a CSR that is FIPS 140 Level 2 compliant. Went through a POC doing this back in February of this year using the Globalsign document here:
https://support.globalsign.com/code-sig ... -Key-vault. We had been using Globalsign for doing our code signing before with a pfx file on each build box and found their pricing to be a bit less than DigiCert.

Right now in the POC I'm doing all of the signing through the Azure Key Vault within our internal network and have tested doing the azuresigntool on multiple systems internally. When I look at the library/binary files after signing, everything looks OK. Recently I'm working on shifting from the POC Azure Key Vault to our production Entra ID Domain in Azure and was able to copy the POC certificate by exporting it in a PEM and then importing in the new Azure Key Vault with premier pricing. The quick test of the azuresigntool worked without issue.

At the beginning of this thread I said I'm not an expert but maybe someone else can chime in that if the CSR I generated in the Azure Key Vault with premium pricing wasn't FIPS 140 Level 2 compliant, I would have assumed that the Globalsign EV Code Signing certificate that we purchased (passed in the CSR into it) would have said it wasn't compliant. How smart is that CSR check? I don't know.

[axisuser]

I ended up using google hsm and a global sign code cert. This is so wildly cheap compared to the other vendors with there own signing tool. Ssl.com would have been around $15k/year but with Google hsm we are paying less then $100.