- Creating certificates
- Installing certificates
If you are using a free trial subscription, you also need to download and install our timestamp certificate for signature verification. Don’t forget to uninstall the certificate after the trial period.
For paid and Open Source subscriptions, this is not necessary.
Test certificates can be used to sign development builds that are not going to be distributed to your users or customers. You can read how to create test certificates in SignPath in the user guide In order to ensure your artifacts behave the same way during installation even though they are not signed by commercial CA you need to trust the certificate on the computers you use for testing. There are some options when managing test certificates:
- You can either create self-signed certificate or create them using an in-house CA.
- You can roll out the certificate by installing them manually or by using automated processes.
You have two options to create certificates:
Self-signed certificates can be created right from within SignPath and don’t require an additional setup of tools and infrastructure. The disadvantage is that you cannot revoke the certificate, but have to remove it from each computer if it was misused.
To use an in-house CA, you can create a certificate signing request (CSR) in SignPath and use your in-house CA (e.g. Microsoft Active Directory Certificate Services or OpenSSL) to issue the test certificate. The certificate can then be imported into SignPath. By using an in-house CA, you have one controlled instance for your public key infrastructure (PKI) and a straight-forward revocation process, in case the certificate has been misused.
Certificates can be rolled out to your test computers manually or using an automated process. You should generally add self-signed test certificates to the
Trusted Root Certification Authorities certificate store of computers you use for testing your software. If you do this, Windows will treat your test certificates as if they were issued by a trusted Root CA.
You may also add your test certificates to the
Trusted Publishers store on internal machines. This is what happens when a user choses to always trust this publisher during installation, and therefore results in the same behavior, so don’t do this if you want to replicate the default behavior on user machines.
Adding a certificate to this store will affect User Account Control (UAC) device driver installation prompts as well as whitelisting features such as Software Restriction Policies (SRP), AppLocker and WDAC Code Integrity Policies.
Only add your certificates to this store for computers in your own organization, don’t use your installer to add your certificate to this store.
On Windows, you can install certificates by following these steps:
- Open the certificate in Windows Explorer
- For certificate file: select Open.
- For signed files: select Properties from the context menu, go to the Digital Signatures tab, open a signature (Details) and select View Certificate.
- In the certificate property window, click Install Certificate…
- Select Current User or Local Machine location
- Select the Trusted Root Certification Authorities store
Using scripts and batch files
- In PowerShell scripts, use
Import-Certificate $certificate_file -CertStoreLocation Cert:\LocalMachine\Root
- In batch files, use
CertUtil -addstore Root <certificate-file>
These commands require administrative permissions.
Use Group Policy Objects (GPOs) to add certificates to computers.
- In order to trust a certificate, create a GPO for
Public Key Policies/Trusted Root Certification Authorities
- In order to explicitly un-trust a certificate, create a GPO for
Public Key Policies/Untrusted Certificates