Windows - Security - Create System Certificate Bundle

What the certificate bundle consolidation does

This Automox Worklet™ exports all certificates from the Windows Trusted Root Certificate Store and consolidates them into a single PEM-formatted bundle file. The Worklet then configures six environment variables (REQUESTS_CA_BUNDLE, GIT_SSL_CAPATH, NODE_EXTRA_CA_CERTS, WEBSOCKET_CLIENT_CA_BUNDLE, AWS_CA_BUNDLE, and SSL_CERT_FILE) to reference this centralized bundle, forcing all compliant applications to use the same trusted certificate chain.

The Worklet stores the bundle file at C:\ProgramData\proxy\cabundle.crt with restrictive file permissions (read-only, accessible to System and Administrators, with read access for all users). If your environment includes Java applications, the Worklet automatically locates the JetBrains keytool and imports the bundle into Java keystores, eliminating the need for separate Java certificate management.

Why standardize certificate validation across your endpoints

When different applications maintain separate certificate stores, they can report conflicting SSL/TLS validation results. Python libraries, Git clients, Node.js applications, and AWS SDKs may each trust different CAs, creating inconsistent security posture and operational complexity. A single, managed CA bundle ensures all applications validate against the same trusted roots, eliminating certificate errors and simplifying endpoint security policy.

Organizations with custom or third-party CAs benefit particularly from centralized bundle management. Instead of configuring each application individually, you define your certificate trust chain once, and the Worklet distributes it uniformly across all endpoints. This approach also simplifies compliance audits by providing a single point of certificate inventory and validation.

How certificate bundle consolidation works

1. Evaluation phase: Checks if all six environment variables are configured at the machine level and verifies that the cabundle.crt file exists at C:\ProgramData\proxy\. If any variable is missing or the bundle file does not exist, the Worklet signals that remediation is required.

2. Remediation phase: Creates the proxy directory if it does not exist, exports all unique certificates from Cert:\LocalMachine\Root, writes them in PEM format to the bundle file, appends any additional CA certificates if provided, sets read-only file permissions, configures all six environment variables, and optionally imports the bundle into Java keystores.

Certificate bundle configuration requirements

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

• Administrative privileges required to set machine-level environment variables and modify file permissions

• Write access to C:\ProgramData\proxy directory

• If using custom CAs, provide additional certificate files as the tmpFiles parameter in the remediation script

• For Java keystore updates, Java 8 or later must be installed if JetBrains keytool is available

• Bundle file uses ASCII encoding; applications must support PEM certificate format

Expected certificate trust state after remediation

After the Worklet completes successfully, a single bundle file containing all Windows Trusted Root certificates exists at C:\ProgramData\proxy\cabundle.crt. Environment variables REQUESTS_CA_BUNDLE, GIT_SSL_CAPATH, NODE_EXTRA_CA_CERTS, WEBSOCKET_CLIENT_CA_BUNDLE, AWS_CA_BUNDLE, and SSL_CERT_FILE all reference this path at the machine level, available to all users and applications.

Python pip, Git clients configured with SSL verification, Node.js applications with NODE_EXTRA_CA_CERTS support, AWS CLIs, and WebSocket clients automatically use the centralized bundle for SSL/TLS validation. Endpoints with Java applications will have the bundle imported into their keystores, accessible via the standard "changeit" keystore password. Endpoints require a reboot for newly configured environment variables to take full effect across all applications.