"Not valid 64-bit AAX Plugin" issue on Windows Pro Tools

Hello everyone :wave:

I have an issue with signing the AAX plugin for windows. I have already contacted Avid and got an “Only Sign” certificate. I am able to sign my AAX plugin on Mac. It works fine.

But unfortunately, on windows, it says that "the binary sıgned successfully but it may not run properly due to invalid root certificate ". The certificate that I am using is from my Mac. I don’t have a certificate for my installer on Windows.

Mac = apple certificate + Only sign AAX

Windows = self-generated certificate(from Mac) + Only sign AAX

P42 Climax issue pic

Is there a way to get rid of this issue by using a self-generated certificate? Maybe I could not generate it correctly.
Should I buy a certificate? which one should I buy? because there are many different providers and versions of the certificates. Would an ordinary certificate work fine?

Thanks in advance.:pray:

Without needing to go into anything protected under the NDA for Avid’s SDK, I’ll say you might want to follow up on how to fix that “invalid root certificate” warning you are seeing in Windows. That might mean that you need to update the root certificates stored by the Windows system, so that it can validate the self-generated certs that presumably used those same root certificates. A general certificate utility tool could help you troubleshoot this issue (like this one - can’t vouch for it, it’s just the result of a quick Googling).

Are you sure you’ve signed successfully?

As a friendly reminder,
On Windows there’s no concept of signed folder. You should sign the actual DLL inside the aax folder.

After the signing, I got this :
“Warning! The executable has been signed successfully. But the certificate (key file) used for the signing doesn’t have a trusted root in the system.
It may be impossible for Windows OS to verify the signed executable. It is a good idea to use a Windows-compatible code signing certificate.”

Is it because of my windows license? it is windows 10 Pro and I have bought it.

When i tried to test the self-generated certificate with the software that you suggest, I got this.

Adsız

Looks like yes but i dont know if there is something wrong with my windows 10 license or is it because the self-generated certificate.

@refusesoftware , @ttg

I just bought a new windows 10 pro license and changed my windows key.

But still i get the same message. "the certificate (key file) " tells me that it is because of the certificate that I generated from Mac. Am I wrong?

Would this work ?
https://comodosslstore.com/codesigning-2.aspx

I’m pretty sure your issues are more related to how you sign. not the certificate itself. the self-generated one seems to be working fine.
You should go to Avid dev forums or try obtain support through e-mail with them.

Thank you very much . I see what you mean. I just tested it again. Still i am getting the same message but my plugin is woking on Pro Tools now. it was really strange.

I am planing to buy the code signing certificate from here to sign my installer . For now it says “Unknown” for the company. Would standart validation handle it ? The EV is very expensive :slight_smile:

I’m also using a Comodo certificate for singing my installers on Windows.
You don’t really need the EV certificate (I also found that too expensive).
The only thing it does, is automatically make your signed installer have sufficient “reputation” to avoid that blue Windows Smartscreen warning dialog (that dialog will still say that the installer is correctly signed though, it’s purely a Smartscreen reputation thing).
Note that this is different from the orange/yellow dialog you get when your installer is totally unsigned.
If you get enough downloads of your file, your Smartscreen reputation will get higher and that blue dialog will eventually also not be shown any longer (that’s how I understood it).

Oh, one extra note (maybe you already know this, but I didn’t initially, so I’ll just mention it):
When you sign the installer using signtool.exe, make sure you look into adding a timestamp with the /tr flag. Because if you don’t, at some point your certificate’s expiration date will have passed, and from that moment onwards, when you run the installer, you will again get that yellow/orange “unknown publisher” dialog. If you sign with a timestamp, you don’t have that issue later on (this would of course only be an “issue” if people run your older installers past the certificate’s expiration date they were signed with, but that typically does happen).

1 Like

EV is expensive. But, without it, we’ve discovered that non-EV signs unless the binary is running on enough machines could be blocked by several anti-viruses and even Microsoft’s SmartScreen.

Thank you :pray:

I recently submitted my code sign certificate form. It is being evaluated right now.

I am using the timestamp in my OSX binaries but i didn’t know it is necessary for the Windows.

After getting it, I will make sure that I added a timestamp flag.

I see. Anti-viruses are very annoying. Then users need to add the install to exceptions folders which is scary and difficult for most people.

Then looks like this is all marketing. They have standart validation which at least should provide more than a name on the installer. If anti-viruses and Microsoft’s SmartScreen are going to block the application, then this means that the certificate is not doing anything.

EV vs. standard code signing cert. on Windows:
Yes, if you want instant Smartscreen reputation you need EV, so if you can afford it/find it worthwhile, it’s definitely better to get an EV certificate.
I personally haven’t heard about my plugin (or other) installers getting blocked by Smartscreen or anit-virus software over the past 8 years, but I can imagine @ttg has a lot more data points to go on (I’m a very small developer, so there are not that many people using my plugin, and I probably got lucky, or the ones who got it figured it out, never told me or just moved on).

I do know that Smartscreen initially shows that blue dialog if you’re using non-EV code signing certificates, but that’s not an actual “block” (albeit very annoying to see): you clearly see on that dialog that the software was properly signed + the name of the developer/company, and you just click “Trust” and it’s all fine. And once you have enough downloads, the Smartscreen reputation exceeds MS thresholds and it won’t show up any longer.

Here is a bit more info + also some interesting advice/tips from k-Software (collected from experiences by their user base) on how to build Smartscreen reputation quickly:

It’s not blocking, but similar to have notarized app vs non-notarized.
You need to be ‘smart’ user to understand the emphasis on might rather than harmful and to find the button to run.
The same things also goes for notarizing macOS app though with Apple it’s 99$/year which which is more predictable and affordable.

For an open source project I’ve released a few months ago (outside of my workplace), I did get a paid Apple developer but have no intention to pay for certificate. also for AAX I use self-signed one.

The plug-ins btw aren’t being blocked as far as I know. usually the installers (executable at least) is what SmartScreen or third-party Anti-Virus warns the user about.

OK, I see. Thanks for the clarification.
And yes, it’s about the installer exe indeed. At the moment I’m not signing plugin dlls on Windows (yet…)

Edit: except for wraptool-signing AAX plugins of course