---
title: "Validate device identity and code signing in a private trust stack"
description: "Configure and validate device identity and private code signing beneath a governed private root CA."
source_url: https://dev.digicert.com/solutions/private-trust-stack.html
---

# Validate device identity and code signing in a private trust stack

Configure and validate device identity and private code signing beneath a governed private root CA.

## Solution metadata

- Complexity: Advanced
- Estimated time: 3–5 hours
- Approximate API calls: 25
- Audience: Enterprise PKI integrator; DevSecOps engineer; IoT and device engineer
- Workstreams: Shared foundation (required); Device identity (required); Code signing (required)


Organizations that manage 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 capabilities 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. You can select the same issuing CA for both variables when your PKI policy permits it. For stronger separation of duties, select two issuing CAs beneath the same root CA.

## By the end, you will have

You will have evidence that the tenant can issue purpose-appropriate device and code-signing certificates and produce a verifiable private signature beneath the approved root CA:

- 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.
- Separate certificate templates for device authentication and private code signing.
- A Device Trust Manager 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.


> **Note**
>
> This workflow validates the DigiCert® ONE configuration and cryptographic outputs in a demo tenant. Production integration with device key stores, relying services, trust distribution, and artifact-specific signing systems is outside this workflow.


> **Warning**
>
> The single cross-product service user in this guide simplifies initial setup. For production, use separate identities for administrative setup, device enrollment, and software signing. Give each identity only the roles it needs, and do not use the broadly privileged setup credential in a production pipeline.


One integrator can complete the demo workflow. 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.

```mermaid
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

| Product | API specification | Role in this solution |
|---------|-------------------|-----------------------|
| Account Manager | [API reference](https://dev.digicert.com/md/account-manager-api/api-reference.md) | Identify the account and organization, find the required roles, and create the setup identity and credentials. |
| DigiCert Private CA | [API reference](https://dev.digicert.com/md/digicert-private-ca-api/api-reference.md) | Identify the root and issuing CAs, assign each issuer to the account, and download the CA certificates. |
| Device Trust Manager | [API reference](https://dev.digicert.com/md/device-trust-api/api-reference.md) | Select the device template, then create the division, certificate profile, policy, authentication configuration, and device group. Issue a device certificate. |
| Software Trust Manager | [API reference](https://dev.digicert.com/md/software-trust-api/api-reference.md) | Select the code-signing template, create a private trust certificate profile, keypair, and signing certificate, and sign a hash. |

### Data flow overview

| From | To | Data | Purpose |
|------|----|------|---------|
| Establish the account foundation | Prepare the private trust domain, configure device identity, and configure code signing | `account_id`, `organization_id`, `service_api_token` | Identify the target account and organization and authenticate setup calls. |
| Establish the account foundation | Configure and test private code signing | `client.crt`, `client.key` | Provide the second authentication factor for protected Software Trust Manager operations. |
| Prepare the private trust domain | Trust stores | `root-ca.pem` | Establish the private trust anchor. |
| Prepare the private trust domain | Configure the device certificate infrastructure | `device_ica_id`, `device-issuing-ca.pem` | Configure and verify device-certificate issuance. |
| Prepare the private trust domain | Configure and test private code signing | `signing_ica_id`, `signing-issuing-ca.pem` | Configure and verify private code-signing certificate issuance. |
| Configure the device certificate infrastructure | Device certificate profile | `device_certificate_template_id` | Apply the device certificate constraints defined in Device Trust Manager. |
| Configure and test private code signing | Software Trust Manager certificate profile | `code_signing_certificate_template_id` | Apply the code-signing constraints defined in Software Trust Manager. |
| Configure the device certificate infrastructure | Enroll and verify a device | `division_id`, `device_certificate_profile_id`, `certificate_policy_id` | Configure passcode enrollment and issue a device certificate. |

## 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:


- A DigiCert® ONE account with Account Manager, DigiCert Private CA, Device Trust Manager, and Software Trust Manager entitlements.


- An API token for a bootstrap user authorized to list accounts, organizations, and roles and to create the setup service user.


- An existing private root CA and active issuing CA. Creating or importing the CA hierarchy is a governed PKI activity outside this workflow.


- An active organization record for the private code-signing certificate subject.


- An enabled Device Trust Manager rendezvous zone assigned to the account for primary usage.


- An active custom Device Trust Manager template for RSA-2048 client authentication certificates.


- An active Software Trust Manager code-signing certificate template with `type: CUSTOM` and `template: TEST`. In hosted accounts, ask DigiCert Support to create this template before you start if it is not already available.


- Tenant roles that grant only the operations used in this guide. Find their exact names with `GET /account/api/v1/role`. Do not copy role names from another tenant.


- `curl`, `jq`, OpenSSL, and Python 3 with the `requests` package for the examples.


- A demo tenant for validation before production use.


The required capabilities are:

| Product | Required capabilities |
|---------|-----------------------|
| Account Manager | **Manage users** for the bootstrap user. Each role selected for the other products also needs access to the target account. |
| DigiCert Private CA | **View CM CA** (`VIEW_CM_CA`) and **Manage CM CA Accounts** (`MANAGE_CM_CA_ACCOUNTS`). |
| Device Trust Manager | A role that contains **Solution administrator** for the configuration workflow. |
| Software Trust Manager | **Manage certificate profiles**, **View certificate template**, **View keypair**, **Generate keypair**, **Generate certificate**, and **Sign**. |


> **Note**
>
> The examples use the US demo host `demo.one.digicert.com`. Substitute the host for your tenant and region. Software Trust Manager operations that require multi-factor authentication use `clientauth.<host>`, the service user's client certificate, and the service user's API token in the `x-api-key` header.


The guided workflow provides a complete cURL 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`, and the Python examples retain `snake_case`. Store secrets passed between phases, such as `service_api_token` and `passcode`, in an approved secret manager rather than in a general-purpose environment file.

## Key concepts

| Term | Definition |
|------|------------|
| Root CA and trust anchor | The root certificate installed in a relying party's trust store. It terminates certificate-path validation. |
| Issuing CA (ICA) | The intermediate CA that signs end-entity certificates. It is an issuer, not the trust anchor. |
| Certificate template | The purpose-bound constraints for issued certificates, including allowed key types, subject fields, validity, key usage, and extended key usage. |
| Certificate profile | A product-specific configuration that refines an end-entity template for a workload. |
| Certificate policy | The Device Trust Manager object that binds a profile, issuing CA, division, and enrollment methods. |
| Authentication policy | A Device Trust Manager collection of enrollment credentials, such as passcodes. |
| Service user | A non-interactive Account Manager identity represented by an API token and, where required, a client authentication certificate. |

## Implementation roadmap

Establish the account foundation, then prepare the private trust domain. The complete validation includes both device identity and code signing. After the shared foundation is ready, complete the workstreams concurrently or in either order.

### Shared foundation

Shared prerequisites.

1. [Establish the account foundation](https://dev.digicert.com/md/solutions/private-trust-stack/phase-1-account-foundation.md) — Account Manager
   Create a service user with limited roles, capture its API token, and create its client authentication certificate. Estimated time: 25 minutes. Inputs: bootstrap_api_token, account_name, organization_name, approved_role_names, client_auth_certificate_expiration. Outputs: account_id, organization_id, service_user_id, api_token_id, service_api_token, client_auth_certificate_id, client.crt, client.key.

2. [Prepare the private trust domain](https://dev.digicert.com/md/solutions/private-trust-stack/phase-2-private-trust-anchor.md) — DigiCert Private CA
   Identify the root and workload-specific issuing CAs, assign each issuer to the account, and download the CA certificates. Estimated time: 25 minutes. Inputs: account_id, service_api_token, root_ca_name, device_ica_name, signing_ica_name. Outputs: root_ca_id, device_ica_id, signing_ica_id, root-ca.pem, device-issuing-ca.pem, signing-issuing-ca.pem. Can start after Phase 1.

Next, complete every required workstream. You may work in either order or in parallel.

### Device identity

Required workstream.

3. [Configure device certificate infrastructure](https://dev.digicert.com/md/solutions/private-trust-stack/phase-3-device-infrastructure.md) — Device Trust Manager
   Select a device template, create a profile limited to one division, and bind the device issuing CA in a REST certificate policy. Estimated time: 20 minutes. Inputs: account_id, service_api_token, device_ica_id, device_template_name, primary_rendezvous_zone_name. Outputs: device_certificate_template_id, primary_rendezvous_zone_id, division_id, device_certificate_profile_id, certificate_policy_id. Can start after Phase 2.

4. [Enroll and verify a device](https://dev.digicert.com/md/solutions/private-trust-stack/phase-4-device-enrollment.md) — Device Trust Manager
   Attach a passcode authentication policy to a device group, issue a device certificate, and validate its key and chain. Estimated time: 25 minutes. Inputs: account_id, service_api_token, division_id, certificate_policy_id, passcode, root-ca.pem, device-issuing-ca.pem. Outputs: authentication_policy_id, passcode_id, device_group_id, device_certificate_id, certificate_request_id. Can start after Phase 3.

### Code signing

Required workstream.

5. [Configure and test private code signing](https://dev.digicert.com/md/solutions/private-trust-stack/phase-5-code-signing.md) — Software Trust Manager
   Select a code-signing template, bind the signing issuer to a profile, and verify a signature. Estimated time: 30 minutes. Inputs: account_id, organization_id, service_api_token, signing_ica_id, code_signing_template_name, client.crt, client.key, root-ca.pem, signing-issuing-ca.pem. Outputs: code_signing_certificate_template_id, signing_profile_id, keypair_id, signing_certificate_id, signature_id. Can start after Phase 2.


### Planning time

| Work | Focused execution time |
|------|------------------------|
| Shared foundation | 50 minutes |
| Device identity | 45 minutes |
| Code signing | 30 minutes |
| Full workflow | Approximately 125 minutes |

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

## Resume after a pause

1. Consult the [implementation status and saved values table](https://dev.digicert.com/md/solutions/private-trust-stack/reference.md#implementation-status-and-saved-values).
1. Verify the saved values and the last phase checkpoint you satisfied.
1. Resume at the first unmet checkpoint.
1. 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.

## After validation

- [Prepare the solution for production operations](https://dev.digicert.com/md/solutions/private-trust-stack/operate.md).
- [Diagnose a failed run or a request with an uncertain result](https://dev.digicert.com/md/solutions/private-trust-stack/troubleshoot.md).
- [Look up identifiers, authentication methods, and request formats](https://dev.digicert.com/md/solutions/private-trust-stack/reference.md).

## Start the implementation

[Establish the account foundation](https://dev.digicert.com/md/solutions/private-trust-stack/phase-1-account-foundation.md)

## Manual pages

- [Phase 1: Account foundation](https://dev.digicert.com/md/solutions/private-trust-stack/phase-1-account-foundation.md) — Shared foundation — Identify the account and organization and create the setup service identity and credentials.
- [Phase 2: Private trust domain](https://dev.digicert.com/md/solutions/private-trust-stack/phase-2-private-trust-anchor.md) — Shared foundation — Assign the issuing CAs and download the CA certificates used by both workloads.
- [Phase 3: Device certificate infrastructure](https://dev.digicert.com/md/solutions/private-trust-stack/phase-3-device-infrastructure.md) — Device identity — Create the division, device certificate profile, and certificate policy.
- [Phase 4: Device enrollment](https://dev.digicert.com/md/solutions/private-trust-stack/phase-4-device-enrollment.md) — Device identity — Create passcode enrollment configuration and validate an issued device certificate.
- [Phase 5: Code signing](https://dev.digicert.com/md/solutions/private-trust-stack/phase-5-code-signing.md) — Code signing — Issue a private code-signing certificate, sign a known hash, and verify the signature and certificate path.
- [Operate this solution](https://dev.digicert.com/md/solutions/private-trust-stack/operate.md) — Prepare, monitor, rotate, recover, and scale the private trust stack.
- [Troubleshoot the private trust stack](https://dev.digicert.com/md/solutions/private-trust-stack/troubleshoot.md) — Diagnose cross-product authorization, configuration, enrollment, path-validation, and signing failures.
- [Private trust stack reference](https://dev.digicert.com/md/solutions/private-trust-stack/reference.md) — Look up identifiers, response structures, authentication methods, and endpoints used by the solution.