Windows - Security - Create System Certificate Bundle

What the Trusted Root bundle distributor does

This Automox Worklet™ exports every certificate from the Windows Trusted Root Certificate Store and consolidates them into a single PEM-encoded bundle on disk. The Worklet then binds six machine-level environment variables to that file path. Every SSL-aware application on the endpoint validates against the same chain. The script enumerates Cert:\LocalMachine\Root, deduplicates by thumbprint, and writes the output to C:\ProgramData\proxy\cabundle.crt in ASCII encoding.

The Worklet sets REQUESTS_CA_BUNDLE, GIT_SSL_CAPATH, NODE_EXTRA_CA_CERTS, WEBSOCKET_CLIENT_CA_BUNDLE, AWS_CA_BUNDLE, and SSL_CERT_FILE at the machine target. Each variable points at the same cabundle.crt path. Python requests, Git, Node.js, the AWS CLI, the WebSocket client, and any tool that honors SSL_CERT_FILE then validate certificates against the consolidated bundle rather than their own vendored trust stores.

After the bundle is written, the Worklet applies an explicit ACL. SYSTEM and the local Administrators group keep full control. Everyone else gets read access. The file is then marked read-only so a stray process or local user cannot tamper with the trust anchor. If the policy supplies extra CA files through the tmpFiles parameter, the script appends each one to the bundle in order. When keytool.exe is on PATH or under any java_app_paths location (defaulted to C:\Program Files\JetBrains), the script also imports those certificates into every discovered cacerts keystore using the default "changeit" password.

Why enforce a single SSL trust baseline on Windows

Most Windows endpoints carry several parallel trust stores. The OS keeps its own list at Cert:\LocalMachine\Root. Python ships with the certifi bundle. Node.js bundles its own roots. The Java runtime keeps a cacerts keystore. Git for Windows is configured against either the OS store or its own ca-bundle.crt depending on installer choices. When a security team adds a corporate or third-party CA, that root usually lands only in the Windows store. The other applications keep validating against their stale, vendored bundles, which produces SSL handshake failures, CI pipeline breakage, and unpredictable certificate pinning behavior across the fleet.

Trusted Root stores on Windows drift every time a vendor installer pushes its own root, a corporate PKI rolls a new issuing CA, or an old enterprise CA reaches end of life and disappears from the gold image. Apply this Worklet on a recurring policy so cabundle.crt and the six SSL_CERT_FILE-style variables are re-synced on every workstation and server in scope. A weekly evaluation rewrites the bundle and rebinds the variables before a missing root becomes a Sev-2 ticket or an audit finding. The control supports PCI-DSS 4.2 cryptographic-trust requirements and NIST 800-53 SC-12 key management.

How Trusted Root bundle distribution works

1. Evaluation phase: The Worklet queries the machine environment for REQUESTS_CA_BUNDLE, GIT_SSL_CAPATH, NODE_EXTRA_CA_CERTS, WEBSOCKET_CLIENT_CA_BUNDLE, AWS_CA_BUNDLE, and SSL_CERT_FILE. If any variable is missing or empty, the endpoint is flagged non-compliant and remediation is queued. The script then runs Test-Path against C:\ProgramData\proxy\cabundle.crt; a missing bundle file is also a non-compliant signal. All six variables present and the bundle file on disk produces an exit 0.

2. Remediation phase: The script creates C:\ProgramData\proxy if it does not exist, clears any read-only flag on an existing bundle, and enumerates Cert:\LocalMachine\Root recursively. Certificates are deduplicated by thumbprint, base64-encoded with line breaks, and wrapped with -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers. The PEM stream is written to cabundle.crt in ASCII with no trailing newline. Any tmpFiles supplied by the policy are appended in order. The Worklet then strips ACL entries that are not SYSTEM or BUILTIN\Administrators, adds an explicit Everyone:Read rule, and marks the file read-only. Each of the six environment variables is written only when not already set, so reruns stay idempotent. Where keytool is discoverable under C:\Program Files\JetBrains (or on PATH), the script imports each tmpFiles certificate into every cacerts keystore it finds, skipping aliases that are already present.

Certificate bundle distribution requirements

• Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, Windows Server 2022, or later

• PowerShell 5.1 or later (the Automox agent default on Windows already meets this)

• Administrative privileges to write machine-level environment variables and to modify ACLs under C:\ProgramData\proxy

• Roots already present in Cert:\LocalMachine\Root; deploy your corporate or third-party CAs into the Windows store first using Group Policy, Intune, or a companion Worklet

• Optional tmpFiles parameter in the remediation script accepts an array of extra .crt or .pem paths to append to the bundle

• Optional java_app_paths parameter, defaulted to C:\Program Files\JetBrains, controls where the script looks for keytool.exe and cacerts files when extending the bundle into Java keystores

• Applications must honor at least one of the six standard CA-bundle variables, or accept PEM input through their own configuration (Python requests, Git http.sslCAInfo, Node.js TLS, AWS SDK, and any tool reading SSL_CERT_FILE all qualify)

Expected SSL trust state after distribution

A consolidated PEM file containing every Trusted Root certificate sits at C:\ProgramData\proxy\cabundle.crt with SYSTEM and Administrators in full control, Everyone in read, and the read-only flag set. All six environment variables resolve to that path at the machine level, and follow-up policy runs exit 0 without rewriting the bundle.

Validate from PowerShell on a freshly rebooted endpoint. Run [Environment]::GetEnvironmentVariable('SSL_CERT_FILE','Machine') to confirm the path. Test the bundle with python -c "import requests; print(requests.get('https://www.microsoft.com').status_code)" in a new shell. Validate Git with git -c http.sslCAInfo=$env:SSL_CERT_FILE ls-remote against an internal HTTPS Git host. Use openssl verify -CAfile C:\ProgramData\proxy\cabundle.crt against a leaf certificate from your CA to confirm the chain resolves. For audit evidence, capture the SHA-256 hash of cabundle.crt with Get-FileHash and store it with the policy run identifier. If a local administrator clears the file or unsets a variable, the next evaluation flags the endpoint and remediation rewrites the bundle.