Configuring Entropy on CentOS7/RockyLinux8 for FIPS OpenSSL
Introduction
The FIPS openssl version is built with strict requirements for entropy to provide the necessary security guarantees. It fills up "pools" of truly random numbers when it starts up. If these pools aren't filled, applications that call the openssl library get blocked until enough random material is gathered to proceed. Regular openssl behaves differently: if it can't get enough true randomness, it falls back to pseudorandomness and continues. It's important to understand that FIPS isn't meant to run in pieces. It's a holistic system. The kernel provides the entropy to the openssl library through the getrandom() system call.
The Rocky Linux 9 kernel (and upstream 5.10, 5.15, and later kernels) generally provide enough entropy more or less built-in. CentOS 7 (kernel 3.10) and Rocky Linux 8 (kernel 4.18) don't in some cases, and the shortage is most visible on virtualized or headless systems that lack a good hardware entropy source. When the pool runs dry, the FIPS cryptographic path is the first thing to stall, and it can surface in several different ways.
Problem
The FIPS openssl build enforces strict entropy requirements, so on startup and during key operations it draws truly random material from the kernel through getrandom(). If the kernel entropy pool has not gathered enough material, that call blocks until more is available. Because FIPS does not degrade to pseudorandomness the way the non-FIPS libraries do, a slow or starved pool surfaces as a hang or a hard failure rather than a slowdown.
Virtualized guests are a common trigger. A VM has no direct access to physical hardware entropy sources, so it depends on the hypervisor and the host to keep its pool topped up. When the host itself is entropy-starved, it cannot feed its guests, and any FIPS cryptographic operations running in those guests can stall.
Symptoms
The starvation shows up in a few different ways depending on what calls into the FIPS openssl library first.
dnf metadata downloads time out because the TLS connection cannot complete:
dnf list
Rocky Linux BaseOS 0.0 B/s | 0 B 17:45
Errors during downloading metadata for repository 'baseos':
- Curl error (28): Timeout was reached for https://.../BaseOS/x86_64/os/repodata/repomd.xml [SSL connection timeout]
- Curl error (28): Timeout was reached for https://.../BaseOS/x86_64/os/repodata/repomd.xml [Operation timed out after 99165 milliseconds with 0 out of 0 bytes received]
Error: Failed to download metadata for repo 'baseos': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
sshd may freeze on startup, preventing remote access to the system.
An application doing TLS fails from the application layer with an OpenSSL EOF error, often intermittently or under load, and early in the process's life:
EOF occurred in violation of protocol (_ssl.c:1149)
The tell that this is entropy and not a network or certificate problem is where the process is blocked. Attaching strace shows it stuck in getrandom() rather than in a network or socket call:
strace -f -p <PID>
You can confirm the pool is low by reading the available entropy on the affected system. A healthy pool is typically in the thousands; a value that sits in the low hundreds or keeps dropping under load points to starvation:
cat /proc/sys/kernel/random/entropy_avail
Resolution
Install rng-tools and enable the rngd daemon so it feeds extra, high-quality entropy into the kernel pool, preventing it from becoming exhausted.
On a Rocky Linux 8 system:
dnf install rng-tools
systemctl enable --now rngd
Apply the fix on the layer that is actually starved. If a hypervisor host is failing to supply entropy to its guests, enabling rngd on the host resolves the problem for every VM it hosts. Likewise, if you run containers with the FIPS openssl library installed, enable rngd on the host, not inside the container. On a CentOS 7 host:
yum install rng-tools
systemctl enable --now rngd
After rngd is running, restart the affected application or service and confirm that the TLS handshake completes and that entropy_avail stays healthy under load.
Root Cause
FIPS-compliant cryptography imposes stricter entropy requirements than the default configuration, and it blocks waiting for the kernel pool rather than falling back to pseudorandomness. The FIPS openssl library called getrandom(), the kernel could not satisfy the request because the pool was depleted, and the call blocked. To whatever was calling in, that stall surfaced as a dnf/TLS timeout, a frozen sshd, or an EOF occurred in violation of protocol (_ssl.c:1149) error.
On virtualized systems the shortage originates at the virtualization layer: the guest has no direct hardware entropy source and depends on a host that is not supplying enough. That is also why the non-FIPS libraries do not fail in the same conditions, because they degrade to pseudorandomness instead of blocking. Running rngd restores a steady supply of entropy and clears the failure.
Notes
Newer Rocky Linux kernels generally provide adequate entropy without extra tuning, so this problem is most common on older kernels (CentOS 7 and Rocky Linux 8) and in virtualized or headless environments that lack a good hardware entropy source. If you run FIPS workloads on VMs, treat entropy provisioning as part of the build: enable rngd on the guests, and make sure the hypervisor host is not itself starved.