Fred Ahrens

On our systems it takes between 2 to 4 seconds per file. Hard to say what might have an influence on this duration. It may depend on the region where your signing account is located. We use West Europe. Internet speed could also be an important variable in this game.

Easy. Isn't it?

Looks good. Have you set the environment variables AZURE_TENANT_ID, AZURE_CLIENT_ID and AZURE_CLIENT_SECRET? In Azure, if you go to the home page of your Trusted Signing Account: Under "Access control (IAM)" > "Role assignments": Is your app listed with having the right "Trusted Signing Certificate Profile Signer"?

Are the values shown for "CodeSigningAccountName" and "CertificateProfileName" correct? If yes, those values should be redacted in your post. If not, you need to update your metadata file.

The "client secrect" is related to the app used for doing the signing. You should check at https://melatonin.dev/blog/code-signing-on-windows-with-azure-trusted-signing/#step-4-create-an-app-registration if you have created the app needed for doing the signing. This "app" part was initially hard to understand for me. This app is just a placeholder without a real executable or service endpoint. The only purpose is to give it the access right for signing your files. The client secret of this app will be used on top of your other credentials for identifying the app to be used. The client secret of the app is the "Value" entry in section "Certificates & secrets" - not "Secret ID" (it's visible only for a short time; if it's no longer visible and you don't know the value, you'll need to create a new client secret). BTW: That's also the first place to check if the signing suddenly stops working. Usually it's caused by an expired client secret.

It looks like you did exclude all available authentication methods via "ExcludeCredentials". If you leave this parameter empty and provide authentication details via environment variables, you should be able to use your certificate. As long as the authentication doesn't work, you may get a lot of misleading error messages - like "Azure CLI not installed". Actually, Azure CLI is not needed at all. Without authentication SignTool will also not be able to find a valid certificate. I should mention: I assume you try to set up a simple batch file that does the code signing for you. If not, let me know your planned code signing process.

There are two places where you need to provide credential information: You need to set Windows environment variables: set AZURE_TENANT_ID=(enter your azure tenant ID here) set AZURE_CLIENT_ID=(this is the client ID of the app you have set up for authentication) set AZURE_CLIENT_SECRET =(thats the client secret value of the prepared app) Best place would be in a batch file that also contains calls to SignTool etc.. Make sure you strictly limit access to this batch file. Then you need to create the metadata.json file to be used with SignTool and the Azure Trusted Signing DLL: { "Endpoint": "correct URL for your area", "CertificateProfileName": "name of the certificate in your trusted signing account", "CodeSigningAccountName": "name of your Trusted Signing account, NOT your e-mail address or other user ID" } If the details are set correct, you should be able to authorize against the Azure Trusted Signing service and sign your files with SignTool. Setting more variables than the ones mentioned above may confuse the authorization process and may cause the internal selection of another authorization method (there are many) that might not work for your case.

Our Trusted Signing validation took about 30 minutes from creating the validation request until successful validation. But we are also Microsoft Partner for many years and this might have produced already enough interaction between Microsoft and us for giving them enough material for speedy validation. If the related documentation is correct, Trusted Signing is still in preview and is currently open only to companies that are registered more than 3 years with an Azure account.

Got it working with the help of the documentation available at Code signing on Windows with Azure Trusted Signing · Melatonin Most related documents currently online (including Microsofts documentation) still have a major error in the description of the metadata.json format. Instead of using the "TrustedCodeSigningAccount" entry you will need the entry "CodeSignigAcccountName" and set it to the name of the Trusted Signing Account in Azure -, not your e-mail address you use for logging into Azure or other Microsoft services.

I tried it and it still feels very "previewish". After being able to create the signing account, getting my identity validated and creating a first certificate, I'm currently stuck at properly submitting my credentials while trying to sign an exe with SignTool.exe. The available documentation still lacks a lot of important details and it's still too new to find suitable help at stackoverflow or similar. It might work better if you use it via Azure DevOps or GitHub. But so far it still needs some finetuning - especially the documentation - before it can be used with SignTool.exe. With the tool available at https://docs.rs/crate/trusted-signing-cli/0.2.0 I came the closest so far with simple signing an exe file - but still get errors I can't get any further explanation for.

You can control the client via command line (see https://www.virtualhere.com/client_api). This allows you to create build scripts that temporarily activate the dongle on the client system only when it's needed for signing your files and deactivating it after when the script finishes.

+1 for Proxmox. For a very long time I had the impression, it's an "enthusiasts platform for virtualization". One of our customers "forced" us to test our software under Proxmox and 1 month later most of our bare metal machines and VMs were migrated to Proxmox VMs and containers. Couldn't be happier too.

For using the code signing dongles (or any other USB device) I recommend VirtualHere. Install the VirtualHere server in the host machine and your USB dongles/devices connected to the host can be accessed via a simple client within your VMs. It's not free but not expensive and just works. Meanwhile we switched from Hyper-V to Proxmox as it has built-in USB-pass-through and other features missing in Hyper-V. But main reason was: there is actually no longer a free stand-alone Hyper-V server as it got discontinued by Microsoft.

I don't need any new features. I just need that the existing features work as intended. And there are many areas where existing features need to be made usable again (e.g. refactoring, code formatting, HighDPI). OK, one new feature would be nice: compiling for Raspberry Pi. But fixing the existing features needs to be done first.

For me it's the lack of communication. Errors happen, but at a certain stage they should start to communicate about the error and give some advice about expected timeframe for fixing the problem, possible workarounds and so on. I really don't care (that much) how long this takes - but it would be nice to get some regular updates about the progress made. We are now in a situation where we have to review our development environment and make it as independent as possible from the availability of Embarcadero servers. In result we have to stop using GetIt, and other services may follow.