cURL Root Certificates Update

What the cURL certificate refresh Worklet does

This Automox Worklet™ refreshes the system-wide root certificate bundle that cURL and other OpenSSL-backed tools read from /etc/ssl/cert.pem on macOS endpoints running Mojave (10.14) or earlier. The Worklet downloads the current bundle from the LibreSSL portable project on GitHub, backs up the existing file to /etc/ssl/cert.BAK, and writes the new bundle in place. After the swap, it runs an openssl s_client probe against api.automox.com to confirm the trust chain validates end to end.

The Worklet targets a known operational gap: Apple stopped shipping certificate store updates for older macOS releases, so endpoints stuck on High Sierra, Mojave, or earlier carry a static cert.pem that still trusts the expired DST Root CA X3. That root was the historical anchor of the Let's Encrypt chain, and its September 2021 expiry broke HTTPS for any tool relying on the OpenSSL bundle. The Worklet replaces the stale bundle with the LibreSSL maintained version so the chain validates against ISRG Root X1 and other modern roots.

The evaluation phase is conservative. It reads the Darwin kernel major version and exits zero on Darwin 19 or later, because Catalina and newer endpoints receive certificate store updates from Apple and do not need the Worklet. It also parses the OpenBSD version stamp inside /etc/ssl/cert.pem and exits zero when the on-disk bundle is already at 1.24 or later. Only Mojave or earlier endpoints with a stale bundle are flagged for remediation.

Why refresh the macOS cURL trust store

TLS trust is invisible until it breaks, and it breaks all at once. When DST Root CA X3 expired, every HTTPS connection from a legacy macOS endpoint to a Let's Encrypt protected service started failing with a certificate verification error. Tools that pin OpenSSL rather than Secure Transport were hit first: cURL, git, pip, wget, brew, and any custom script that shells out to curl. In many shops the first symptom was that the Automox agent itself could no longer reach api.automox.com, which removed the obvious remediation path. Refreshing /etc/ssl/cert.pem with a maintained bundle restores trust for every consumer of that file in one operation.

cURL on macOS ships a cert.pem bundle that ages out as new roots are issued and old ones expire. A stale bundle is the root cause of pip install SSL CERTIFICATE_VERIFY_FAILED tickets from developers and silent agent check-in failures alike.

Run the Worklet across the macOS developer-laptop and shared-Mac fleet to refresh /etc/ssl/cert.pem in a single policy pass. Keep it on a recurring schedule so the next evaluation catches a stale bundle before a developer files a broken-TLS ticket or an agent loses contact with the platform.

How the cURL certificate refresh works

1. Evaluation phase: The script reads the Darwin kernel version with uname -r and extracts the major number. Darwin 19 and above maps to Catalina or later, which Apple still updates, so the endpoint exits compliant. For older endpoints, the script greps the OpenBSD: header line inside /etc/ssl/cert.pem, parses the version field, and strips the dot. A value of 124 or greater (LibreSSL 1.24+) marks the bundle as current and the endpoint exits compliant. Anything older returns a non-zero exit code and the policy schedules remediation.

2. Remediation phase: The script re-checks the Darwin version and refuses to run on Catalina or later. On Mojave or earlier, it downloads the current cert.pem from https://raw.githubusercontent.com/libressl-portable/openbsd/master/src/lib/libcrypto/cert.pem into /tmp/cert.pem using curl -ksS, then moves the existing /etc/ssl/cert.pem to /etc/ssl/cert.BAK and promotes the new file into place. If the first download fails, the script retries it once before giving up. Once the swap completes, the script calls openssl s_client -connect api.automox.com:443 and greps for Verify return code: 0 (ok) to confirm the new bundle resolves the Automox API chain. A failed verification returns exit code 1 so the failure shows up in Automox activity logs.

macOS cURL certificate refresh requirements

• macOS Mojave (10.14, Darwin 18), High Sierra (10.13, Darwin 17), or earlier; Catalina and newer endpoints are skipped by the evaluation phase

• Outbound HTTPS reachability to raw.githubusercontent.com on TCP 443 to fetch the LibreSSL portable cert.pem

• Outbound HTTPS reachability to api.automox.com on TCP 443 for the post-swap openssl s_client verification step

• Root privileges for the Automox agent so it can write to /etc/ssl/ (the default agent context already meets this requirement)

• /etc/ssl/cert.pem present on the endpoint; the script reads its OpenBSD version stamp during evaluation to decide whether a refresh is needed

Expected TLS state after the refresh

After remediation, /etc/ssl/cert.pem on the endpoint reflects the current LibreSSL portable bundle and includes ISRG Root X1, the active anchor for Let's Encrypt chains. The previous bundle is preserved at /etc/ssl/cert.BAK in case a rollback is needed. cURL, git, pip, wget, brew, and any other tool that defaults to the system OpenSSL trust store can complete TLS handshakes against modern endpoints without certificate verification errors. The Automox agent itself can reach api.automox.com, which restores the management plane on endpoints that had gone dark after the DST Root CA X3 expiry.

Validate the refresh by running curl -v https://valid-isrgrootx1.letsencrypt.org/ on the endpoint and confirming the handshake completes with SSL certificate verify ok. A second probe with openssl s_client -connect api.automox.com:443 should print Verify return code: 0 (ok) at the bottom of the session summary. To confirm the bundle itself, grep the OpenBSD: header inside /etc/ssl/cert.pem and check that the version field is 1.24 or later. Subsequent Automox policy runs report the endpoint as compliant without re-running the download, because the evaluation phase finds the bundle already current.