AlmaLinux Hands the Certification Test Kit to Its Users — and Publishes the Results

TL;DR

• On September 24, 2026, the AlmaLinux OS Foundation launched software certification for third-party products: results land in the public catalogue at catalog.almalinux.org, and every tester is named.
• The alma-certify suite was fully rewritten as a Python tool that runs on the machine under certification, ships as an RPM in the extras repository, and finishes most runs in under 10 minutes.
• A catalogue listing is a claim by whoever ran the test — vendor, Foundation, or community member — and validations stack, tracked per AlmaLinux major version.
• Compatibility certification is not a security certification: FIPS 140-3 validated modules and a Common Criteria certification for AlmaLinux OS 9.2 are separate paths.
• For procurement, trusting a Linux compatibility listing now has a concrete checklist: who tested, against which release, and whether the suite can be re-run locally.
• The shift inverts the old vendor-administered certification bottleneck

The vetting bottleneck just changed hands

On September 24, 2026, the AlmaLinux OS Foundation announced software certification for third-party products, and the announcement opens with the argument in full: "Software certification is here, and hardware certification takes under 10 minutes." The mechanics behind that line — the test kit, the catalogue, the named tester — matter more than the headline.

Certification in the Linux ecosystem has historically been a vendor-administered bottleneck: paid programmes, non-disclosure agreements, and closed test cycles decided who earned the badge. The AlmaLinux certification page says plainly this is the problem the programme exists to remove: "Certifying in the Linux ecosystem is too often a tedious, painful process." The response: the test kit is public, the results are public, the tester is named.

The sections below cover what the programme does, what a listing is and is not, and the questions procurement engineers should carry into the next compatibility check.

One catalogue, and every tester named

All of this work lands in the public catalogue at catalog.almalinux.org, covering systems, components, software, benchmarks, and validations — with attribution in one sentence: "Every listing says who did the testing: the vendor, the AlmaLinux OS Foundation, or a community member."

The results are cumulative: "Those validations stack and complement each other, and they're tracked per AlmaLinux major version." Stacking puts a community confirmation alongside a Foundation-validated result. Per-major-version tracking means a 9.x listing does not carry over to 10.x — every major upgrade resets the question.

alma-certify: the test kit runs on the machine it tests

The engine is a full rewrite — "It replaces the Ansible-based suite that we used to provide" — running as a Python tool "directly on the machine being certified, and produces a report the catalog can ingest", delivered as a single package: "It ships as an RPM in the extras repository." Nothing is hidden: "As always, it's fully open source."

Speed is a stated goal: "for the overwhelming majority of systems a certification run now finishes in under 10 minutes." The vendor loop is short — "you just list your product, cite the releases it supports, and submit" — and the community route shorter: "Just sign in to catalog.almalinux.org and confirm that a product works on the release you're running."

A named tester beats a logo — and a listing stays a claim

What the catalogue does not do is certify on anyone's authority but the tester's own. A community confirmation is a 'works for me' report: useful evidence, not a guarantee. The model surfaces disagreement instead of burying it — two listings for the same product, one green and one not, are information rather than a bug.

That is the distance from a vendor-run programme: the old style resolved conflicts inside a closed process; this one publishes both claims and lets the next tester — or the customer — re-run the suite and decide. Reproducibility is the audit: point the tool at the machine you actually run.

Compatibility is not security: FIPS and Common Criteria stay outside the catalogue

The most important sentence in the programme's own documentation is the shortest: "Certification here is a statement about compatibility." It means AlmaLinux runs correctly on a piece of hardware, or software runs correctly on AlmaLinux — nothing beyond that. The page is explicit: "This is not a regulatory or security certification."

AlmaLinux OS 9.2 carries those assurances separately: "FIPS 140-3 validated cryptographic modules and a Common Criteria certification." Separate programmes, separate evidence chains — no catalogue listing substitutes for either. If a vendor's slide blends 'certified to run on AlmaLinux' into 'already FIPS-ready', the correction is above.

What procurement should check before trusting a listing

For an enterprise engineer the catalogue turns a compatibility claim into an inspection checklist, in order: who ran the test; which major version — a 9.x listing says nothing about 10.x; which tool version produced the report; and whether the suite can be re-run locally, so a modest lab can repeat the test instead of taking the listing on faith.

This is release change control applied to compatibility: a claim about a specific release needs evidence pinned to that release. Run the suite against the machine you operate, not the marketing slide.

The bar for enterprise Linux just moved

The quiet consequence is competitive. A distribution's certification programme used to be a moat: the vendor controlled who got tested, at what price, under what terms. AlmaLinux dismantled the moat by publishing the tooling and the results, and by treating community validation as first-class evidence that stacks with vendor and Foundation results.

The bar for every distribution claiming enterprise readiness is higher: with an open test kit, public results, and a named tester, a competing claim that cannot say who tested what against which release looks like an assertion without provenance. For EU procurement the catalogue maps onto the supply-chain scrutiny that NIS2-style diligence already demands — without ever claiming to replace FIPS or Common Criteria assurance.

The philosophy echoes the ownership and change-control debates we covered in Linux ownership governance and Ubuntu 26.10's feature freeze: governance in the open beats governance in a private queue. The kit is in users' hands; the honest move is to run it. New infrastructure analysis lands on neticslabs.com.

Sources

• AlmaLinux OS blog — "Software certification is here, and hardware certification takes under 10 minutes" — almalinux.org/blog/2026-09-24-certification-in-minutes/, 2026-09-24.
• The AlmaLinux Certification Program page — almalinux.org/certification/ (the compatibility statement and the FIPS 140-3 / Common Criteria distinction).
• catalog.almalinux.org — public certification catalogue (captured 2026-09-28).