[Solved] Do you Code-sign your VST's and VST3's on Windows?

[tsenkov]

Hey JUCErs,

So I do sign the installer (and uninstaller) as well as the AAX plugins on Windows (and I sign all plugins and installer on Mac), but I am wondering if you would usually sign your VST & VST3 on Windows?

[chkn]

Yes!

And it makes sense, checking the certificate is the only way the end-user can test, if the plugin which he/she has downloaded, actually is the one the developer has created.

I would wish that DAWs generally would only load proper signed plugins, this would make copy protection a (little) bit easier.

[tsenkov]

Makes sense. Thanks @chkn.

[tsenkov]

BTW, I have also asked another question I would love to get your opinion on: Do you preemptively submit installers for whitelisting to anti-virus software companies?

[reFX]

We sign our installers and that may prevent AV from complaining.

[pizzafilms]

I’m a Mac guy…what’s the simplest way to sign my Windows installers? Thank you.

[tsenkov]

Well I am using Inno Setup + Microsoft’s Signtool.

I make notes of such convoluted topics the first time I go through the process and these are specifically for signing the installer (the export of the certificate is very weird and there might be a better way, but this worked for me). This is how I integrated the signing in my automated build, so may not be the simplest way if you don’t make release-build binaries often.

---

Installer signing

Getting a certificate

You will need a .p12 certificate to sign the installer. Buy one from a reseller of Comodo, not directly, because direct sales are usually more expensive.

NB!: Request/buy the certificate from Firefox on some computer and then claim and install the certificate on that same computer and that same browser. Finally export/backup the certificate through Firefox Settings (should be listed as personal certificate). The p12 file you export is what you will use on your Windows build machine.

Before you are able to claim/download your certificate, they will need to verify your company phone - check Duns and Bradstreet for a record of your company (D-U-N-S number) if you need to make an update - don’t try directly D&B, they don’t directly change international companies’ data (if your company is outside the US). Instead find your company’s record through upik.de (for EU companies) and submit an update from there. May take up to 30 days for the update to get processed, so plan this a lot earlier and in advance way before a release (2-3 months at least).

Signtool

To sign the installer you need to use Microsoft’s Signtool 6.3. This can’t be installed separately and you need to install Windows SDK 8.1 to get it on your system. Use the 32bit version of the tool. There is a need for double signing and you need to timestamp that signature through comodo’s timestamp server (in the same command).

Inno Script Studio

Create 2 sign tools: Tools -> Configure Sign Tools.

signToolSha1

"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool.exe" sign /f "path/to/certificate.p12" /t http://timestamp.comodoca.com $f

signToolSha256

"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool.exe" sign /f "path/to/certificate.p12" /fd sha256 /tr http://timestamp.comodoca.com/?td=sha256 /td sha256 /as /v $f

---

And the rest is kind of preserved in my build (my build is in Javascript, this is a grunt-exec cli command spec which just creates the text of a CLI command to be executed):

...
build_signed_installer: {
    // Compile installer
            // ISCC.exe inno-setup-installer-build-script.iss
        // Double-signing because of this issue:
        //     https://support.comodo.com/index.php?/Knowledgebase/Article/View/1102/38/code-signing-certificates---sha-1-and-sha-256-information
    command: function () {
        return [
            "ISCC.exe ",
            "\"/SsignToolSha1=$q" + signToolPath + "$q sign /f $q" + signCertificatePath + "$q /t http://timestamp.comodoca.com $f\"",
            "\"/SsignToolSha256=$q" + signToolPath + "$q sign /f $q" + signCertificatePath + "$q /fd sha256 /tr http://timestamp.comodoca.com/?td=sha256 /td sha256 /as /v $f\"",
            INSTALLER_CONFIG_NAME
        ].join (" ");
    },
    options: {
        cwd: productPath,
        maxBuffer: UNLIMITED_SIZE
    }
},
...

This is how I verify signature:

...
validate_installer_signature: {
    command: function (installerName) {
        return [
            signTool + " verify",
                "/pa",
                installerName
        ].join (" ");
    },
    options: {
        cwd: productPath,
        maxBuffer: UNLIMITED_SIZE
    }
},
...

And your setup spec should have something like this:

...
[Setup]
...
SignTool=signToolSha1
SignTool=signToolSha256
...

---

I hope this is helpful.

[pizzafilms]

VERY! Thank you for being so generous.

[onqel]

Keep in mind that when signing plugins using a trusted certificate (usually limited to 1 or 2 years validity) that Pro Tools refuses to load signed plugins after its certificate has expired. I would recommend using a custom self-signed certificate with a custom experiation date to sign plugins and restrict the use of a real code signing certificate to the installer software.

[chkn]

@onqel

Keep in mind that when signing plugins using a trusted certificate (usually limited to 1 or 2 years validity) that Pro Tools refuses to load signed plugins after its certificate has expired.

Oh really? We have to differentiate, when signing with windows signtool, the validity date of the certificate means, how long you can use a certificate to sign a exe/dll, i guess?

But that ProTools refuses plugins, which has been signed (with the pace wraptool) at a date, while the certificate was valid, after the date has expired, is a new information. Is this really true? (It would make no sense). Can anybody confirm this?

[onqel]

This is our experience after using a 2-year StartCom certificate. Our plugins suddenly started failing PT validation and reapplying the signature using a different certificate with a valid date fixed it. It would be interesting to hear other’s experience on the matter. We signed using wraptool on both platforms (Win/Mac) and it affected both…

[chkn]

Thanks, If that’s true, it would be catastrophic, that’s definetly not how signed software should be handled.

The signing process shouldn’t be possible, but signed software it self should still working.

Can someone confirm this behavior?

[erteash]

Sorry to ask this here, i couldn’t find a clear answer anywhere. If you sign an AAX plugin with other certificates like Apple’s, does it still work in pro tools?
And is it really true that the plugin stops working after the certificate has expired?

[ttg]

@erteash

Sorry to ask this here, i couldn’t find a clear answer anywhere. If you sign an AAX plugin with other certificates like Apple’s, does it still work in pro tools?
And is it really true that the plugin stops working after the certificate has expired?

On Mac - Apple Certificate works of course.
On Windows - Apple Certificate (there’s some instructions about it with the signing tool…) works. If you have code-signing you can use it. both works.

We used Apple exported cert for a while until I got code-signing to sign installers.
(spoiler - Windows Defender still makes it hard for code-signed executables if they’re not very commonly used)

Expiration - Signed binary SHOULD NOT expire. the certificate does, making it not valid for signing…

There was one time this issue on PACE protected plug-ins -

Are You Having iLok Issues? Then Read This Important Information | Pro Tools...

[moritzsur]

update: you no longer need to double sign, SHA256 works for every relevant windows version.