How build machines and scripts prove who they are to CodeSign Secure, and how to manage those credentials safely.
Every signing client uses two credentials together:
An authentication certificate (PFX/P12 file and its password). The client presents it during the TLS handshake. This is mutual TLS.
API user credentials: a username, a code or passcode, and identity type 1. The client exchanges them for a token.
The server then checks the user’s role permissions and team mapping before it signs anything. See How a signing request flows.
| Credential | Created in | Used by |
|---|---|---|
| Authentication certificate (.pfx) and password | System Setup > User > Generate Authentication Certificate: select the user, enter a Certificate Name and a Valid Till date | Every signing client |
| Registered username | The CodeSign Secure user the client signs as | Every signing client and API script |
| Code or passcode | The CodeSign Secure activation code set during setup. The KSP asks for it as Code during installation; the PKCS#11 Wrapper reads it from passcode in its INI file. | KSP, PKCS#11 Wrapper and API scripts |
| Token | Created automatically with default expiry.For custom expiry, go to System Setup > User > Generate API Key: an API Key Name and an expiry of 30, 60, or 90 days | Non-interactive authentication for client machines and automated signing |
| Client | Authentication certificate | API user credentials |
|---|---|---|
| Windows KSP | Environment variables EC_Client_Auth (path to the PFX) and EC_Client_Pass (its password) | Entered in the installer: Username, Code, Identity Type 1, API Base URL https://<your domain>/api/(Can be updated from Registry Editor settings, for example, Computer\HKEY_CURRENT_USER\Software\Encryption Consulting\SigningKSP) |
| PKCS#11 Wrapper | [pfxfile_path] and [pfxfile_passwd] in ec_pkcs11client.ini | [login_token] username and passcode in the same file |
| EC KSP for Mac | See Apple Signing | See Apple Signing |
| Utility Tool | See Utility Tool | The server address is set with BASEURL in the tool’s configuration file |
| Stage | What to do |
|---|---|
| Issue | Generate one authentication certificate per build machine or pipeline. Download it once and store it in a secret store. |
| Renew | Before the Valid Till date, generate a new certificate, update EC_Client_Auth and EC_Client_Pass or the INI file, restart build agents so they pick up the change, and test a signing. |
| Rotate | Change passcodes and API keys on a schedule and whenever someone who knew them leaves. |
| Respond to exposure | If a PFX file, password or passcode is exposed, lock the user in System Setup > User until new credentials are issued, then review the Audit Trail for signing you didn’t expect. |
Allow only the build service account to read credential files.
# Windows (run as Administrator)
icacls C:\EC\AuthCert.pfx /inheritance:r /grant:r "Administrators:F" "<DOMAIN>\<build-service-account>:R"
# Linux and macOS
chmod 600 /opt/ec/AuthCert.pfx /opt/ec/ec_pkcs11client.ini
chown <build-user> /opt/ec/AuthCert.pfx /opt/ec/ec_pkcs11client.ini
Keep credential files outside source code folders so they can’t be committed by accident.
Use a dedicated API user for automation rather than a person’s account. Signing in again with the same account revokes that account’s earlier portal sessions.
In CI/CD, inject credentials at run time from the platform’s secret store. See Securing CI/CD credentials.