I sent papers in German. The identity validation team is a different team within Microsoft, my guess is they are drowning in new edge cases they aren’t used to handling. Mine also hung for a week or two until Meha figured it out (they were confused if I was personal or biz).
Despite the F-tier UI with 0 detail about fail cases, I’m pretty sure it’s humans approving. I think that’s why people tend to try a couple different submissions — with luck you’ll get someone less confused/discerning 
Cool thanks @sudara we appreciate your updates.
I can now report, that I re-submitted and validation went through within 10 min 
The key difference in my submission was, that the first time around I submitted our DUNS number in the validation form, assuming that that would make things easier than submitting a German Tax ID, as the DUNS can easily be verified online and Apple uses that to verify, too.
This time I submitted our German VAT ID in the validation form and 10 minutes later my validation status went to status “Completed”. (They did however fix part of the input field restrictions that I mentioned on my github issue, so street address numbers now also take forward slashes like “12/3”, which they didn’t last time I tried).
So all in all it really seems like Microsoft support is on top of it and it’s just hiccups happening.
//Edit: About 1h of fiddling with our CI and I have Trusted Signing fully integrated in bash on Windows.
In case someone is looking for the magic lines that make all this work unattended:
az login --service-principal -u "$AZURE_CLIENT_ID" -p "$AZURE_CLIENT_SECRET" --tenant "$AZURE_TENANT_ID"
signtool.exe sign -v -debug -fd SHA256 -tr "http://timestamp.acs.microsoft.com" -td SHA256 -dlib "$ACS_DLIB" -dmdf "$ACS_JSON" "$path_to_your_file"
az logout
It took a few hours and Validation: Passed!
Letsssss goooooooo!!!
If anyone has a weird domain name like me (apu.software), just put in any normal domain name first. Fill out the entire form until it enables the submit button. Then, like a ninja change the domain back to your weird one. The button stays enabled and validation still works fine.
Trusted Signing works like a charm! Thanks for all the info and guides!
Has anyone managed to make it work in a GitLab pipeline on a windows runner (shared or own)? We always get an “Access denied.” error without any reasons. Works good locally (even on the same virtual machine as the runner).
Got it working in a GitHub action (local runner), but the action mentioned in some of the documentation shared in this thread is a bit out of date. I suppose since they renamed it for the public preview:
I was encountering errors getting things going locally, but this action run on the same machine worked immediately. The only problem is, when you try to run it twice from within the same action it gets an error when trying to reinstall the action:
Run azure/trusted-signing-action@v0.3.19
Run $modulePath = "F:\actions-runner\_work\_actions\azure\trusted-signing-action\v0.3.19/trusted-signing-module-0.3.18.zip"
Write-Error: Failed to create file 'F:\actions-runner\_work\_actions\azure\trusted-signing-action\v0.3.19\TrustedSigning\about_TrustedSigning.help.txt' while
expanding the archive file 'F:\actions-runner\_work\_actions\azure\trusted-signing-action\v0.3.19\trusted-signing-module-0.3.18.zip' contents as
the file 'F:\actions-runner\_work\_actions\azure\trusted-signing-action\v0.3.19\TrustedSigning\about_TrustedSigning.help.txt' already exists. Use
the -Force parameter if you want to overwrite the existing directory
'F:\actions-runner\_work\_actions\azure\trusted-signing-action\v0.3.19\TrustedSigning\about_TrustedSigning.help.txt' contents when expanding the
archive file.
Kind of annoying. Will likely just remove the folder after each instance.
Other than that, pretty straightforward.
I’m wondering, has anyone had success setting this up with PACE cloud signing?
When I try, my PACE signature helper (basically the same thing as the bat script in the tutorial, just invoking the signtool.exe with the appropriate dll/json files) does the platform signature, no problems, exits on 0 and then wraptool fails…
Has anyone encountered this? Here’s an excerpt from my logs, showing how the platform signature succeeds and how wraptool fails on the same file then right after
$ "${wraptool}" sign --verbose --account "$PACEACCOUNTNAME" --password "$PACEPW" --signtool "$PACE_SIG_HELPER" --signid 1 --extrasigningoptions "digest_sha256" --allowsigningservice --wcguid $PACEWCGUID --in "$AAXFILE" --out "$SIGNED_TEMP"
[...]
Submitting digest for signing...
OperationId dc85ad42-59e3-4c48-adf9-112d0448af7a: InProgress
Signing completed with status 'Succeeded' in 3.3497466s
Successfully signed: C:\Users\myuser\AppData\Local\Temp\76649702-134c-4ef1-a28a-9ff99cfac110\MyPlugin.aaxplugin
Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0
PACE signature helper finished with exit code: 0
wraptool Error: pace::eden::thrift::exception::PaceThriftExceptionWire: WrapToolException::ErrorSigningTarget, 38, Failed to sign the target binary., wrapinstallerserverbase.cpp, line 998, Path to target we tried to sign: "C:\Users\myuser\AppData\Local\Temp\76649702-134c-4ef1-a28a-9ff99cfac110\MyPlugin.aaxplugin"
Speaking of Pro Tools, is it actually even necessary to use Trusted Signing for AAX if you’ve already got a wraptool signing process in place? I would think the primary reason for using Trusted Signing is to prevent installers from throwing up anti-virus warnings. That and .exe files which can be run directly.
Only thing I can think is if an anti-virus is actively monitoring LoadLibrary from Pro Tools at runtime (which is possible), or if it’s scanning every file on disk for PE headers.
Just curious if anyone has a definitive reason/need.
I’m not sure how much I can go into detail here because of the PACE NDA (so I won’t), but you need a regular old certificate and signtool alongside the wraptool to sign AAX (doesn’t matter if it’s OV or EV). So currently I’m using my SSL EV certificate with dongle for that, but in order to upgrade to Azure I also have to do the AAX signing with Azure, instead of with my SSL EV cert. OV certs are also only coming on dongles going forward, so that’s the whole reason why I’m trying to move everything to Azure, including the AAX signature. I’m already using PACE cloud signing in combination with my EV hardware dongle, now I’d like to use PACE cloud signing with Azure Trusted Signing instead
My question was more general and not directed toward your case. I currently actually use my macOS certificate for Pro Tools and it works fine. So introducing Trusted Signing adds complexity since it isn’t out-the-box compatible. I’m basically trying to avoid dealing with the Python wrapper workaround if it’s not actually important.
You use your macOS certificate on Windows? (This is all about signing AAX on Windows, there is no need for Trusted Signing on macOS)… if you tell me this works, i will absolutely go and try that!
Only for AAX, and only because I didn’t previously have a proper EV or OV certificate. It has apparently been fine for AAX as I’ve never had a user complain about it.
O M G! I’m going to try this! I guess it makes sense that it would work? It’s just a certificate by a valid authority, and that’s really all that wraptool wants I guess… Since I’m delivering my mac certificate to CI builds via AWS Secrets anyways I can just deliver it to the windows runner as well and pass it to wraptool! I’ll report back if that actually works (and please someone stop me and tell us why this is not a good idea!).
I’m still interested in hearing if anyone figured out using Trusted Signing with PACE cloud signatures or if anyone sees a glaring error in my approach? It should work, the platform signature is happening as it should, no matter if it’s happening through my EV dongle or through Azure… and then wraptool fails after that, but only when the platform signature was done through Azure.
So, I just tried this out.
While it seems to work, I also get this in the PACE output:
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.
Which makes sense…So, I think I’ll have to hit up PACE support and see what Sergio has to say about using wraptool with Azure Trusted Signing…
yea, it was always a half-measure on my part. better than nothing but certainly not correct.
I’m trying to create a Trusted Signing Account now, to maybe take advantage of the last few free days 
, and apparently I may already be too late: Seems like I need to select a pricing tier right off the bat?
Hey @vberthiaume
Are you talking about the 100 bucks azure credit or so that you are promised on signup? I got that too, but it expires after a while so it’s not like you save a ton, i think it’s 2-3 months that you can save here, so <30$ if you only want to use Trusted Signing. I had to setup billing and everything too, and now it’s just using that credit while it’s not yet expired I think.
The only thing I haven’t gotten to work yet is PACE cloud signing, but other than that it’s an extremely smooth experience to sign, well worth the 9.99/mo
It might not actually charge you (yet). My Azure subscription is pay-as-you-go and it is still registering < $0.01 in costs even though I have a Trusted Signing account in the “Basic ($9.99/mo)” pricing tier. Maybe for now the name is just a misnomer until they come out of preview?
@koaladsp-cecill
Your guide assumes a physical iLok for AAX right?
I’m currently trying to setup iLok Cloud Signing with Azure, and as described here
here it fails, after the Azure platform signature finished.
I have already contacted PACE support asking about this, but so far they opted to link back to your tutorial, instead of actually responding to my email - and looking at your tutorial again, you don’t seem to be using iLok Cloud. Do you have any insight on this?
