Build system integration

PowerShell Gallery


This section describes how SignPath can be integrated into automated builds using continuous integration software. You can use the PowerShell module provided by SignPath, directly call the Web API to submit signing requests, or integrate SignPath as part of your AppVeyor build step.

Information Locating ID values

All necessary IDs can be found on the signing policy details page, including a code snippet that calls the PowerShell module.


Before accessing the API, you have to create a CI User in the User section of the SignPath application.

The API token is displayed when a new CI user is created. (If you lose the API key, you will need to generate a new one.)

Make sure to keep the access token in a secure location. Most Continuous Integration (CI) systems provides a mechanism to store secrets, which is usually the best place to keep API tokens. If you use several distinct systems for API access, we recommend that you create individual CI User accounts in SignPath.


SignPath can be integrated in your automated build process by using our API. For convenience, we provide a PowerShell module that can be used from within your build/deploy chain. The module can be downloaded from PowerShell Gallery.

Signing requests can be created by calling the following commands via PowerShell:

Install-Module -Name SignPath

# Submit a signing request and get a signing request ID without waiting for completion ...
$signingRequestID = Submit-SigningRequest
    -CIUserToken $CI_USER_TOKEN
    -OrganizationId $YOUR_ORGANIZATION_ID
    -ProjectKey $YOUR_PROJECT_KEY
    -SigningPolicyKey $YOUR_SIGNING_POLICY_KEY
    -InputArtifactPath $PATH_TO_INPUT_ARTIFACT

# ... and download the signed artifact later.
    -CIUserToken $CI_USER_TOKEN
    -OrganizationId $YOUR_ORGANIZATION_ID
    -SigningRequestId $signingRequestID
    -OutputArtifactPath $PATH_TO_OUTPUT_ARTIFACT

# Or submit a signing request and wait for completion.
    -CIUserToken $CI_USER_TOKEN
    -OrganizationId $YOUR_ORGANIZATION_ID
    -ProjectKey $YOUR_PROJECT_KEY
    -SigningPolicyKey $YOUR_SIGNING_POLICY_KEY
    -InputArtifactPath $PATH_TO_INPUT_ARTIFACT
    -OutputArtifactPath $PATH_TO_OUTPUT_ARTIFACT


In case the PowerShell module is not sufficient, you can communicate directly with our API by calling our public HTTP REST endpoints.

Base URL and authentication uses bearer authentication.

Common API arguments
Base URL
Authorization HTTP header field Authorization: Bearer <token>

You need to provide these values for every single API request.

Submit a signing request

URL /SigningRequests
Method POST
Encoding multipart/form-data
SigningPolicyId Signing policy for which you want to create the signing request
Artifact Artifact file
Description Optional description for your signing request (e.g. version number)


curl -H "Authorization: Bearer $CI_USER_TOKEN" 
     -F "ProjectKey=$YOUR_PROJECT_KEY" 
     -F "SigningPolicyKey=test-signing" 
     -F "Artifact=@$PATH_TO_ARTIFACT" 
     -F "Description=$DESCRIPTION"$ORGANIZATION_ID/SigningRequests

Success result: HTTP status code 201. A HTTP Location response-header field is returned with the URL of the created entity.

Check the status of a signing request

URL /SigningRequests/id
(Location response-header field from /SigningRequests)
Method GET
Parameters none


curl -H "Authorization: Bearer $CI_USER_TOKEN"$ORGANIZATION_ID/SigningRequest/$SIGNING_REQUEST_ID

Success result: HTTP status code 200. Status of the signing request in JSON format:

  "description":"Called by curl",
  "projectName":"Test project",

Possible status values: WaitingForApproval, QueuedForProcessing, Processing, Completed, Failed, Denied, Canceled, RetrievingArtifact, ArtifactRetrievalFailed

Download the signed artifact

Once the signing request has been successfully completed, the status response contains a signedArtifactLink field with a link to the signed artifact file. It can easily be retrieved by issuing the following command:

URL /SigningRequests/id/SignedArtifact
(signedArtifactLink field from GET SigningRequests/id)
Method GET
Parameters none


curl -H "Authorization: Bearer $CI_USER_TOKEN" 

Success result: HTTP status code 200. Returns the binary content of the signed artifact.


If you are using the CI service AppVeyor, there is an alternative CI integration. Instead of pushing the artifact from your build script, you can issue an AppVeyor notification after your build, and will pull the artifact from AppVeyor. This results in additional confidence and provides the foundation for restricted Open Source signing.


By pulling the artifact from AppVeyor, can make sure that the binary artifact is a result of a specific build process applied to specific source code (branch and commit).

Prerequisites and restrictions

This feature is a proof-of-concept for Open Source projects. Future versions may allow disabling certain limitations in paid subscriptions.

Current limitations:

  • The AppVeyor project and the Git repository must be public on one of the following hosting services:
    • GitHub
    • GitLab
    • Bitbucket

These are verified in order to guarantee that the binary results from the specified source code:

  • No additional scripts may be executed during the build step and no cache entries may be used (so that the build remains fully traceable and is only built from the repository)
  • The build settings must not be modified between starting the AppVeyor build and calling

Build documentation

In order to enable independent verification of builds, SignPath performs the following actions:

  • For NuGet packages: 1 The build settings are stored in an AppVeyorSettings.json file in the root of the NuGet package 2 The commit hash and repository URL are written to the metadata of the NuGet package

These steps allow consumers of the signed artifact to confidently link the it to a specific source code version and build settings.


This shows the secrets that need to be shared between and AppVeyor Setup flow

Action Remarks Step by step
Add an AppVeyor integration to a SignPath project must authenticate against Appveyor to retrieve the build artifacts
  1. On, select My Profile and API Keys, then remember the Bearer token for the next step
  2. On, add an AppVeyor integration to your project and enter the API key you just acquired
Encrypt the SignPath API token in AppVeyor AppVeyor lets you encrypt secret values. You can then safely use the encrypted string in your appveyor.yaml file
  1. On, choose the Users menu and create a new CI User or open an existing one
  2. Remember the SignPath API token for the next step
  3. On, open Account Settings and choose Encrypt YAML
  4. Enter "Bearer <SignPath API token>" (without quotes)
  5. Remember the encrypted SignPath API token for the next step
Add a deploy Webhook Append this to your appveyor.yaml file:
- provider: Webhook

Replace the parameters:

  • <ORGANIZATION_ID>, <PROJECT_KEY> and <SIGNING_POLICY_KEY> values can be retrieved from the Signing policy page
  • <ENCRYPTED_ACCESS_TOKEN> is the value from the previous step

Azure DevOps

For Azure DevOps you can use build pipeline tasks from the official extension on the marketplace. These tasks will provide an integrated experience in calling the PowerShell module.