Validate device identity and code signing in a private trust stack

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.

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.

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 required capabilities are:

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

Planning time

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.
2. Verify the saved values and the last phase checkpoint you satisfied.
3. Resume at the first unmet checkpoint.
4. 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.
• Diagnose a failed run or a request with an uncertain result.
• Look up identifiers, authentication methods, and request formats.

Start the implementation

Establish the account foundation