Trusting a private CA on macOS and Windows, and verifying it actually took effect

Goal

Add a private root CA certificate to the system-wide trust store on macOS and on Windows Server, so TLS clients that consult the OS store accept certificates it issued.

Prerequisites

Administrator/root privileges (on Windows an elevated PowerShell or command prompt, because the target is the machine store); the CA certificate in DER or PEM form for macOS, a .cer/.crt/.p7b file for Windows (macOS 13 and later; Windows Server 2016 and later, PowerShell 5.1+). On macOS 11 and later, changing admin trust settings from the command line additionally needs an interactive authorization in a logged-in GUI session; run over SSH or from an unattended script, add-trusted-cert can fail with an authorization error ("no user interaction was possible"). For unattended or fleet-wide rollout, a configuration profile with a certificate payload delivered by MDM is the supported route.

Steps

macOS:

1. sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/ca.pem -d writes the trust setting to the admin domain (the default is the invoking user's domain), which applies to all users on the machine; -r trustRoot (also the default result type) marks a self-signed root as trusted for all policies — an intermediate would need trustAsRoot; and -k stores the certificate in the System keychain rather than the invoking user's login keychain.
2. No reboot is required; new TLS connections normally see the change, but already-running long-lived daemons may need a restart.

Windows:

1. PowerShell: Import-Certificate -FilePath C:\ca.cer -CertStoreLocation Cert:\LocalMachine\Root
2. Or certutil -addstore -f "Root" C:\ca.cer (without -user, certutil targets the local machine store; -f overwrites a copy that is already present). Both write to the Local Machine Trusted Root store, so no per-user step is needed for services or scheduled tasks running as other accounts.
3. Non-interactive: adding to LocalMachine\Root shows no confirmation prompt, so both commands run unattended from an elevated session.

Expected result

macOS: security find-certificate -c "<CA common name>" /Library/Keychains/System.keychain returns the certificate, security dump-trust-settings -d lists it among the admin trust settings, and a TLS client (curl, an app using the system store) accepts a leaf certificate chaining to it. Windows: Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like "*<CA name>*" returns it, and Invoke-WebRequest against a server presenting a leaf from that CA no longer reports a trust error.

Limits and test basis

A certificate imported into a keychain without trust settings (for example with security import or Keychain Access drag-and-drop) looks installed but is not trusted as a root; check dump-trust-settings, not only find-certificate. On Windows, adding to CurrentUser\Root instead of LocalMachine\Root trusts it only for that user, not for services, and it pops up a security-warning confirmation dialog that blocks unattended runs. To undo: sudo security remove-trusted-cert -d /path/to/ca.pem and then sudo security delete-certificate -c "<name>" /Library/Keychains/System.keychain on macOS, or certutil -delstore "Root" "<serial number or thumbprint>" (elevated) on Windows.