- Setting up SignPath
- Distribution of roles
- Using SignPath
Setting up SignPath
The following table separates steps between two roles:
- Administrator: has control over your SignPath organization, but does not necessarily know how the development team works.
- Development: people who know the details of your development process, but don't necessarily have administrative privileges in SignPath.
See also: Distribution of roles
|Create an organization||Administrator||
Register for a free trial or paid subscription!
|Create or import certificates||Administrator||
You will need at least two certificates:
|Create user accounts||Administrator||
Set up your team:
Identify projects that need to be signed, restrict their content and define which elements need signing.
|Create signing policies||Administrator||
For each project
|Integrate into CI builds||Development||
Use our PowerShell module or call our API for automatically submitting signing requests to SignPath. See build system integration.
|Disable old certificates||Administrator||
When everything is working, consider revoking existing unsafe certificates via your CA. (Signatures of properly time stamped code will still be valid.)
See key concepts for details about projects and signing policies.
Distribution of roles
SignPath is designed to make sure that people in charge of security have full control over code signing. Therefore, it makes sense to assign the role of organization administrator to security persons, such as InfoSec officers. It is also possible to assign administrative privileges to people in the development team. This can be on a permanent basis, or only temporarily to speed up initial setup. You can go with a model where every change has to be implemented by a dedicated administrator, or you can decentralize administration and have InfoSec review change audit logs regularly. Use the model that works best for your organization.
If you aim for the highest security, we recommend assigning the administrator role only to InfoSec staff and have them working directly with the development teams.
There are two ways for submitting signing requests:
- Use the Web application to submit artifacts for signing
- Go to the application dashboard
- Select a project and signing policy
- Upload a file
- Use the PowerShell module or call our API
In any case, you will receive e-mail notifications for your request and be able to monitor them in the Web application.
Approving signing requests
For signing policies that require approval, each approver will receive an e-mail notification whenever an approval is requested. Approvers will also see signing request waiting for their approval in the application dashboard.
Administrators will be notified about important events. They can also use the Web application to see a full activity audit for each entity, including users, certificates, projects, signing policies and signing requests.