Documentation  ❯  Signing Code


Once your project is set up, you can submit a signing request by either

  • Uploading an artifact on the web interface
  • Integrating a call to SignPath in your build process
  • Resubmitting an existing signing request

Direct upload

For testing purposes or when you have very infrequent releases, you can choose to simply upload the binary artifact via the web interface.

Build process integration

We recommend that you integrate SignPath in your automatic CI pipeline. This has several advantages besides just saving tedious work:

  • Elimination of error-prone routine activities provides additional security
  • Automatic propagation of metadata, such as version numbers, source code version and build
  • Origin verification ensures that the signed binary conforms to a specific source code version

SignPath provides multiple ways to be integrated into your pipeline. See the documentation for details including information about origin verification.

Resubmitting an existing signing request

Available for Enterprise subscriptions

You can resubmit an existing signing request and specify a different signing policy. This is especially useful when you build a release candidate, and want to postpone the release decision until later.

When compared to just submitting the same artifact again, the new resubmit feature has the following advantages:

  • The exact same artifact is being signed that was used for testing
  • Any verified origin information is still available
  • The original signing request is referenced

Resubmit via user interface

To resubmit a completed signing request, click the Resubmit signing request button on its details page.

Required permissions: This button is only visible for users with permission to submit a signing request for any of the project’s signing policies.

Resubmit via API

This feature is available via the REST API and PowerShell module.


Parameter Value
Signing Policy required
Description optional
all other copied from original signing request

Permissions and policies

  • Permissions and origin verfication are evaluated according to the new signing policy.
  • Origin verifcation is evaluated based on the original signing request’s origin data.

This ensures that the integrity of the signing request and artifact are preserved even when fully detached from the actual build process.

Usage scenario

A typical release scenarios would look like this:

Step Actor Condition Action
1 CI system   A release candidate is built and submitted for test-signing.
2 SignPath test-signing policy The release candidate is signed using the test certificate.
3 CI system or test tool   The release candidate is tested. Consider trusting the test certificate on test systems.
4 CI system or test tool tests passing A resubmit request is created for release-signing.
5 SignPath release-signing policy Project manager is notified about pending approval.
6 Project manager arbitrary Approves or denies based on test results and verified origin data from step 2.
7 SignPath approval The release candidate is signed using the release certificate.

Instead of manual approval using SigmPath (steps 5 and 6), a release management or workflow system might be used to submit the re-signing request and/or provide the approval using SignPath REST APIs.

Sign up for news and special offers