certmonger

Overview

certmonger is a service for handling certificate enrollment and renewal on systems that use public key infrastructure. Its upstream project describes it as a background daemon that can track certificate requests, monitor existing certificates, and help renew them before they expire. (pagure.io)

In a Linux distribution, this package is typically useful when a system needs to request, track, or refresh certificates without doing all of that manually. Exact integration points depend on the distribution build and local configuration, so NiceOS maintainers should verify the packaging details before relying on a specific workflow.

Purpose and typical use cases

Typical use cases include:

• requesting certificates from a CA and storing the issued certificate on disk
• tracking certificate expiration and triggering renewal workflows
• automating enrollment for hosts that need managed certificates
• supporting systems that rely on certificate-based authentication or service identity

Typical users are:

• system administrators managing certificate lifecycles on servers
• infrastructure or platform engineers automating enrollment for fleets
• security engineers who need managed certificate rotation or tracking
• CI/CD or deployment maintainers who want certificate handling to be part of automation

The package is not a general-purpose PKI toolkit; it is meant to reduce repetitive operational work around certificate enrollment and renewal.

Upstream project

Upstream project page: certmonger on Pagure

The upstream project page states that certmonger is intended to simplify interaction with certificate authorities and keep systems enrolled. It also notes support for a background daemon and a command-line client that uses the daemon over D-Bus. The same project page is the best starting point for upstream documentation and release activity. (pagure.io)

If a local package change depends on upstream behavior, NiceOS maintainers should verify the relevant upstream documentation or source code instead of assuming the behavior is stable.

Dist-git repository contents

This dist-git repository is organized to keep packaging data separate from upstream source content:

• SPECS/ contains the RPM spec file and any packaging logic used to build the package.
• SOURCES/ contains source metadata and manifest files used to describe the external sources referenced by the package.
• METADATA/ stores repository metadata used by dist-git tooling.
• SBOM/ stores software bill of materials material, when present in the repository layout.

The large upstream source archives are intentionally not stored in this Git repository. This keeps the repository smaller and avoids duplicating large upstream release artifacts in version control.

Source storage and integrity policy

Source integrity is tracked through manifest files in SOURCES/ rather than by storing the full upstream archive in Git.

For maintainers, this means:

• check that the expected source manifests are present and updated when sources change
• verify that the spec file still points to the correct source material
• confirm that any regenerated metadata matches the intended upstream release contents

Do not rely on a stale manifest after updating the package. If the source layout changes upstream, the manifest format or source references may also need to be refreshed.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether the upstream release changes build requirements or optional features
• whether spec file patches still apply cleanly
• whether generated files in the source tree need regeneration
• whether any packaging metadata in SOURCES/, METADATA/, or SBOM/ needs to be refreshed
• whether local distro policy requires additional hardening, subpackage changes, or file ownership adjustments
• whether the update affects service files, D-Bus integration, or installed paths

Risks to consider:

• upstream behavior changes may alter enrollment, renewal, or monitoring workflows
• generated documentation or man pages may need to be rebuilt from upstream sources
• packaging assumptions may become invalid if upstream renames files or adjusts build tooling

If something in the update path is unclear, NiceOS maintainers should verify it before relying on it.

Build and verification checklist

A practical RPM-maintainer checklist:

• confirm that the spec file still references the correct source metadata in SOURCES/
• verify that all required manifests and auxiliary files are present
• rebuild the SRPM and check that it is reproducible within local packaging expectations
• run the package build in a clean mock or equivalent isolated build environment
• inspect the build log for missing build dependencies, deprecation warnings, or failed tests
• review the installed file list for unexpected additions or removals
• verify that service units, D-Bus files, and documentation are installed as intended
• if applicable, run the package test suite or any upstream smoke tests
• confirm that the resulting package still matches NiceOS policy for file locations, dependencies, and ownership

References

• certmonger upstream project page
• certmonger commits and release activity

Russian documentation

See README_RU.md for the Russian version of this documentation.

Dist-git repository notes

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