Distributing a Standalone root CA with Group Policy or Intune¶

A Private CA in Standalone mode has a root that CertIntel created, so nothing trusts it until you install that root on every device that must accept the certificates it issues. This page is the rollout guide: get the root, check it, push it with the tools you already use for the fleet (Group Policy, Intune or another MDM, the Linux trust stores, macOS configuration profiles), verify it on a device, and take it out again when the CA is rotated or deleted.

Three things to know before you start:

• CertIntel does not push the root to devices. The dashboard gives you the root and its fingerprint; distribution and verification are yours, with your own deployment tooling. Agent 1.5.0 and later report whether their own machine trusts the root (see Checking where the root is trusted); machines without an Agent are not reported.
• The CertIntel Agent never installs a root on its own. Issuing, renewing or installing a certificate never touches a trust store. The opt-in certintel private-ca trust <id> command and the desktop app's Trust this CA on this computer… action install the root on that one machine, after an explicit administrator approval; they are a convenience for a lab box or a single server, not a rollout mechanism (see One machine at a time).
• A Subordinate (bring your own root) CA needs none of this: your devices already trust your root, and the CertIntel-held issuing CA chains to it.

1. Download the root and check its fingerprint¶

1. Open Settings → Private CA and click the standalone CA.
2. Open the fold-out Roll the root out to a fleet (Group Policy, Intune, CertIntel Agent) (platform builds after 2026.10.28). It links back to this page, offers the root as root.crt (binary DER, the format Group Policy and Intune import directly) and shows the root's SHA-256 fingerprint; its Group Policy and Intune lines are one-sentence summaries of the sections below. The same file is public at https://<your CertIntel origin>/pki/<ca_id>/root.crt and as PEM at /pki/<ca_id>/root.pem, so a deployment pipeline can fetch it without signing in.

3. Compare the file you downloaded with the fingerprint on the page before you put it into any policy. The fingerprint is the SHA-256 of the DER bytes, so hashing root.crt gives the same value (hashing root.pem does not; use openssl on the PEM copy):

   Get-FileHash .\root.crt -Algorithm SHA256
   

   certutil -hashfile root.crt SHA256
   

   openssl x509 -inform der -in root.crt -noout -fingerprint -sha256
   openssl x509 -in root.pem -noout -fingerprint -sha256     # PEM copy
   

Keep the fingerprint with your change record; every verification step below compares against it. A standalone root defaults to a 20-year validity, so the file you distribute today is the one you will be removing in a long time.

2. Windows: Group Policy¶

Use Group Policy for domain-joined computers. The root goes into the computer store (LocalMachine\Root); do not deploy it as a user certificate.

1. Open the Group Policy Management console (gpmc.msc), create a new GPO (or open an existing certificate-trust GPO) and Edit it.
2. Go to Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities.
3. Right-click the node, choose Import…, select root.crt (the wizard accepts DER .crt/.cer and Base-64 files alike) and keep the default store Trusted Root Certification Authorities. Finish the wizard; the root appears in the list with its subject and expiry.
4. Link the GPO to the OU that contains the computers that must trust the CA (right-click the OU → Link an Existing GPO…). A link to the domain root reaches every computer; prefer the narrowest OU that holds the servers and workstations that will see these certificates. Domain controllers are in their own OU and need a separate link if they are relying parties.

5. Wait for the next policy refresh (90 minutes by default, plus a random offset) or force it on a test computer from an elevated prompt:

   gpupdate /target:computer /force
   

A root delivered this way lands in the policy-managed part of the store and is removed again when you delete it from the GPO or unlink the GPO; it cannot be deleted locally by a user.

Verifying on a Windows device¶

List the installed roots, filtered by the root's common name:

certutil -store Root "Example Root CA"

certutil prints the subject, serial, validity and Cert Hash(sha1). That hash is SHA-1, not the SHA-256 fingerprint the CA page shows, so do not compare the two. Get the SHA-256 of the installed copy in PowerShell (the Thumbprint property is SHA-1 as well):

$root = Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like '*Example Root CA*'
$root | Format-List Subject, NotAfter, Thumbprint
[BitConverter]::ToString([Security.Cryptography.SHA256]::Create().ComputeHash($root.RawData)) -replace '-'

The last line must equal the fingerprint on the CA page. The certificate dialog (certlm.msc → Trusted Root Certification Authorities → Certificates, double-click the root → Details) confirms the subject, serial number and validity; its Thumbprint field is SHA-1 too, so use the PowerShell line for the SHA-256 comparison. A browser or curl request to a server that already holds a CertIntel-issued certificate is the end-to-end check.

3. Windows: Intune¶

Use an Intune Trusted certificate profile for Entra-joined or co-managed Windows devices.

1. In the Intune admin center open Devices → Configuration → Create → New policy.
2. Choose Platform: Windows 10 and later, Profile type: Templates, then the Trusted certificate template, and Create.
3. Name the profile (for example CertIntel private CA root), then under Configuration settings upload root.crt as the Certificate file (rename it to .cer if the file picker filters on that extension; the content is the same DER) and set Destination store to Computer certificate store - Root.
4. Assignments: assign the profile to a device group that contains the computers which must trust the CA. Assigning to users would still place the root in the computer store, but device groups are what you want for servers and shared machines.
5. Review and Create.

Intune delivers the certificate at the device's next check-in. Devices check in about every eight hours, so a fleet-wide rollout can take most of a working day. To hurry a test device: on the device, Settings → Accounts → Access work or school → (your account) → Info → Sync, or in the admin center open Devices → Windows → (device) → Sync. Then verify on the device as in Verifying on a Windows device.

To see the rollout from the portal, open the profile and look at Device and user check-in status on its Overview, and Device status for the per-device result; a device that has not checked in since the assignment is still listed as Pending. Removing the profile's assignment (or deleting the profile) removes the root from the devices at their next check-in.

4. Linux¶

The Linux trust stores take a PEM or DER file in a distribution-specific anchor directory followed by an update command. Use the PEM copy (root.pem) and give the file a name that identifies the CA:

Push the file and the command with the configuration-management tool you already use (Ansible, Salt, Puppet, a deb/rpm package of your own); the operations are idempotent. Verify with OpenSSL against a server that holds a CertIntel-issued certificate, or by checking the installed copy:

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt server.pem        # Debian/Ubuntu bundle
openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.crt server.pem           # RHEL family bundle
openssl x509 -in /usr/local/share/ca-certificates/certintel-example-root.crt -noout -fingerprint -sha256

Some software keeps its own trust store and ignores the system one:

• Java reads $JAVA_HOME/lib/security/cacerts (or its own truststore): keytool -importcert -cacerts -alias certintel-root -file root.pem (-cacerts needs Java 9 or later; older releases take -keystore).
• Python requests uses the bundled certifi store unless REQUESTS_CA_BUNDLE (or SSL_CERT_FILE) points at a bundle that contains the root.
• Firefox has its own store; enable Use the enterprise roots under Settings → Privacy & Security → Certificates, or set the security.enterprise_roots.enabled / Certificates policy, so it honours the system store.
• Snap packages are confined and may not see /usr/local/share anchors; check the application's documentation.

5. macOS¶

Deploy the root as a configuration profile with a certificate payload (com.apple.security.root). Through MDM the root is installed in the System keychain and trusted without any clicks on the Mac:

• Intune: Devices → Configuration → Create → New policy → Platform: macOS → Profile type: Templates → Trusted certificate, upload root.crt, set the deployment channel to the device channel, and assign it to a device group, exactly as for Windows.
• Jamf Pro: Computers → Configuration Profiles → New, add the Certificate payload, upload root.crt, tick Allow all apps access if you have apps that need it, scope the profile to the Macs and save.
• Another MDM: build a .mobileconfig with a com.apple.security.root payload containing the DER bytes and push it as a device profile.

A profile that a user installs by double-clicking is not trusted automatically on current macOS; only MDM-delivered profiles are. For a single Mac without MDM, from Terminal with an administrator account:

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain root.pem

Verify in Keychain Access → System → Certificates (the root shows This certificate is marked as trusted for all users) or with security find-certificate -c "Example Root CA" -p /Library/Keychains/System.keychain | openssl x509 -noout -fingerprint -sha256. Removing the profile from the MDM removes the root; the manual install is removed with sudo security remove-trusted-cert -d root.pem followed by sudo security delete-certificate -c "Example Root CA" /Library/Keychains/System.keychain.

One machine at a time: the Agent¶

An enrolled Windows or Linux Agent can install the root on its own machine, and only there, when an administrator asks for it:

• Windows: select the certificate, Edit workflow… → Trust this CA on this computer…, confirm the dialog and approve the elevated CertIntel Agent - administrator approval prompt; or run certintel private-ca trust <id> from an elevated prompt.
• Linux: sudo certintel private-ca trust <id> writes the root into the distribution's anchor directory and runs its update command.

This is a per-machine opt-in for a test box or a server that has no policy coverage; it is not a fleet rollout and cannot be triggered from the dashboard. Fleet trust comes from the sections above. See Trusting the CA on the machine.

On Windows, Agent 1.5.0 and later restrict the root to TLS server and client authentication; earlier releases restricted it to server authentication, so client certificates from the CA were not trusted. After upgrading, run certintel private-ca trust <id> again on machines where an earlier Agent installed the root: it updates the restriction in place.

Checking where the root is trusted¶

Agent 1.5.0 and later report, without any extra rights, whether their machine trusts the root - however it was installed, including by Group Policy, Intune or a Linux anchor file. The CA page's Trust on hosts matrix shows each host and store as Trusted, Trusted (server only), Trusted (client only), Not trusted, Error or Not reported (an Agent allowed to request certificates that sent no report, for example one before 1.5.0). Use it to follow a rollout and, before removing an old root, to find the hosts that still trust it. Machines without an Agent are not covered; verify those as in the sections above. See trust status on hosts.

Rotation: a new root¶

Two kinds of rotation are different on the trust side:

• Issuing CA rotation (on a platform build that offers it). CertIntel rotates an issuing CA before it expires by creating a successor signed by the same root. Devices keep trusting the same root, so nothing needs to be redistributed. Agent 1.5.0 and later move their certificates to the successor at the next renewal.

• A new root. CertIntel does not renew or rotate a root: when you want a new root (or the root itself is about to expire, which the CA page warns about), you create a new standalone CA, which brings a new root with a new fingerprint. Plan the trust side first:

• Create the new CA and distribute its root with the same GPO, Intune profile, Linux anchor and macOS profile before anything is issued from it: add the second root alongside the first (a GPO and an Intune profile each hold any number of roots; Linux anchor directories take any number of files). Verify on a device that both roots are present.

• Point new issuance at the new CA (Agents: change the certificate's issuing CA with Issue / replace; direct requests: use the new CA's page) and let renewals move the fleet across.
• Keep the old root until the last certificate it signed has expired or been replaced. Devices that still hold old-root certificates stop validating the moment the old root disappears from their store. The CA's Issued certificates table and the Certificates inventory (source Private CA) show what is still out there, and the Trust on hosts matrix of each CA shows which Agent hosts trust which root.
• Then remove the old root from the GPO (delete it under Trusted Root Certification Authorities), the Intune profile (unassign or delete), the Linux anchor directory (delete the file, re-run the update command) and the macOS profile, and delete the old CA.

When the CA is deleted¶

Delete this CA soft-deletes the CA and its root. Certificates it issued keep working on devices until they expire; CertIntel stops publishing the CRL and nothing can be issued or revoked. The root stays trusted wherever you put it until you take it out, and that is what stops its certificates from validating:

• Remove the root from the GPO (or unlink the GPO) and from the Intune profile; devices drop it at their next policy refresh or check-in.
• Delete the file from the Linux anchor directories and run the update command; remove the macOS profile, or security remove-trusted-cert on a manually trusted Mac.
• Remove the trust anchor that CertIntel registered on the Trusted CAs page once the last certificate is gone; deleting the CA leaves it in place.

Do this deliberately: removing a root from a device whose server certificates still chain to it breaks those servers at once, with no warning from CertIntel. CertIntel sees device trust stores only through the trust reports of Agent 1.5.0 and later, and never stops you from removing a root.

Related pages¶

• Private CA - setting up a standalone or subordinate CA, issuance, CRLs, and the Agent
• Trusted CAs & ignore list - the trust anchor a CA registers for chain reviews in the dashboard
• Windows Agent and Linux Agent - the per-machine certintel private-ca trust command