vcsjones/azuresigntool

SignTool Library and Azure Key Vault Support

Azure Sign Tool

The below README is based on functionality in main which may not be the same as the latest released version of AzureSignTool. For README information about released versions, please see the README for the version's associated tag. The README for the current release can be found here.

Azure Sign Tool is similar to signtool in the Windows SDK, with the major difference being that it uses Azure Key Vault for performing the signing process. The usage is like signtool, except with a limited set of options for signing and options for authenticating to Azure Key Vault.

Example usage:

AzureSignTool.exe sign -du "https://vcsjones.com" \
  -fd sha384 -kvu https://my-vault.vault.azure.net \
  -kvi 01234567-abcd-ef012-0000-0123456789ab \
  -kvt 01234567-abcd-ef012-0000-0123456789ab \
  -kvs <token> \
  -kvc my-key-name \
  -tr http://timestamp.digicert.com \
  -td sha384 \
  -v \
  -ifl C:\list\of\file\to\sign.txt \
  C:\additional\file\to\sign\program1.exe \
  C:\additional\file\to\sign\program2.exe

The --help or sign --help option provides more detail about each parameter.

A walk-through is available if you're interested on getting set up from scratch.

Parameters

• --azure-key-vault-url [short: -kvu, required: yes]: A fully qualified URL of the key vault with the certificate that will be used for signing. An example value might be https://my-vault.vault.azure.net.

• --azure-key-vault-client-id [short: -kvi, required: possibly]: This is the client ID used to authenticate to Azure, which will be used to generate an access token. This parameter is not required if an access token is supplied directly with the --azure-key-vault-accesstoken option. If this parameter is supplied, --azure-key-vault-client-secret and --azure-key-vault-tenant-id must be supplied as well.

• --azure-key-vault-client-secret [short: -kvs, required: possibly]: This is the client secret used to authenticate to Azure, which will be used to generate an access token. This parameter is not required if an access token is supplied directly with the --azure-key-vault-accesstoken option or when using managed identities with --azure-key-vault-managed-identity. If this parameter is supplied, --azure-key-vault-client-id and --azure-key-vault-tenant-id must be supplied as well.

• --azure-key-vault-tenant-id [short: -kvt, required: possibly]: This is the tenant id used to authenticate to Azure, which will be used to generate an access token. This parameter is not required if an access token is supplied directly with the --azure-key-vault-accesstoken option or when using managed identities with --azure-key-vault-managed-identity. If this parameter is supplied, --azure-key-vault-client-id and --azure-key-vault-client-secret must be supplied as well.

• --azure-key-vault-certificate [short: -kvc, required: yes]: The name of the certificate used to perform the signing operation.

• --azure-key-vault-accesstoken [short: -kva, required: possibly]: An access token used to authenticate to Azure. This can be used instead of the --azure-key-vault-managed-identity, --azure-key-vault-client-id and --azure-key-vault-client-secret options. This is useful if AzureSignTool is being used as part of another program that is already authenticated and has an access token to Azure.

• --azure-key-vault-managed-identity [short: -kvm, required: possibly]: Use the ambiant Managed Identity to authenticate to Azure. This can be used instead of the --azure-key-vault-accesstoken, --azure-key-vault-client-id and --azure-key-vault-client-secret options. This is useful if AzureSignTool is being used on a VM/service/CLI that is configured for managed identities to Azure. Important to mention is that this option leverages the DefaultAzureCredential class which is trying to get a token via multiple options including Visual Studio Credentials and Interactive Browser Authentication.

• --description [short: -d, required: no]: A description of the signed content. This parameter serves the same purpose as the /d option in the Windows SDK signtool. If this parameter is not supplied, the signature will not contain a description.

• --description-url [short: -du, required: no]: A URL with more information of the signed content. This parameter serves the same purpose as the /du option in the Windows SDK signtool. If this parameter is not supplied, the signature will not contain a URL description.

• --timestamp-rfc3161 [short: -tr, required: no]: A URL to an RFC3161 compliant timestamping service. This parameter serves the same purpose as the /tr option in the Windows SDK signtool. This parameter should be used in favor of the --timestamp option. Using this parameter will allow using modern, RFC3161 timestamps which also support timestamp digest algorithms other than SHA1.

• --timestamp-authenticode [short: -t, required: no]: A URL to a legacy "Authenticode" timestamping service. This parameter serves the same purpose as the /t option in the Windows SDK signtool. Using a "Authenicode" timestamping service is deprecated. Instead, use the --timestamp-rfc3161 option.

• --timestamp-digest [short: -td, required: no]: The name of the digest algorithm used for timestamping. This parameter is ignored unless the --timestamp-rfc3161 parameter is also supplied. The default value is sha256. Possible values:

  • sha1
  • sha256
  • sha384
  • sha512

• --file-digest [short: -fd, required: no]: The name of the digest algorithm used for hashing the file being signed. The default value is sha256. Possible values:

  • sha1
  • sha256
  • sha384
  • sha512

• --additional-certificates [short: -ac, required: no]: A list of paths to additional certificates to aide in building a full chain for the signing certificate. Azure SignTool will build a chain, either as deep as it can or to a trusted root. This will also use the Windows certificate store, in addition to any certificates specified with this option. Specifying this option does not guarantee the inclusion of the certificate, only if it is part of the chain. To include multiple certificates, specify this option mulitple times, such as -ac file1.cer -ac file2.cer. The files specified must be public certificates only. They cannot be PFX, PKCS12 or PFX files.

• --verbose [short: -v, required: no]: Include additional output in the log. This parameter does not accept a value and cannot be combine with the --quiet option.

• --quiet [short: -q, required: no]: Do not print output to the log. This parameter does not accept a value and cannot be combine with the --verbose option. The exit code of the process can be used to determine success or failure of the sign operation.

• --continue-on-error [short: -coe, required: no]: If multiple files to sign are specified, this flag will cause the signing process to move on to the next file when signing fails. This flag modifies the exit code of the program. See the Exit Codes section for more information.

• --input-file-list [short: -ifl, required: no]: Specifies a path to a text file which contains a list of files to sign, with one file per-line in the text file. If this parameter is specified, it is combined with files directly specified on the command line. The distinct result of the two options is signed.

• --skip-signed [short: -s, required: no]: If a file is already signed it will be skipped, rather than replacing the existing signature.

• --append-signature [short: -as, required: no]: When specified the signing process adds a signature to an existing signature instead of replacing it. Requires Windows 11 or later.

Advanced

• --page-hashing [short: -ph, required: no]: Causes the Authenticode signing process to generate hashes of pages for verifying when the application is paged in to memory. If this flag is omitted, the default configuration for the operating system will be used. This flag will not affect non-PE file formats.

• ---no-page-hashing [short: -nph, required: no]: Causes the Authenticode signing process to exclude hashes of pages for verifying when the application is paged in to memory. If this flag is omitted, the default configuration for the operating system will be used. This flag will not affect non-PE file formats.

• --max-degree-of-parallelism [short: -mdop, required: no]: When signing multiple files, specifies the maximum number of concurrent operations. Setting this value does not guarentee that number of concurrent operations will be performed. If this value is unspecified, the system will use the default based on the number of available processor threads. Setting this value to "1" disable concurrent signing.

In most circumances, using the defaults for page hashing is recommended, which can be done by simply omitting both of the parameters.

Supported Formats

This tool uses the same mechanisms for signing as the Windows SDK signtool. It will support the same formats as signtool supports. However, the formats that azuresigntool and signtool support vary by operating system and which Subject Interface Packages are present on the system.

Exit Codes

The exit code is an HRESULT. Successfully signing produces a result of S_OK ("0"). If all files fail to sign, the exit code is 0xA0000002. If some were signed successfully, the exit code is 0x20000001.

Cancellation

The standard Ctrl+C key sequence is used to cancel the signing. Any in-flight signing operations are finished, then the process exits with a status code according to the complete signing operations.

Requirements

Windows 10 or Windows Server 2016 is required. Some features require later versions of Windows.

azuresigntool's Issues

Default platform for tool?

What should the default platform be for the tool, x86 or x64? I believe the way it's compiled now, it's x86. Either way is okay by me but I think it should be explicitly documented somewhere. Reason is if native dll's are required for #2, then we need to be aware of the platform.

SignFile returning code -2146762749

I'm coming to this from @onovotny's https://github.com/onovotny/SignService which includes this library.

I'm seeingAuthenticodeKeyVaultSigner.SignFile return a code of -2146762749 which googling tells me may be coming from something called WinTrust or WinVerifyTrust. In my case I suspect this is because I am testing with a certificate that is self-signed.

Does anyone have any thoughts on this? Am I on the right track with this or is this likely something else? Should I expect this to work with a self-signed certificate?

Stop using "master" as dev root.

The git branch master will be renamed to main.

Distribute tool via NuGet?

Hey @vcsjones, awesome tool. I couldn't find a pre-built version of this tool on NuGet. I see you've uploaded pre-built versions to https://github.com/vcsjones/AzureSignTool/releases already, but would you consider making it available as a .NET Core global console tool via NuGet.org? This would make the acquisition experience pretty simple:

PS> dotnet tool install -g azuresigntool
PS> azuresigntool sign -du "https://vcsjones.com" (etc...)

If you are ok with this, I made a few tweaks here to enable building a .NET Core global tool package (see master...natemcmaster:global-tool). If this is something you would take as a PR, I'm happy to send it your way and feature the tool in the blog post.

Thanks,
Nate

Ensure colors are restored on process exit

In some circumstances the program will change the text color when printing to the console (green for example) and not restore the original color by the time the process exits. This leaves the console in a state of permanently green text.

Reported in #72

Use GetProcAddress to test for platform support

Right now we just p/invoke SignerSignEx3 blindly. It would be better to use LoadLibrary and GetProcessAddress to correctly handle unsupported platforms.

Friendly error message for mismatched Publisher on Appx

The SignerSignEx3 api will return an error code if the publisher identity in the AppxManifest.xml doesn't match the subject of the certificate. As this may be a common error, would be worth trapping and returning a better error message.

Allow page hashing

SignTool allows opting in to page signing. We should allow it as well.

Add verbose command

For some reason, when running on app services, the command is taking 11 seconds for exe's and 33 seconds for appx/appxbundle.

Verbose output to the console may help trace this.

Docs / Readme should show timestamping parameters

ECDSA Support

Azure Key Vault seems to (finally) support ECDSA. We should support it, but the docs are scant on it and I don't see an announcement.

Update build.proj

Need to update build.proj to account for dotnet core tooling and publishing.

AzureSignTool hanging during build on Azure

I have seen this issue happen twice now. Our build usually completes in about 8-10 minutes and signs around 25 files. However, both times that I have seen the problem, the build was still going after 30-40 minutes, and eventually Azure cancelled it due to lack of activity. Looking at the logs it happened on trying to sign the very first file. Here is the logs leading up to and after the problem. Everything happened in the first 3-4 minutes up to the "CMD=AzureSignTool" line, which is exactly what we are sending as the command-line. The Attempting to cancel the build.... happened about 50+ minutes later. This is a rare occurrence, as this is only the second time it happened. I didn't think much about it the first time, which was maybe a week or two ago, but when it happened again in exactly the same place in exactly the same way, I thought it was worth reporting. I have replaced some of the information with "*" for security reasons.

Azure Log Excerpt:

CopyFilesToOutputDirectory:
Copying file from "obj\x86\Release\ExpressCheck.Core.dll" to "D:/a/1/s/bin/x86/Release/ExpressCheck.Core.dll".
ExpressCheck.Core -> D:\a\1\s\bin\x86\Release\ExpressCheck.Core.dll
Copying file from "obj\x86\Release\ExpressCheck.Core.pdb" to "D:/a/1/s/bin/x86/Release/ExpressCheck.Core.pdb".
PostBuildEvent:
call D:\a\1\s\signtool\signcode.bat "D:/a/1/s/bin/x86/Release/ExpressCheck.Core.dll"
Signing File: "D:/a/1/s/bin/x86/Release/ExpressCheck.Core.dll"
"CMD=AzureSignTool sign -fd sha256 -td sha256 -kvu https://**************.vault.azure.net/ -kvi ---- -kvs *** -kvc ************ -tr http://timestamp.comodoca.com -v "D:/a/1/s/bin/x86/Release/ExpressCheck.Core.dll"
Attempting to cancel the build...
Done Building Project "D:\a\1\s\ExpressCheck.sln" (Rebuild target(s)) -- FAILED.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(5165,5): warning MSB5021: Terminating the task executable "cmd" and its child processes because the build was canceled. [D:\a\1\s\source\ExpressCheck.Core\ExpressCheck.Core.csproj]
Done Building Project "D:\a\1\s\source\ExpressCheck.Core\ExpressCheck.Core.csproj" (Rebuild target(s)) -- FAILED.

Build FAILED.

"D:\a\1\s\ExpressCheck.sln" (Rebuild target) (1) ->
"D:\a\1\s\source\ExpressCheck.Core\ExpressCheck.Core.csproj" (Rebuild target) (2) ->
(PostBuildEvent target) ->
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(5165,5): warning MSB5021: Terminating the task executable "cmd" and its child processes because the build was canceled. [D:\a\1\s\source\ExpressCheck.Core\ExpressCheck.Core.csproj]

1 Warning(s)
0 Error(s)

Time Elapsed 00:56:34.91
##[error]The operation was canceled.
Finishing: Running Build Script

Move to natemcmaster/CommandLineUtils

This is a better supported and easier to work with command line parser. https://github.com/natemcmaster/CommandLineUtils

Real Error Handling

If anything goes wrong, everything blows up in to a great big ball of fire.

• Unable to find certificate in Azure
• Invalid credentials
• Invalid access token
• Unable to get key for certificate
• Invalid permissions on cert or key (no sign permission, for example)

CLI argument validation needs to give more guidance

There are many cases where the CLI will print nothing at all and give the user the impression the tool is doing nothing and is broken.

1. If an unknown flag is specified
   ex azuresigntool sign --invalid Foo.exe
2. If authentication succeeds however the credentials used have insufficient permission to AzureKeyVault objects (like a missing get permission on a certificate)
3. Need to smoke test for others.

Sniff for 16-bit files

Authenticode doesn't support 16-bit libraries. We should sniff these out and give a clearer error message than what SignerSignEx2/3 produce as they are not signable.

SHA1 signing

Hello Kevin,

thanks for creating this tool. It helped me to start using Key Vault quickly and was much easier to understand (at least for me) than the official samples. I've noticed the current README states that:

SHA1 signing is not supported by Azure Key Vault.

I just wanted to let you know it is possible to create SHA1 signature with RSNULL algorithm as I've demonstrated on StackOverflow few minutes ago.

Keep up the great work!

Split into library

The core logic should be available as a library that can be called directly.

Nothing happens

Windows 10 1903, installed the tool, ran azuresigntool and got help text. azuresigntool sign [...] does nothing. No output. Tried 1.0.1 and 2.0.17 to no avail.

.NET Core SDK (reflecting any global.json):
 Version:   2.2.203
 Commit:    e5bab63eca

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18362
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.2.203\

Host (useful for support):
  Version: 2.2.4
  Commit:  f95848e524

.NET Core SDKs installed:
  2.1.602 [C:\Program Files\dotnet\sdk]
  2.2.203 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

cc @onovotny

Suggested and supported key type and key size/elliptic curve for EV code signing CSR?

Of the options offered by Azure Key Vault (below), what is supported by AzureSignTool? Additionally, if anyone has suggestions on what is likely the most practical to use considering security and other tradeoffs, that would be useful too.

As per #36 (comment), some key type with size and/or curve elliptic name choices offered by Azure Key Vault are not supported when using AzureSignTool.

The portal at the moment offers the following key types:

• RSA
• EC
• RSA-HSM
• EC-HSM

I presume that as issuers require an HSM in order to issue EV certificates, that means we need to choose between RSA-HSM and EC-HSM.

For RSA-HSM, the portal offers the following key size options:

• 2048
• 3072
• 4096

Apparently, since 2015 NIST has recommended a minimum key size of 2048 for RSA.

For EC-HSM, the portal offers the following elliptic curve names:

• P-256
• P-384
• P-521
• P-256K

When I naively asked in a different issue if RSA-HSM with a key size of 2048 would work, @garrett-wood shot me down and I went with his suggestion to use EC-HSM with P-384. Unfortunately though, once our certficate was eventually issued I then discovered that it is not supported by AzureSignTool and/or the underlying OS.

Thanks in advance for any advice offered.

-kvi, -kvt, -kvs error

Hello, when using these three options, which the instructions imply are needed to all be used together, I get the following error:

AzureSignTool.exe sign --description "Some description" --description-url "https://a-url.net/" --azure-key-vault-url https://akeyvaulturl.vault.azure.net/ --azure-key-vault-client-id aadID --azure-key-vault-client-secret password --azure-key-vault-tenant-id aadID --azure-key-vault-certificate nameofcert --timestamp-rfc3161 http://timestamp.digicert.com/ --verbose C:\Some\File\Path.exe

echo %ERRORLEVEL%
-2147024809

Using just --azure-key-vault-client-id and --azure-key-vault-client-secret works fine though, so not sure if this is just stale docs or a bug.

MSIX Support

Figure out how to get this working with MSIX and/or what the requirements are.

Warn when no timestmap

Lack of a timestamp is a ticking time bomb. We should print a warning if there is effectively no timestamp specified.

NetCoreApp 2.0

Consider switching to netcoreapp-2.0 with a win-64 RID.

We'll be able to move faster on pinvoke improvements.

Signing VSTO app/deployment manifests?

I'm not sure if this is a feature request for AzureSignTool or just a cry for help but I'll give it a shot :)
I've been using AzureSignTool for a while now as part of several build pipelines on Azure DevOps and it's been a godsend - it's the only way we can sign our code on DevOps since our CA won't trust us with the public key for our own certificate. Just starting a new project though and it's an Office add-in (using VSTO) and it seems that as well as signing the actual code, we need to sign some XML manifest files as well. Optimistically, I tried using AzureSignTool to sign one of these files and I got output like this:

2020-03-25T18:21:32.3888927Z trce: AzureSignTool.Program[0]
2020-03-25T18:21:32.3889918Z       Retrieving certificate <certificate name>.
2020-03-25T18:21:33.0607022Z trce: AzureSignTool.Program[0]
2020-03-25T18:21:33.0607786Z       Acquiring access token from client id
2020-03-25T18:21:33.5904715Z trce: AzureSignTool.Program[0]
2020-03-25T18:21:33.5905521Z       Acquired access token from client id
2020-03-25T18:21:34.0793425Z trce: AzureSignTool.Program[0]
2020-03-25T18:21:34.0794051Z       Retrieved certificate <certificate name>.
2020-03-25T18:21:34.0849915Z trce: AzureSignTool.Program[0]
2020-03-25T18:21:34.0850413Z       Creating context
2020-03-25T18:21:34.8703934Z info: AzureSignTool.Program[0]
2020-03-25T18:21:34.8704563Z       => File: filename.vsto
2020-03-25T18:21:34.8704821Z       Signing file filename.vsto
2020-03-25T18:21:34.8783099Z trce: AzureSignTool.Program[0]
2020-03-25T18:21:34.8783729Z       => File: filename.vsto
2020-03-25T18:21:34.8784259Z       Getting SIP Data
2020-03-25T18:21:34.8800826Z trce: AzureSignTool.Program[0]
2020-03-25T18:21:34.8801738Z       => File: filename.vsto
2020-03-25T18:21:34.8802472Z       Calling SignerSignEx3
2020-03-25T18:21:34.8969190Z fail: AzureSignTool.Program[0]
2020-03-25T18:21:34.8970955Z       => File: filename.vsto
2020-03-25T18:21:34.8971318Z       Signing failed with error 800B0003 for file filename.vsto
2020-03-25T18:21:34.8971618Z info: AzureSignTool.Program[0]
2020-03-25T18:21:34.8971884Z       => File: filename.vsto
2020-03-25T18:21:34.8972114Z       Stopping file signing.
2020-03-25T18:21:34.8982315Z info: AzureSignTool.Program[0]
2020-03-25T18:21:34.8982903Z       Successful operations: 0
2020-03-25T18:21:34.8983581Z info: AzureSignTool.Program[0]
2020-03-25T18:21:34.8984039Z       Failed operations: 1

I found issue #60 so I at least know that the error code probably means there's no SIP for this type of file, but I'm not sure where to go next with this. Any ideas?

error 80190194

Everything was working fine until about 6 hours ago and now signing is failing with error 80190194. I have not changed anything in my code or on Azure. I have tried with multiple different certs, both standard certs and EV certs. Same error keeps happening.

I'm trying to identify if this is an issue on Azure but the error message is not very helpful. Is there a way to get more info about the error?

The logs look like this:

    // everything looks good before this
    trce: AzureSignTool.Program[0]
          => File: C:/{snip}.exe
          Acquired access token from client id
    fail: AzureSignTool.Program[0]
          => File: C:/{snip}.exe
          Signing failed with error 80190194 for file C:/{snip}.exe.
    info: AzureSignTool.Program[0]
          => File: C:/{snip}.exe
          Stopping file signing.
    info: AzureSignTool.Program[0]
          Successful operations: 0
    info: AzureSignTool.Program[0]
          Failed operations: 1

Unable to find certificate -- not sure where I'm going wrong

Hi! Firstly, thank you for this tool. Secondly, this is a low priority issue, and I'm 98% sure it's my fault, so if you happen to be able to point me in the right direction, I'd appreciate it.

Background / Goal

I recently bit the bullet got an Authenticode cert to sign an office add-in I want to publish.

Goals:

• Use AzureSignTool within an AzureDevOps pipeline to sign the setup.exe file produced by my build process.
• Double-check that this is "enough" in this case.

What I've Done

• Obtained the cert
• Uploaded the cert into an Azure KeyVault I created
• Registered an app in my Azure AD
• Granted the app access to the Azure KeyVault
• Used the app ID as my client ID and a generated client secret as my secret.
• Installed AzureSignTool as a global tool within my pipeline steps:

- task: DotNetCoreCLI@2
  inputs:
    command: 'custom'
    custom: 'tool'
    arguments: 'install --global azuresigntool'
  displayName: Install AzureSignTool

• Called the AzureSignTool from the command line (info redacted);

- task: CmdLine@2
  displayName: 'Sign outputted .exe with AzureSignTool'
  inputs:
    script: "AzureSignTool.exe sign -du 'https://killeencode.com' -kvu 'https://[REDACTED].vault.azure.net' -kvi '[REDACTED]' -kvs '[REDACTED]' -kvc '[REDACTED]' -v setup.exe"
    workingDirectory: '$(Build.ArtifactStagingDirectory)'

The Problem

No matter what, AzureSignTool appears unable to find the cert:

trce: AzureSignTool.Program[0]
      Retrieving certificate '[REDACTED]'.
fail: AzureSignTool.Program[0]
      Failed to retrieve certificate '[REDACTED]' from Azure Key Vault. Please verify the name of the certificate and the permissions to the certificate.
info: AzureSignTool.Program[0]
      Failed to get configuration from Azure Key Vault.
##[error]Cmd.exe exited with code '-2147024809'.

What I've confirmed (or so I think)

• The KeyVault URL is correct -- copied it directly from portal
• The application ID from my Azure AD app registration is being used as the input to -kvi
• The client secret for my application in AD is being used as the input to -kvs
• The cert name is correct (copied from keyvault in portal)
• The application's service principal has permissions on the key vault (Owner for now)
• In the KeyVault's access policy, the application's service principal has every single permission (for now, to remove this as a variable)

Things I think it could be

The DevOps pipeline is under a different account than the azure subscription, and thus a different directory. I am wondering if the DevOps pipeline isn't able to access the keyvault across subscriptions? Although with the client ID and secret, I thought that'd be mitigated.

Any insight into what it could be would be greatly appreciated; I'm somewhat new to this and I've exhausted the other resources I'm aware of. Hoping someone with more experience here can spot it quickly,

1.0

Create a signed 1.0 release. I think this is 1.0 quality.

Question/Issues with using AzureSignTool with Azure Key Vault Private Endpoints

Hey There,

First off, I want to thank you guys for Azure Sign Tool. I'm new to this, but I really like it! It works well and it seems to fit the bill for our HSM EV Code signing needs akin to #112.

• I'm trying to leverage a Private endpoint connection for my key vault.

• I go through the above documentation, setting up the Private endpoint immediately after I create the vault. I've gone through the setup guide, registering my application in AD as mentioned here.

• If I run AzureSignTool like so, it works fine

AzureSignTool sign -du "https://<my website>/" ^
-kvu "https://signingadventure2.vault.azure.net/" ^
-kvi "[REDACTED_APPLICATION_ID]" ^
-kvs "[REDACTED_APPLICATION_CLIENT_SECRET]" ^
-kvc "anothercert" ^
-v "VersionSelector.exe"

However, when I run the same command with the private link (see below)for the Vault Id, I receive the error

trce: AzureSignTool.Program[0]
      Retrieving certificate anothercert.
fail: AzureSignTool.Program[0]
      Failed to retrieve certificate anothercert from Azure Key Vault. Please verify the name of the certificate and the permissions to the certificate.
info: AzureSignTool.Program[0]
      Failed to get configuration from Azure Key Vault.

Command Run.

AzureSignTool sign -du "https://<my website>/" ^
-kvu "https://signingadventure2.privatelink.vaultcore.azure.net" ^
-kvi "[REDACTED_APPLICATION_ID]" ^
-kvs "[REDACTED_APPLICATION_CLIENT_SECRET]" ^
-kvc "anothercert" ^
-v "VersionSelector.exe"

The Private Endpoint seems to be setup correctly. Private DNS is enabled using Azure's privatelink.vaultcore.azure.net
Specifically, this looks good. I can also access the page when inside the Virtual Network.

C:\Users\shermanericdemo\Desktop>nslookup signingadventure2.privatelink.vaultcore.azure.net
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
Name:    signingadventure2.privatelink.vaultcore.azure.net
Address:  10.1.1.8

There's probably something silly I'm doing wrong on my end, but haven't stumbled upon it yet and was wondering if anyone here had success with using Azure Sign Tool and Private Endpoint connections with Azure Key Vault.

Thanks in advance!

Add support for Windows Server 2012

Hi,

Thanks for making such a great tool! Unfortunately, I have a hard dependency on using server 2012 for some builds and cannot use this tool as it works on 2016 onwards. Are there any workarounds/libs I can install to make it work?

Determine feasibility of Sealing and ITOS.

Windows SDK signtool supports sealing. We should investigate if it's worth bringing to AzureSignTool.

Strong Name Sign

(Writing for information tracking purposes)

Strong naming this project solves an interesting performance problem on Azure App Services. We may be able to remove it later, but it appears to help with an ngen issue for framework libraries.

Accept multiple files as input

When signing a lot of files, it could be beneficial to pass them all into signtool. Perhaps as an input file with one file per line?

An option can specify the max concurrency so signing can be done in parallel.

Benefits: Getting access tokens/certificate operations would be amortized for all files in the batch instead of for each file.

Add Support for Certificate Authentication

For use cases where a managed identity is not possible, using a certificate thumbprint where the certificate is stored in a local HSM, TPM, or smartcard provides significantly more security than a shared secret.

It would seem the underlying APIs support this, is it possible to add the functionality?

--azure-key-vault-tenant (-kvt) isn't required

If you add -kvt or --azure-key-vault-tenant nothing will happen when you try to sign the file, if you remove the tenant argument it signs fine.

Only way I found this is because the azuresigntool sign --help doesn't list an option for key vault tenant so I would assume the README.md doco is out of date.

AzureSignTool cannot sign binary files

When using device guard, the policy file format is "p7b". The SDK Signtool can sign it when the option /p7co is used. The command below works for sdk signtool:
signtool sign /p7 /p7co 0 /f my.pfx /p /a myfile.p7b

But using Azuresigntool there is not an equivalent and when signing without p7co option I got the error below:

An example of a policy can be found in the attached zip:

SIPolicy.zip

Add/verify support for signing dtrace scripts

https://techcommunity.microsoft.com/t5/Windows-Kernel-Internals/DTrace-on-Windows/ba-p/362902

Trying to get more details, but the blog post indicates it's done similar to PowerShell, so I assume it's a SIP somewhere. Might already work if you have the right SIP installed. Otherwise, might need local updates.

Investigate better error output when HTTP requests fail

When the signing process fails because the timestamp server could not be reached, an arcane error message is printed (but the file is actually signed!) and counted as a failure.

We should make it clear that the operation was still successful, and handle the error message better.

Allow specifying additional certificates

AKV doesn't allow you to store a full chain of certs. We should allow specifying additional certificates to aid in building a full chain.

Right now AST will make a best effort for chain building. I'm not clear if that does AIA fetching. Popular CAs won't have this problem, but I imagine a smaller one might.

SignTool also has an option for this. We should match the CLI arg.

Need to doc Managed Identity usage

Now that Managed Identities are supported, the readme needs updates with the new parameters.

Verbosity

We have log levels now. Verbose could probably be more useful.

Unit Tests

Now that the mystery of PlatformTarget is solved, we can write tests!

GitHub release action

Need to tag, build, and push on releases.

Insufficient error details in KeyVaultConfigurationDiscoverer.Materialize

Found that the 'Failed to retrieve certificate..' error logged is not verbose enough. Reporting the actual exception message was helpful to diagnose the failure (host name not found caused by an incorrect vault URL).

I suggest the exception message (including a stack trace, if possible) is reported.

README.md is out of sync with current state of your project

Your last release appears to have completely dropped the EXE implementation and gone with a Nuget "global tool" version. Your README still mentions the EXE as if it were the only way to access. Someone downloading your latest package and attempting to use your README (which is, by the way, the only documentation I have been able to find) will be greatly confused.

Better error output

In #60 it was reported that "SignFile returning code -2146762749".

Giving back raw HRESULTs as an integer isn't helpful. We should make some changes so that the cause of a failure is more obvious.

1. Change SignFile to return an enum. The enum will contain possible HRESULTs that are common scenarios that should be expected (TRUST_E_SUBJECT_FORM_UNKNOWN is common enough that Microsoft's signtool handles it specially and prints out a helpful error message).

2. For cases where the HRESULT is not in the enum, it will be a "nameless" enumeration value since values can be cast to enums that don't have a label for that value.

3. Have the CLI handle possible enum values and give more helpful error messages.

4. Send this downstream to SignService so that it logs the enum better.

Appx/AppxBundle support

Might be worth spelling out what's required for appx/appxbundles. I think files from the Windows SDK directory need to be in the same directory (possibly the wintrust.dll/wintrust.dll.ini) as this tool along with some of the Opc dll's. I know it needs some of the exe's in there too.

I can play with this later this week.

Signing fails with 80072EE2 error

Randomly, signing fails with an error:
trce: AzureSignTool.Program[0] Retrieving certificate certName. trce: AzureSignTool.Program[0] Retrieved certificate certName. trce: AzureSignTool.Program[0] Creating context info: AzureSignTool.Program[0] => File: F:\agent1\_work\3\a\publish\fileName.exe Signing file F:\agent1\_work\3\a\publish\fileName.exe trce: AzureSignTool.Program[0] => File: F:\agent1\_work\3\a\publish\fileName.exe Getting SIP Data trce: AzureSignTool.Program[0] => File: F:\agent1\_work\3\a\publish\fileName.exe Calling SignerSignEx3 fail: AzureSignTool.Program[0] => File: F:\agent1\_work\3\a\publish\fileName.exe Signing failed with error 80072EE2 for file F:\agent1\_work\3\a\publish\fileName.exe. info: AzureSignTool.Program[0] => File: F:\agent1\_work\3\a\publish\fileName.exe Stopping file signing. info: AzureSignTool.Program[0] Successful operations: 0 info: AzureSignTool.Program[0] Failed operations: 1
It can happen either for dll or exe files.
Simple retry does not help. Sometimes it works normally after the machine restart.

Support for HSM stored certificates?

It seems that if one wants to have their certificate stored on an HSM (a requirement for EV code signing certs for DigiCert), it needs to be stored as a Key in the KeyVault.

https://docs.microsoft.com/en-us/azure/key-vault/general/about-keys-secrets-certificates#object-types

Are there any plans to support signing from certficates stored in HSMs?