# HOWTO: Install wolfSSL FIPS-eval on RHEL / Rocky / AlmaLinux / CentOS Stream This guide walks through installing the wolfSSL Full Linux FIPS-eval channel on the RHEL-family ecosystem: RHEL 9 or 10, Rocky Linux 9 or 10, AlmaLinux 9 or 10, and CentOS Stream 9 or 10. The same rpms install on all of these. ## READ THIS FIRST **This is a demo and presales evaluation channel. It is NOT supported and is NOT for production use.** The packages installed by this channel are NOT the FIPS-certified wolfCrypt bundle. They are an unsupported best-effort build of the upstream open-source wolfSSL that approximates the wolfCrypt FIPS 140-3 algorithm boundary (certs #4718 and #5041) so you can evaluate the interface and integration story before purchasing the real thing. The wolfCrypt cryptography engine itself is dual-licensed: **GPL-3.0 or commercial**. The GPL-3.0 build available through this channel carries copyleft obligations. If GPL-3.0 is incompatible with your product or distribution model, you need the commercial license. **For supported FIPS 140-3 validated wolfCrypt, production licensing, FIPS certificate and Operational Environment (OE) work, and any production support: contact wolfSSL Inc. See "Getting help, support, sales, licensing, and FIPS certification" at the bottom of this document.** FIPS-eval is unsupported. Use it to evaluate, demo, and prototype, and then talk to us. ## Supported platforms | EL major | Architecture | Tested on | |----------|--------------|--------------------------| | 9 | x86_64 | Rocky 9.7, AlmaLinux 9.7 | | 9 | aarch64 | Rocky 9.7, AlmaLinux 9.7 | | 10 | x86_64 | Rocky 10.1, AlmaLinux 10.1 | | 10 | aarch64 | Rocky 10.1, AlmaLinux 10.1 | The same `.el9` and `.el10` rpms install on Rocky, Alma, CentOS Stream, and RHEL at the same major version. This is by design: the RHEL ecosystem is binary-compatible across rebuilds at the major-version level, so we ship one set of rpms per (major, arch). If you are on a derivative we haven't explicitly tested (Oracle Linux, Springdale, EuroLinux, etc.), the bootstrap script falls back to checking `ID_LIKE` for `rhel`, `centos`, or `fedora-core`. If your distro matches any of those, the install should work. If it doesn't, contact us — odds are the fix is one line in the detection logic. ## Quick start On a fresh EL 9 or 10 machine, as root (or via `sudo`): ``` curl -fsSL https://fips-eval.wolfssl.com/install | sudo bash sudo dnf install wolfssl-fips-eval-el9 # or -el10 ``` That's it. Two lines. The first line configures `dnf` to trust the wolfSSL FIPS-eval repository. The second line installs the meta-package, which pulls in wolfSSL, wolfProvider, and the trust anchor for the repo. ### Container image artifacts Pre-built OCI container images are available today for **Debian** only (Trixie and Bookworm, both `linux/amd64` and `linux/arm64`). See [HOWTO-oci.md](HOWTO-oci.md) for the Debian container recipe. EL (RHEL/Rocky/Alma/CentOS Stream) OCI images are on the roadmap; no release date is committed. If you need an EL container artifact today, build one locally from the dnf flavor. Two-line `Dockerfile` against the stock Rocky Linux 9 base image (substitute `almalinux:9`, `rockylinux:10`, or `almalinux:10` as needed; UBI and RHEL base images work the same way): ```dockerfile FROM rockylinux:9 RUN curl -fsSL https://fips-eval.wolfssl.com/install | bash \ && dnf install -y wolfssl-fips-eval-el9 \ && dnf clean all ``` Or `FROM rockylinux:10` + `wolfssl-fips-eval-el10` for EL 10. `docker build .` produces an image functionally equivalent to the Debian pre-built OCI artifacts — same wolfssl/wolfprov build, same algorithm surface, same caveats. Works equally on UBI (`registry.access.redhat.com/ubi9/ubi`), plain RHEL containers, AlmaLinux containers, and Rocky containers. ## What the bootstrap script does The `curl | bash` line runs [`install-bootstrap.sh`](https://fips-eval.wolfssl.com/install) which: 1. Detects you're on a RHEL-family system by reading `ID` from `/etc/os-release` and matching against `rhel`, `rocky`, `almalinux`, or `centos`. As a fallback for less common derivatives, it checks `ID_LIKE` for `rhel`, `centos`, or `fedora-core`. 2. Detects the EL major version from `VERSION_ID` (e.g. `9.7` → major `9`; `10.1` → major `10`) and the CPU architecture from `uname -m`. 3. Downloads the signed `wolfssl-fips-eval-archive-keyring-latest.elN.noarch.rpm` for your EL major version. 4. Runs `rpm -Uvh --force` to install the keyring. The rpm's `%post` scriptlet runs `rpm --import` on the included armored OpenPGP public key, so dnf can verify repository metadata against the wolfSSL FIPS-eval signing key. 5. Writes `/etc/yum.repos.d/wolfssl-fips-eval.repo` with `repo_gpgcheck=1` (signed `repomd.xml.asc` verified on every refresh) and `gpgcheck=0` (per-rpm signing is a known follow-up; the signed repomd contains the SHA-256 of every package, providing transitive integrity). The bootstrap script does NOT install any cryptography packages itself. That step is explicit: you run `dnf install ...` only after you've read this far. ## What gets installed by the meta-package `sudo dnf install wolfssl-fips-eval-el9` (or `-el10`) installs: - **wolfssl 5.9.1** (`-1.fipseval1.el9` or `.el10`): the wolfSSL TLS/SSL + wolfCrypt cryptography library, built with the FIPS-approximating configure flags. LTO is disabled in the spec because EL 10's `redhat-hardened-cc1` LTO configuration breaks linking of wolfSSL's ECC symbols; the disable is universal across all our EL builds for consistency. - **libwolfprov 1.1.1** (`-1.fipseval1.elN`): the OpenSSL 3.x provider that routes OpenSSL crypto calls into wolfSSL. Installs at `/usr/lib64/ossl-modules/libwolfprov.so` and drops a provider configuration snippet at `/etc/pki/tls/openssl.cnf.d/wolfprovider.conf`. - **wolfssl-fips-eval-archive-keyring**: the repository trust anchor. - **cryptsetup, krb5-libs, openssh-clients**: stock EL packages, pulled in as `Requires` so the meta-package represents the full cryptographic userspace stack. Stock EL packages are used as-is; we do not ship patched variants on the EL channel. - **openssh-server, x11vnc**: pulled in as `Recommends`. To skip these, use `dnf install --setopt=install_weak_deps=False ...`. If you only want the wolfSSL libraries and not the broader userspace: ``` sudo dnf install wolfssl libwolfprov ``` ## Activating wolfProvider system-wide After install, wolfProvider is on disk but not yet wired into the system OpenSSL configuration. There are three ways to use it. ### Option 1: Per-command (recommended for first evaluation) Set `OPENSSL_CONF` for the command you want to test: ``` OPENSSL_CONF=/etc/pki/tls/openssl.cnf.d/wolfprovider.conf openssl list -providers ``` You should see: ``` Providers: libwolfprov name: wolfSSL Provider version: 1.1.1 status: active ``` If you see only the OpenSSL `default` provider, wolfProvider is not loading; check `/etc/pki/tls/openssl.cnf.d/wolfprovider.conf` exists and `/usr/lib64/ossl-modules/libwolfprov.so` is present. This `OPENSSL_CONF` environment variable works for any application that uses `libcrypto.so.3` through normal env var handling. ### Option 2: System-wide Add this line to the bottom of `/etc/pki/tls/openssl.cnf`: ``` .include /etc/pki/tls/openssl.cnf.d/wolfprovider.conf ``` After this, every OpenSSL-using application on the system routes through wolfProvider unless it explicitly overrides `OPENSSL_CONF`. This is consequential, especially on RHEL and Rocky/Alma where many system services are configured through Red Hat's crypto-policies framework (`update-crypto-policies(8)`). Layering wolfProvider on top is supported but means two systems are active simultaneously. Test in a non-production environment first. ### Option 3: Application-level If you're a developer integrating wolfProvider into your own application, create a dedicated OpenSSL library context and load the provider explicitly: ```c #include OSSL_LIB_CTX *ctx = OSSL_LIB_CTX_new(); OSSL_PROVIDER *prov = OSSL_PROVIDER_load(ctx, "libwolfprov"); /* ... use ctx ... */ OSSL_PROVIDER_unload(prov); OSSL_LIB_CTX_free(ctx); ``` This avoids modifying global state and lets you A/B-test wolfProvider against the default provider in the same process. ## Verifying the install A successful `dnf install` already proves repository trust: dnf verified the `repomd.xml.asc` signature against the imported wolfSSL FIPS-eval key before fetching any package. Beyond that: ### Verify the library is installed ``` rpm -qa | grep -E '^(wolfssl|libwolfprov)' ``` You should see at minimum: - `wolfssl-5.9.1-1.fipseval1.elN.` - `libwolfprov-1.1.1-1.fipseval1.elN.` - `wolfssl-fips-eval-archive-keyring-2026.05.23-1.elN.noarch` ### Verify the library exposes the public SP math API ``` nm -D /usr/lib64/libwolfssl.so.44 | grep -c " T sp_" ``` This should return `73` on both x86_64 and aarch64. ### Verify a real crypto operation goes through wolfSSL ``` OPENSSL_CONF=/etc/pki/tls/openssl.cnf.d/wolfprovider.conf \ openssl list -digest-algorithms | grep wolfprov ``` You should see entries like: ``` { 2.16.840.1.101.3.4.2.1, SHA2-256, SHA-256, SHA256 } @ libwolfprov { 2.16.840.1.101.3.4.2.2, SHA-384, SHA2-384, SHA384 } @ libwolfprov ``` The `@ libwolfprov` suffix means OpenSSL is routing these algorithm requests into wolfProvider, which routes them into wolfSSL. ### Verify with ltrace (deep proof) ``` sudo dnf install -y ltrace OPENSSL_CONF=/etc/pki/tls/openssl.cnf.d/wolfprovider.conf \ ltrace -e 'wc_*+wolfSSL_*+sp_*' -c \ openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-384 -out /tmp/key.pem 2>&1 | tail -25 ``` You should see thousands of calls to `wc_ecc_*`, `sp_to_unsigned_bin`, `sp_init`, etc. — wolfCrypt's internal ECC and SP-math API. ### Same rpms on Rocky AND AlmaLinux This channel is verified to install the same artifacts on both Rocky 9.7 and AlmaLinux 9.7, and the same artifacts on both Rocky 10.1 and AlmaLinux 10.1. The `.el9` / `.el10` rpms have no Rocky-specific or Alma-specific `Requires`, so they install cleanly on either side of the ecosystem at the matching major version. CentOS Stream and RHEL itself should behave the same way at each major. ## What FIPS-eval is NOT (the honest list) This is not optional reading. Every bullet matters. - **It is not a FIPS 140-3 validated cryptographic module.** It is an open-source wolfSSL build that approximates the validated module's algorithm set so you can evaluate the interface and integration story. Production deployments that require FIPS validation must use the certified wolfCrypt module, which is a separate purchase. The CMVP-issued FIPS 140-3 certificates referenced by this channel (#4718, #5041) cover that certified module, NOT this evaluation build. - **It is not the actual FIPS-certified bundle.** A FIPS-certified deployment requires the certified wolfCrypt module source, the matching Operational Environment (OE) from the CMVP certificate, and in many cases an OE add to extend the certificate to your specific platform. None of that is in this channel. - **It is not supported.** No SLA, no CVE response process, no support pipeline. - **It is not for production.** Treat it as a demo binary. Use it on evaluation laptops, lab machines, and CI sandboxes. Do not deploy it to anything that processes real data, real traffic, or real customers. - **It does not include FIPS-mode operational self-tests.** The certified wolfCrypt module includes power-on self-tests, continuous random-number-generator health tests, and integrity checking of the cryptographic boundary. This evaluation build does not run those tests at startup. - **The license is GPL-3.0.** wolfCrypt and wolfSSL are dual-licensed: GPL-3.0 OR commercial. The build distributed by this channel is the GPL-3.0 build. If GPL-3.0 copyleft is incompatible with your product, you need a commercial license — contact wolfSSL. - **It does not coordinate with `update-crypto-policies`.** Red Hat's crypto-policies framework manages system-wide OpenSSL configuration via `/etc/crypto-policies/`. wolfProvider lives parallel to that system: if you set `OPENSSL_CONF` or add the `.include` line, our provider loads regardless of what crypto-policies has done. For evaluation this isolation is a feature; for production it is a design decision your team should make explicitly — and production needs the supported product anyway. - **We do not ship patched cryptsetup, openssh, krb5, or x11vnc on EL.** Stock EL packages are used as-is. The Debian channel ships Mode-2-minimal patches for those four apps; the EL channel does not (Red Hat's crypto-policies framework already handles much of what those patches do, and porting the patches to EL's heavily-patched srpms is a larger project — contact wolfSSL if you need it). - **The repository is not yet per-rpm signed.** The `repomd.xml.asc` IS signed, providing transitive integrity via SHA-256 of every package. Per-rpm embedded signing is a planned follow-up. For an unsupported evaluation channel this is acceptable; for production this would need to be addressed — which is another reason production needs the supported product, not this channel. If your evaluation hits a question like "does this exact configuration pass FIPS 140-3 algorithm testing," the answer is: not from this channel. Contact wolfSSL — see the next-to-last section of this document — to discuss what would. ## Removing the FIPS-eval channel ``` sudo dnf remove \ wolfssl-fips-eval-el9 wolfssl-fips-eval-el10 \ wolfssl libwolfprov wolfssl-fips-eval-archive-keyring sudo rm -f /etc/yum.repos.d/wolfssl-fips-eval.repo sudo rpm -e gpg-pubkey-fa9ac3974b0099d415c7367319d1f0db1f304c7b 2>/dev/null ``` The stock-EL `cryptsetup`, `krb5-libs`, `openssh-*`, and `x11vnc` packages remain installed; we did not patch them, so there's nothing to revert. ## Getting help, support, sales, licensing, and FIPS certification This channel is unsupported. For everything that matters in a real deployment — support, production licensing, the actual FIPS-certified code, an actual FIPS certificate, and Operational Environment (OE) work to extend that certificate to your platform — talk to wolfSSL Inc. **Contact wolfSSL:** - Email: - Phone: +1 425 245 8247 - Web: - Products: - FIPS 140-3 information: - Licensing: - Support & Maintenance: **Download the supported, licensed wolfSSL:** **For reference, in case you want to inspect this evaluation channel:** - Repository status page: - Repository signing key fingerprint: `FA9A C397 4B00 99D4 15C7 3673 19D1 F0DB 1F30 4C7B` (ECDSA P-384, anchored in AWS KMS). - The bootstrap script's source is at . Read it before piping to bash.