ca-certificates

Overview

ca-certificates provides the system trust bundle used by TLS-enabled software to verify certificate chains. In NiceOS, this package is part of the shared certificate trust setup that applications such as browsers, package managers, and other network clients use when they validate HTTPS or other TLS connections. NiceOS also documents that its ca-certificates package may include additional trusted roots for compatibility with some Russian services and corporate PKI chains, so maintainers should verify the current policy before relying on that detail. (niceos.ru)

Purpose and typical use cases

Typical use cases include:

• validating HTTPS connections from CLI tools and applications;
• providing a system-wide trust store for desktops and servers;
• adding or removing local trust anchors for internal services;
• keeping certificate trust data aligned with distribution policy and upstream trust list updates. (fedoraproject.org)

Typical users include:

• administrators who manage system trust anchors;
• developers who need reliable TLS verification in applications and CI jobs;
• security engineers who review trust-store changes and certificate policy;
• CI/CD maintainers who need reproducible package builds and predictable trust behavior;
• desktop users whose network applications depend on the system certificate store. (fedoraproject.org)

Upstream project

The upstream data source for CA trust lists is typically maintained outside this dist-git repository. Fedora’s package documentation identifies Mozilla’s CA certificate policy and trust lists as the upstream reference point for the package family, and Red Hat documentation describes the update-ca-trust workflow used to manage the system trust store. If NiceOS carries local trust-policy changes, maintainers should verify the exact upstream source and local delta before updating. (fedoraproject.org)

Dist-git repository contents

This repository is the RPM dist-git for ca-certificates and is organized as follows:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source metadata and manifest files used to track imported upstream material;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials material, when provided by the packaging workflow.

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps source-integrity metadata in SOURCES/ manifests so that imported content can be verified without committing large binary payloads. (packages.niceos.ru)

Source storage and integrity policy

For this package, integrity is tracked through the manifests in SOURCES/, not by storing large source archives in Git. Maintainers should treat the manifest as the authoritative record for imported source material and verify that any refreshed source content matches the intended upstream snapshot and local packaging policy. Do not assume that a manifest update is safe just because the package still builds. (packages.niceos.ru)

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check the following:

• whether the upstream trust list, local trust policy, or package scripts changed;
• whether any local additions or removals of trust anchors still match NiceOS policy;
• whether SPECS/, SOURCES/, METADATA/, or SBOM/ need regeneration;
• whether the package still installs, updates, and refreshes the trust store correctly;
• whether any applications in the distro depend on a stable system trust-store layout;
• whether the change affects users who rely on local or corporate CA anchors. If the expected impact is unclear, verify it before shipping the update. (fedoraproject.org)

Practical risks to consider:

• removing a certificate that is still required by internal infrastructure;
• adding trust anchors that widen trust more than intended;
• mismatches between the package content and the system trust-store tooling;
• packaging drift when upstream trust data changes but local policy is not reviewed. (fedoraproject.org)

Build and verification checklist

Use this checklist when rebuilding or reviewing changes:

• confirm the source manifest in SOURCES/ matches the intended imported content;
• review the spec changes for trust-store installation logic and file placement;
• build the SRPM and RPMs in the expected NiceOS build environment;
• install the built package in a clean test environment;
• run the trust-store update path used by the package or its helper scripts;
• verify that a sample TLS client can read the system trust store;
• verify that any local trust-anchor additions still work as intended;
• check that no unintended files are added to the package payload;
• confirm that repository metadata and SBOM material, if present, are still consistent with the package contents. (fedoraproject.org)

References

• NiceOS package page: ca-certificates
• NiceOS package information: ca-certificates
• NiceOS package repository listing: NiceOS RPM Repository
• Fedora CA certificate package notes: CA-Certificates
• Fedora shared system certificates testing notes: Features/SharedSystemCertificates:Testing
• Red Hat guidance on adding a CA certificate to the trust store: How to update a CA certificate on Red Hat Enterprise Linux 7 and later

Russian documentation

• Read the Russian version: README_RU.md

Dist-git repository notes

• Package repository: rpms/ca-certificates
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.