MS SignTool access denied error

Problem to solve

I am currently trying to get MS sign tool to run with the new Azure Trusted Signing workflow inside a self-hosted gitlab ci runner, which uses the virtual box executor with a Windows 10 guest and bash shell.

The issue is that when invoking signtool to sign an installer, it throws the following error message:

SignTool Error: Access is denied.
SignTool Error: An error occurred while attempting to sign: package/some_installer.exe

Number of files successfully Signed: 0
Number of warnings: 0
Number of errors: 1

Cleaning up project directory and file based variables
ERROR: Job failed: Process exited with status 1                                                       

Steps to reproduce

This is the offending command

"'c:/Program Files (x86)/Windows Kits/10/bin/10.0.22621.0/x64/signtool.exe' sign -v -debug -fd SHA256 -tr '' -td SHA256 -dlib 'c:/tools/signing/microsoft.trusted.signing.client.1.0.59/bin/x64/Azure.CodeSigning.Dlib.dll' -dmdf 'metadata.json' 'package/some_installer.exe'"

Unfortunately, setting the virtual box guest up to be able to work with signtool and azure trusted signing is a bit of a hassle, but it is detailed in the docs below.

Which troubleshooting steps have you already taken? Can you link to any docs or other resources so we know where you have been?

I have set everything up on a local virtual windows guest with git-bash to confirm everything works, which it does.

I checked the privileges on the installer executable with ls -l to confirm they are set to -rwxr-xr-x.

Privileges for the metadata.json file are -rw-r--r--

I set chmod a+rwx on the installer and both sign tool binaries, but still got the same error.

Docs I have used:


Please select whether options apply, and add the version information.

  • Self-managed
  • SaaS
  • Self-hosted Runners


$ gitlab-runner --version
Version:      17.0.0
Git revision: 44feccdf
Git branch:   17-0-stable
GO version:   go1.21.9
Built:        2024-05-16T13:46:14+0000
OS/Arch:      linux/amd64

Just a small update, we are still unable to run this in our standard VirtualBox executor runner, but with a separate windows VM using a shell executor, everything runs smoothly.

I have practically no knowledge of how the VirtualBox executor works, but it would appear that the process in which signtool runs somehow gets different privileges.