Validate device identity and code signing in a private trust stack

Private device fleets can require two complementary trust controls: certificates that identify devices and private signatures that establish software provenance. This solution configures and validates both controls beneath a governed private public key infrastructure (PKI) root CA.

DigiCert® Account Manager provides the automation identity. DigiCert® Private CA provides the root trust anchor and issuing CAs. DigiCert® Device Trust Manager issues device certificates, and DigiCert® Software Trust Manager issues private code-signing certificates and signs a test hash.

The workloads share the account foundation and root trust anchor but remain operationally separate. Each workload has its own purpose-bound end-entity template and issuing-CA variable. Select two issuing CAs beneath the same root CA so each issuer can be constrained to the purpose it serves. A single issuing CA for both variables works where your PKI policy permits it, but a shared issuer cannot be constrained to one workload.

By the end, you will have

After you complete this manual, you can demonstrate that the tenant issues purpose-appropriate device and code-signing certificates and produces a verifiable private signature beneath the approved root CA. You will have:

• A service user with the roles required by the setup workflow, an API token, and a client authentication certificate.
• An active root CA certificate to distribute as the relying-party trust anchor.
• One or two active private issuing CAs assigned to your account.
• A device certificate template and a code-signing certificate template, each identified in its own product and validated against the purpose it serves. This workflow selects existing templates. It does not create them.
• A Device Trust Manager division, certificate profile, certificate policy, and device group configured for passcode-authenticated enrollment.
• A device certificate whose path validates to the private root CA.
• A Software Trust Manager keypair and private code-signing certificate, plus a signature produced over a known hash.

One integrator can complete the demo workflow. A production implementation commonly involves separate identity, PKI, device-platform, and release-security owners. Coordinate the phase outputs with those owners.

Solution architecture

The root CA certificate is the trust anchor installed in relying-party trust stores. The issuing CA signs the two types of end-entity certificates. Each product has its own certificate template and profile.

flowchart TD
    FOUNDATION["Shared foundation<br/>Setup identity: API token + client certificate<br/>Private root CA + workload issuing CA roles"]

    DEVICE["Device identity<br/>Template + profile + policy + group<br/>Passcode-authenticated enrollment"]
    SIGNING["Code signing<br/>Template + profile + keypair<br/>API token + client certificate for protected operations"]

    DEVICE_OUT["Device identity outcome<br/>Device certificate issued<br/>Key and certificate path verified"]
    SIGNING_OUT["Code-signing outcome<br/>Private signing certificate issued<br/>Certificate path and signature verified"]

    TRUST["Relying-party trust stores<br/>Approved private root required"]

    FOUNDATION -->|"device issuer + setup authentication"| DEVICE
    FOUNDATION -->|"signing issuer + setup authentication"| SIGNING
    FOUNDATION -->|"prepare root-ca.pem for distribution"| TRUST

    DEVICE --> DEVICE_OUT
    SIGNING --> SIGNING_OUT

    DEVICE_OUT -. "validates to approved root" .-> TRUST
    SIGNING_OUT -. "validates to approved root" .-> TRUST

Products and APIs

Data flow overview

When to use this manual

Use this manual when:

• Your organization needs both private device authentication certificates and private software signatures.
• Both workloads operate beneath the same approved private root and trust governance model, even when they use separate issuing CAs.
• You want to validate the cross-product configuration and cryptographic outputs in a demo tenant before integrating production systems.

If the workloads have different trust owners or require separate root CAs, implement them independently instead of treating them as one private trust stack.

Before you begin

Make sure you have:

The following table lists the required capabilities. Role response key is the Account Manager product code that groups roles in the GET /account/api/v1/role response. The created service user’s response lists role names and effective permission codes separately. Do not test a role name as though it were a permission code.

Each role selected for the other products also needs access to the target account.

Some stable API codes predate the current product names. ca_manager represents DigiCert Private CA, and secure_software_manager represents Software Trust Manager. The CM in VIEW_CM_CA and MANAGE_CM_CA_ACCOUNTS is the same legacy abbreviation for DigiCert Private CA. In the product interface, these permissions appear as View CA and Manage CA accounts.

The cURL examples provide the complete guided path. Selected steps also include Python examples. This manual uses snake_case names for values passed between phases. The cURL examples export equivalent uppercase environment variables, such as ACCOUNT_ID for account_id, while the Python examples retain snake_case. Store secrets passed between phases, such as service_api_token and enrollment_passcode, in an approved secret manager instead of a general-purpose environment file.

Every example reads and writes files by relative path, including client.crt, root-ca.pem, ca-inventory.json, and device-issuing-ca.pem. Create a dedicated directory for the validation run. Run all five phases from this directory, and keep it until you finish the workflow:

WORK_DIR="private-trust-validation-$(date +%Y%m%d-%H%M%S)"
mkdir -m 700 "${WORK_DIR}"
cd "${WORK_DIR}"
umask 077

Run each cURL block as one unit, in order, from the same shell. Selected Python tabs illustrate the corresponding API operation. When a step contains more than one Python block, keep the earlier variables in the same Python session. Replace example values and placeholders before running a block, and review its output before continuing. The umask 077 setting remains active in the current shell and restricts new files to the current user. It protects response files that can contain tokens, passcodes, and private keys.

If you resume after a pause, return to that directory before running any command.

Key concepts

Planning time

Plan for 3–5 hours in a prepared demo tenant. In addition to focused execution, this estimate includes review, environment setup, resource availability checks, wait or approval time, and validation. It excludes the lead time to establish the CA hierarchy, obtain product entitlements, provision support-managed templates, or complete production approvals.

Resume after a pause

1. Return to the working directory you used for the earlier phases.
2. Consult the implementation status and saved values table.
3. Verify the saved values and the last phase checkpoint you satisfied.
4. Re-export the environment variables the next phase needs. A new shell has none of them.
5. Resume at the first unmet checkpoint.
6. Search for existing resources before repeating any request that creates or changes a resource. A timed-out create request might have succeeded even when its response was lost.

Restore the shell environment

Each phase writes its responses to the working directory, so you can re-export the identifiers without repeating any request. Run only the blocks for phases you already completed, and retrieve the two secrets from your approved secret manager rather than from a local file.

# Secrets: retrieve from your approved secret manager.
read -rsp "Service API token: " SERVICE_API_TOKEN; echo
umask 077
export SERVICE_API_TOKEN

# Establish the account foundation.
ACCOUNT_ID="$(<account-id.txt)"
ORGANIZATION_ID="$(<organization-id.txt)"
SERVICE_USER_ID="$(<service-user-id.txt)"
API_TOKEN_ID="$(<api-token-id.txt)"
CLIENT_AUTH_CERTIFICATE_ID="$(<client-auth-certificate-id.txt)"
export ACCOUNT_ID ORGANIZATION_ID SERVICE_USER_ID API_TOKEN_ID CLIENT_AUTH_CERTIFICATE_ID

# Prepare the private trust domain.
ROOT_CA_ID="$(<root-ca-id.txt)"
DEVICE_ICA_ID="$(<device-ica-id.txt)"
SIGNING_ICA_ID="$(<signing-ica-id.txt)"
export ROOT_CA_ID DEVICE_ICA_ID SIGNING_ICA_ID

# Configure the device certificate infrastructure.
DEVICE_CERTIFICATE_TEMPLATE_ID="$(jq -er '.id' device-template.json)"
PRIMARY_RENDEZVOUS_ZONE_ID="$(<primary-rendezvous-zone-id.txt)"
DIVISION_ID="$(jq -er '.id' division.json)"
DEVICE_CERTIFICATE_PROFILE_ID="$(jq -er '.id' device-profile-response.json)"
CERTIFICATE_POLICY_ID="$(jq -er '.certificate_policy.id' certificate-policy-response.json)"
export DEVICE_CERTIFICATE_TEMPLATE_ID PRIMARY_RENDEZVOUS_ZONE_ID DIVISION_ID \
  DEVICE_CERTIFICATE_PROFILE_ID CERTIFICATE_POLICY_ID

# Enroll and verify a device.
AUTHENTICATION_POLICY_ID="$(jq -er '.id' authentication-policy-response.json)"
PASSCODE_ID="$(jq -er '.id' passcode-response.json)"
DEVICE_GROUP_ID="$(jq -er '.id' device-group.json)"
DEVICE_NAME="$(<device-name.txt)"
CERTIFICATE_REQUEST_ID="$(jq -er '.certificate_request_id' device-certificate.json)"
DEVICE_CERTIFICATE_ID="$(jq -er '.id' device-certificate.json)"
DEVICE_ID="$(<device-id.txt)"
read -rsp "Enrollment passcode: " ENROLLMENT_PASSCODE; echo
export AUTHENTICATION_POLICY_ID PASSCODE_ID DEVICE_GROUP_ID \
  DEVICE_NAME CERTIFICATE_REQUEST_ID DEVICE_CERTIFICATE_ID DEVICE_ID ENROLLMENT_PASSCODE

# Configure and test private code signing.
CODE_SIGNING_CERTIFICATE_TEMPLATE_ID="$(jq -er '.id' signing-template.json)"
SIGNING_PROFILE_ID="$(jq -er '.id' signing-profile-response.json)"
KEYPAIR_ALIAS="$(<keypair-alias.txt)"
KEYPAIR_ID="$(jq -er '.id' keypair-response.json)"
SIGNING_CERTIFICATE_ID="$(jq -er '.id' signing-certificate-response.json)"
SIGNATURE_ID="$(jq -er '.id' signing-response.json)"
export CODE_SIGNING_CERTIFICATE_TEMPLATE_ID SIGNING_PROFILE_ID KEYPAIR_ALIAS KEYPAIR_ID \
  SIGNING_CERTIFICATE_ID SIGNATURE_ID

The enrollment passcode is not recoverable from passcode-response.json. Retrieve the original value from your secret manager, or create a replacement passcode on the existing authentication policy.

Start the implementation

Establish the account foundation