[rahultee]

Why

Several pinned Nixpkgs inputs still use old CA certificate data. NSS 3.131.1 includes updated distrust information so standard CA-bundle consumers reject the affected certificate chains.

What changed

• Pin the upstream NSS 3.131.1 certdata.txt with its verified SHA-256 and use it for the cacert packages in the Nixpkgs sets used by the modules and PHP packages.
• Keep compatibility with both Nixpkgs cacert interfaces: older inputs accept an NSS source tree, while newer inputs accept the certificate-data file directly.
• Preserve each package set's existing extra CA certificates and blocklist options. Module IDs, Node versions, and upgrade aliases do not change.
• This updates CA bundles only. Node.js has an independent built-in trust store, which is not changed here. Node 22/24 runtime security updates and the EOL Node 20 support decision remain separate work; this change does not alias Node 20 to another major.

Test plan

• Built the existing NSS 3.117 CA bundle and the updated 3.131.1 bundles using the pinned public certificate data.
• Checked the 12 public certificate chains from the test dataset with OpenSSL. The old bundle accepted 6 and rejected 6; the updated bundle rejected all 12.
• Verified a live TLS connection to example.com with both bundles.
• Evaluated module metadata and checked Node module aliases; nix fmt -- --check flake.nix and git diff --check pass.
• After resolving the conflict with main, built representative CA bundles for both compatibility interfaces, evaluated all 105 module derivations, and checked all Nix file formatting with nixpkgs-fmt 1.3.0. Node 22.23.4 and 24.22.1 pins, module wiring, and the lockfile from main are unchanged. The CA overlay and data are unchanged from the chain regression test above.
• CI is pending. A full module-bundle build was not run for this conflict fix.

Rollout

Rebuild the module bundle to deliver the updated CA data. Existing custom CA additions remain available. Reverting restores the old CA data and the prior trust behavior.

• This is fully backward and forward compatible

~ written by ⠕ Replit