The OneFS 9.15 release enjoys a substantial security boost with the upgrade of OpenSSL from version 3.0.13 to 3.5.5. In tandem with this, the FIPS (Federal Information Processing Standards) provider module is also uplifted from 3.0.9 to 3.1.2. This upgrade is particularly beneficial for customers running PowerScale in a security-conscious or compliance-driven environment. This article walks through the what, why, and how of the upgrade.
The OpenSSL 3.0 LTS stream reaches end-of-support in September 2026. Beyond this date it will receive no further security patches, CVE fixes, or maintenance updates from the upstream project. For a library that underpins virtually every cryptographic operation on a PowerScale cluster, from TLS handshakes to FIPS-compliant key management, remaining on an unsupported version would mean accumulated CVE exposure, static security scan failures, and potential compliance gaps in environments subject to government or industry mandates.
OpenSSL 3.5 is the next LTS release and is supported through April 2030, providing a further four years of patching headroom. The upgrade to 3.5.5 in OneFS 9.15 closes out ten CVEs carried in the 3.0 stream (one High severity, two Moderate, seven Low) and positions OneFS for the post-quantum cryptography work that will continue into the next release.
OpenSSL 3.x introduced a provider-based architecture that separates cryptographic algorithm implementations into loadable modules.
Architecturally, SSL comprises four fundamental layers:
| SSL Component | Description |
| Alert | Reports issues. |
| Change cipher spec | Implements negotiated crypto parameters. |
| Handshake | Negotiates crypto parameters for SSL session. Can be used for many SSL/TCP connections. |
| Record | Provides encryption and MAC. |
These reside within the stack as follows:
The basic handshake process begins with a client requesting an HTTPS WebUI session to the cluster. OneFS then returns the SSL certificate and public key. The client creates a session key, encrypted with the public key it’s received from OneFS. At this point, the client only knows the session key and it sends this encrypted session key to the cluster, which decrypts it using the private key. Now, both the client and OneFS know the session key so the session, encrypted via the symmetric key, can be established. OneFS automatically defaults to the best supported version of SSL, based on the client request.
This model was established in OpenSSL 3.0 and carries forward to 3.5 without structural change, so the upgrade from OneFS 9.10’s OpenSSL 3.0.13 to 9.15’s 3.5.5 does not alter the fundamental architecture that administrators are already familiar with.
Four providers are defined, each scoped to a different class of algorithms:
| Provider | Details |
| Default Provider | The general-purpose set of commonly used cryptographic algorithms. |
| Legacy Provider | Deprecated or insecure algorithms such as MD2 and RC4, retained for backward compatibility. |
| Base Provider | Key encoding and decoding operations; always loaded alongside the FIPS provider when FIPS mode is active. |
| FIPS Provider | The FIPS 140-3 validated implementation. In OneFS 9.15 this is module version 3.1.2, holding CMVP certificate #4985. |
Which providers are loaded at runtime is controlled by ‘/etc/ssl/openssl.cnf’, but in practice cluster admins never need to edit this file directly. OneFS manages provider selection through a higher-level abstraction: the FIPS mode toggle, exposed via the platform API (pAPI) or the gconfig switch. When FIPS mode is disabled, OneFS loads the Default and Legacy providers. When FIPS mode is enabled, it loads the FIPS and Base providers instead.
MCP (the Master Control Program) handles the mechanics of a FIPS mode change, dynamically rewriting the ‘/etc/ssl/fips_dynamic.cnf’ config file to reflect the new provider selection, and then restarting all affected daemons and services. This means a FIPS pAPI or gconfig toggle is applied cluster-wide without requiring manual intervention on individual nodes.
The SSL version jump from 3.0.13 to 3.5.5 is significant from a support and security perspective, but, for day-to-day cluster administration, the surface area of change is intentionally small. Unlike the update from SSL 1.0.2 to 3.0 in OneFS 9.10, which required substantive code changes across OneFS due to API differences, the 3.0 to 3.5 path is a within-major-version update. There are no new cryptographic providers, no new OneFS-specific protocols, and no new data structures introduced.
The one behavioral change worth noting explicitly is a default cipher update for the following OpenSSL command-line utilities: ‘openssl req’, ‘openssl cms’, and ‘openssl smime’. In 3.5, these commands default to AES-256-CBC instead of the older 3DES (des-ede3-cbc). This is a command-line default only, and neither impacts the cipher negotiation behavior for any OneFS protocol or service, nor affects stored data or existing configurations.
On the FIPS side, the module version advances from 3.0.9 to 3.1.2, the highest FIPS 140-3 certified version available at the time the work was undertaken (CMVP certificate #4985). Existing FIPS mode settings are preserved across upgrade, and OneFS does not automatically enable or disable FIPS mode when nodes reboot into 9.15.
For reference, the following table includes the full set of OneFS subsystems with a direct OpenSSL or libcrypto dependency, grouped by functional area.
| Functional Area | Details |
| AIMA | Local Provider, File Provider, LDAP, AD, Key Manager, Kerberos, mod_auth_isilon |
| Data Mobility | Cloudpools, SyncIQ, Data Mover |
| Infrastructure | Licensing, Upgrade, Patches, HealthCheck, Quota Notifier |
| Other | PAPI, WebUI, Audit Syslog Forwarder, FreeBSD Userspace, CEE
Many other system components/utilities link to openssl / libcrypto (see output of ‘ldd …’) |
| Platforms | Host Operating System Agent (HOSA), Power Tools Agent (PTA) |
| Protocols | S3, SMB, NFS, HDFS/WebHDFS, RDR, Secure Channel, RAN, SSH/SFTP |
| Supportability | isi_gather_info, Outgoing E-mail (Implicit TLS / port 465) |
Upon upgrading to OneFS 9.15, OpenSSL 3.5 takes effect immediately when a node reboots into 9.15 or later, and the previous version is removed from the node at that point. As such, there is no deferred activation or option to retain the old library. Service continuity during the non-disruptive upgrade (NDU) window is maintained in the same way as any other OneFS component upgrade.
During a mixed-version upgrade window, nodes that have rebooted into OneFS 9.15 run binaries compiled against OpenSSL 3.5, while nodes still on an older build continue to use their compiled-in version. Interoperability between the two is maintained, with TLS handshakes between nodes at different OpenSSL versions completing successfully. SyncIQ and SmartSync replication to clusters running older OneFS versions are also unaffected. MCP correctly manages FIPS mode state on both upgraded and non-upgraded nodes throughout the transition.
After upgrade, the following CLI commands can be used to confirm the expected state, including:
To verify OpenSSL library version:
# openssl version OpenSSL 3.5.5 27 Jan 2026 (Library: OpenSSL 3.5.5 27 Jan 2026)
Check FIPS mode status:
# isi security settings view | grep -i fips FIPS Mode Enabled: Yes
List loaded providers (FIPS mode disabled):
# openssl list -providers Providers: default legacy
Verify FIPS provider version (FIPS mode enabled):
# openssl list -providers -provider fips Providers: fips version: 3.1.2
Test TLS connectivity to a specific endpoint:
# openssl s_client -connect <host>:<port>
Additionally, no new log files are created by the OpenSSL upgrade, so troubleshooting continues to use the standard OneFS log locations.
One of the motivations for incorporating OpenSSL3.5 into OneFS is that it provides the foundation for post-quantum cryptographic (PQC) algorithm support. OpenSSL 3.5 includes early implementations of the NIST-selected PQC algorithms (ML-KEM and ML-DSA among them) that will be needed as organizations begin preparing for the eventual deprecation of RSA and elliptic-curve cryptography in the face of quantum computing advances.
No PQC algorithms are exposed to PowerScale cluster users in OneFS 9.15, since the OpenSSL 3.5 upgrade is the enabling step, not the delivery. Integration of PQC into specific OneFS protocol and service layers is planned for a future release.
The OpenSSL 3.5 upgrade in OneFS 9.15 is primarily a forward-looking security and supportability move. Remaining on OpenSSL 3.0 past September 2026 would mean accumulating unpatched CVEs, failing static security scans, and losing access to maintenance fixes from the upstream project. The 3.5 LTS stream extends support coverage to April 2030 and closes ten CVEs already in the 3.0 stream.
For cluster admins, the operational footprint of this change is minimal. The provider architecture is unchanged, FIPS mode is preserved across upgrade, no new configuration is required, and the upgrade proceeds through the normal NDU path. The one behavioral change, the AES-256-CBC default for openssl command-line utilities, is narrow in scope and unlikely to affect most environments.