Trust distribution and updates

Separate roots, intermediates and initial TLS trust when distributing or migrating certificates.

This guide is for device and consumer trust administrators. You need issuer inventory, trust-store access and an authenticated update channel. Distributing certificates is separate from choosing trusted anchors.

Three trust relationships

Relationship	Material prepared by its owner
Device → EST server	Previously verified server root, chain or pin and TLS name.
DMS → requester	CAs and rules authorizing initial or renewal credentials.
Consumer → device	Operational identity roots, intermediates, validation and permissions.

Obtaining a certificate does not automatically configure these relationships in third parties. Review the Trust model.

What cacerts returns

The DMS may include the available downstream TLS certificate, selected Managed CAs and enrollment CA. Selecting the issuer does not include every ancestor. The set may contain leaves, roots and intermediates, including multiple hierarchies during migration.

Position does not define the chain. Identify certificates by subject, issuer, AKI/SKI, signature and constraints. Download and inspect using EST client.

Install the required material

Keep initial EST server trust separate from identity consumer trust.
Select policy-approved roots as anchors.
Retain intermediates for chain building or presentation; do not automatically turn them into roots.
Present the leaf and required intermediates in mTLS. Normally the peer already trusts its root and does not need it sent.
Verify chain, dates, names, usages and revocation from the consumer.

Do not indiscriminately use all of cacerts.pem as -CAfile: this can expand trusted authorities, hide missing intermediates or trust a TLS leaf intended for another purpose.

Migrate trust

Before changing Enrollment CA, inventory disconnected equipment, bootstrap and operational certificates, and consumers. Distribute the new root and required intermediates; check that a cohort accepts both old and new chains.

In the DMS, separate distributed CAs from additional_validation_cas, used for re-enrollment credentials. The inspected validator tries the enrollment CA followed by those CAs against the received leaf; accepting a multilevel chain requires checking what reaches the service and which issuer is configured.

Switch issuance, renew in cohorts and compare the installed serial with the active slot. Remove previous trust once no legitimate equipment needs it and policy permits ending overlap. Follow Hierarchy and rotation for the PKI operation.

Check the update

Test an old identity allowed during overlap, a new one, an unknown chain and the result after removing old trust. Keep trust-store version, approved set, date and result. Reachable /cacerts establishes distribution only; it does not establish installation or acceptance across every device.