- Signing methods and file types
- Artifact configuration
- Policy enforcement
This page explains how the quotas and features of all SignPath Editions.
Code signing certificates
What is the advantage of Extended Validation (EV) code signing certificates?
EV certificates are considered more trustworthy because they
- they require stricter identity checks by the certificate authority (CA)
- are only issued on secure hardware (USB token or HSM)
For non-EV certificates, Windows will warn users about new and newly re-issued certificates.
This does not happen with EV certificates, since they start with full reputation for Microsoft SmartScreen. You will also need EV certificates to sign Windows drivers.
What are test certificates used for?
You may create any number of self-signed test certificates and assign them to signing policies. These are used for test-signing your projects.
Test-signing is used to avoid the security implications of release-signing with EV certificates, which
- to test your signing configuration (especially artifact configurations) without the (which would be )
Starter and Basic subscriptions are priced based on the number of projects you can create in SignPath. Choose the number of projects you need when you buy your subscription, or upgrade later. If you need more than max. projects, you need to upgrade to another the subscription type.
We recommend to use one SignPath project for each actual software project.
If your project produces several artifacts, you have these options to handle them with a single SignPath project:
- Use deep signing: Sign an installer and the files it contains
- Package your artifacts into a ZIP archive: Sign all artifacts that result from a single build job in one step
- Use multiple artifact configurations within one project (not available for Starter subscriptions)
Starter and Basic subscriptions are priced based on the number of active user accounts. Choose the number of users you need when you buy your subscription, or upgrade later. If you need more than max. users, you need to upgrade to another subscription type.
User accounts are required for all interactions with the SignPath user interface, including
- manual upload and approval of signing requests
- administration of your SignPath organization and projects
- checking the status of signing requests
- creating reports
- receiving notifications
This quota does not limit the number of CI user accounts or build agents you can use.
Starter and Basic subscriptions have an upper limit for the number of signing requests per year and project.
|release-signing||Extended Validation (EV) release certificate||20||50|
|test-signing||Self-signed test certificate||100||250|
So for instance, a Basic subscription with 3 projects allows you to complete
- 150 release-signing requests per year (50 × 3)
- 750 test-signing requests per year (250 × 3)
The signing requests quota can be used freely between projects. You may upgrade the available projects of your subscription to get more signing requests per year.
Depending on your artifact configuration, each signing request may contain multiple files for signing.
Fair use quota: You may sign up to 100 files per available signing request (i.e. the sum of release- and test-signing requests ). In the example above, that would be (150 + 750) × 100 = 90,000 files per year.
Starter subscriptions: one CI pipeline at a time.
Basic subscriptions: one CI pipeline per available project at a time.
Additional signing requests submitted from CI pipelines may be rejected and have to be repeated later.
Signing methods and file types
See artifact configurations for details about available signing methods and file types.
Artifact configurations define what artifacts to sign and how. They can either simply define the file type, or they can be detailed specifications of complex artifacts that contain other (nested) artifacts. See setting up projects for details.
Sign installers, packages etc. and their content in a single step. See signing nested artifacts
Create multiple artifact configurations for
- projects that create different artifact at different times, but you want to use the same signing policies
- artifact configurations that change significantly over time (versioning)
Starter subscriptions can only have one artifact configuration per project.
Some file attributes can be restricted.
This is useful if you want to
- enforce metadata policies (signed binaries must use consistent publisher metadata)
- avoid unintentional signing of third-party components
- defend against unauthorized signing (while this can be circumvented by aware parties, the attempt is reported and can be investigated)
Metadata constraints are only available for Enterprise subscriptions.
You can define parameters for each signing request.
Use this to
- create more restrictive artifact configurations
- track arbitrary values across signing requests
- include build-time values
Specify that one or more approvals are required before a signing request is processed.
This is typically used for release-signing. Note that origin verification allows to create secure signing policies without manual approval.
- Starter subscriptions do not provide manual approval.
- With Basic subscriptions, you can specify a list of approvers, and any of them may approve.
- With Enterprise subscriptions, you mal also specify that at least k approvals are required (quorum or k-out-of-n approval).
See approval process for more information.
Signing policies per project
For Starter and Basic subscriptions, you get two signing policies per project:
- a test-signing policy for testing the signing configuration and signing test builds
- a release-signing policy for signing builds that will be delivered to end users
Enterprise subscriptions allow to define any number of singing policies per project. You can use this to create policies with different levels of manual and automatic verification.
- test signing without verification, using a test certificate
- pre-release signing with origin verification, using a certificate that is recognized by QA devices
- release signing with origin verification and a constraint on release branches only
- exception release signing with origin verification, no branch constraints, but manual approval instead
- emergency signing without origin verification, but manual approval with 3 required approvals
When a CI build is submitted to SignPath, certain metadata will be retrieved and verified by SignPath. This includes
- source code repository
- repository branch
- source code commit
- build information
Verification ensures that a person or system with knowledge of the CI user token cannot simply submit an unauthorized signing request.
Origin verification enables the most advanced level of code signing security. Even without origin verification, SignPath prevents many attack vectors using a combination of authentication and permissions, artifact configurations and constraints, malware scanning, notifications, and auditing. However, as soon as somebody gets access to the CI user token, security cannot be guaranteed.
Origin verification traces a software build back to the original source code, making it virtually impossible to sign unauthorized code.
For full security, make sure
- that the source code repository is the single source of truth for software builds, including build scripts and CI configurations
- that all upstream components are signed by their publishers, and signatures are verified
- that your repository and CI infrastructure is secure
Available for Enterprise subscriptions.
Specify the source code repository for a SignPath project, and (optionally) the branch name(s) for a signing policy. This ensures that only software from legitimate builds of these repositories can be signed using this policy.
Manual origin verification
When using manual approval on top of origin verification, approvers will have reliable information to base their decisions on. Also, they can be sure that builds will not even be presented for approval if they don’t meet the policy requirements.
For some CI systems, SignPath offers connectors that can validate software builds for security. This ensures that development teams do not use or enable inherently insecure mechanisms in their release build configurations. Insecure practices include caching on build nodes, interactive access to build nodes, ad-hoc build configuration changes and more.
Specify that certain validation criteria must be enabled for specific certificates. This enforces these policies for all projects end their respective signing policies.
Available for Enterprise subscriptions. See managing certificates.