Manual Chapter : Platform FIPS Overview

Applies To:

  • BIG-IP APM

    17.1.0

  • BIG-IP LTM

    17.1.0

  • BIG-IP DNS

    17.1.0

  • BIG-IP ASM

    17.1.0

back-action F5 Platforms: FIPS Administration

Platform FIPS Overview

Updated Date: 02/13/2026

The FIPS BIG-IP Platform Module solution, also known as Platform FIPS, is a FIPS validated BIG-IP system. The platform FIPS requires a F5 Full-Box FIPS add-on license and allows for FIPS 140-3 validation at level 2 while using the full performance capabilities of the BIG-IP system.

The platform FIPS provides device-level FIPS validation at level 2 for specific BIG-IP platforms with the Full-Box FIPS add-on license installed. Introduced in BIG-IP 13.1.0, the Full-Box FIPS license includes a FIPS installation kit that contains tamper-evident stickers that you must apply to the hardware device in order to be FIPS validated products.

BIG-IP systems with the Full-Box FIPS add-on license installed enter a FIPS-enabled mode during the boot process. When the BIG-IP system enters FIPS-enabled mode, the system changes the SSL cipher suites to be FIPS-compliant and enables the FIPS required self-tests to validate the integrity and operation of the system. If the system fails any of the self-tests during the boot process the BIG-IP system halts.

The Full-Box add-on license can be installed on any BIG-IP hardware platforms running the BIG-IP software version 13.1.0 or later for FIPS compliance, but only specific BIG-IP platforms and versions have been validated for FIPS. For more information about FIPS validated platforms and versions, see the security policy and certificates for your platform at F5 Certifications.

When a system is in FIPS-enabled mode, the FIPS module information displays in the command-line interface and web-based user interface.

These are the FIPS module names:

  • Cryptographic Module for BIG-IP
  • F5 Device Cryptographic Module
  • F5 vCMP Cryptographic Module

These options enable you to verify FIPS-enabled mode on BIG-IP systems:

  • Use the database (db) variable security.fips140.compliance to check if the system is in FIPS-enabled mode.
  • Use the Linux command cat on the /config/f5_public/fips.conf file. If the response is 1, then the FIPS-enabled mode is enabled. If the response is 0, an empty file, or no file is available, then FIPS-enabled mode is disabled.

These options enable you to verify FIPS module information on BIG-IP systems:

  • In the BIG-IP Configuration utility, the FIPS module information is displayed in the Version field at Systems > Configuration > Device > General.
  • Use the tmsh show sys version command sequence to display the FIPS module information, along with other system information.

The FIPS service indicator shows whether sessions are established using FIPS approved or non-approved cryptographic algorithms. The service indicator session information is collected and logged only when a FIPS 140-3 license is installed on a BIG-IP system. A service indicator is logged in /var/log/audit logs, any time an approved service is established using the CLI or the web-based user interface.

With a FIPS 140-3 license, management plane GUI and SSH sessions are created in FIPS and allow only the usage of FIPS 140-3 approved ciphers. For more information, see FIPS supported ciphers.

These are supported SSH ciphers:

Ciphers MACS Kex Algorithms
aes128-ctr

|hmac-sha1

|ecdh-sha2-nistp256 |aes256-ctr

|hmac-sha2-256

|ecdh-sha2-nistp384 |aes128-cbc

| | | |aes256-cbc

| | |

You can configure the BIG-IP system to enable service indicator logs for dataplane services in High-Speed Logging (HSL).

At a high level, these tasks enable service indicator logs:

  • Configure a remote syslog server, for example Splunk, rsyslog, ipfix, or ArcSight.
  • Configure a high-speed remote logging, which includes these tasks:
    • Create a node.
    • Create a pool of remote logging servers.
    • Create a remote high-speed log destination.
    • Create a formatted remote high-speed log destination.
    • Create a publisher.
  • Verify if the log level is set to Notice or higher in SSL field at System > Logs > Configuration > Options.
  • Verify if the configured log publisher is selected in client SSL and server SSL profiles at Local Traffic > Profiles > SSL.

Local traffic pools use nodes as target resources for load balancing. A node is an IP address or a fully-qualified domain name (FQDN) that represents a server resource that hosts applications.

Note: An alternate way to create a node is to create a pool member. When you create a pool member, the BIG-IP system creates the corresponding node for you.

  1. On the Main tab, expand Local Traffic, and click Nodes.

    The Node List screen opens.

  2. Click the Create button.

    The New Node screen opens.

  3. For the Address field:

    1. If you want to specify the node by its IP address, click Nodes and type an IP address.

    2. If you want to specify the node by a fully-qualifed domain name (FQDN), click FQDN and type the node’s FQDN.

  4. In the Configuration area of the screen, configure the settings as needed or retain the default values.

  5. If you chose FQDN for the Address setting, then in the FQDN area of the screen, configure the settings as needed or retain the default values.

  6. Click Finished.

    The screen refreshes, and the new node appears in the node list.

Before creating a pool of log servers, gather the IP addresses of the servers that you want to include in the pool. Ensure that the remote log servers are configured to listen to and receive log messages from the BIG-IP system.

Create a pool of remote log servers to which the BIG-IP system can send log messages.

  1. On the Main tab, click Local Traffic > Pools.

    The Pool List screen opens.

  2. Click Create.

    The New Pool screen opens.

  3. In the Name field, type a unique name for the pool.

  4. Using the New Members setting, add the IP address for each remote logging server that you want to include in the pool:

    1. Type an IP address in the Address field, or select a node address from the Node List.

    2. Type a service number in the Service Port field, or select a service name from the list.

      Note: Typical remote logging servers require port 514.

    3. Click Add.

  5. Click Finished.

Before creating a remote high-speed log destination, ensure that at least one pool of remote log servers exists on the BIG-IP system.

Create a log destination of the Remote High-Speed Log type to specify that log messages are sent to a pool of remote log servers.

  1. On the Main tab, click System > Logs > Configuration > Log Destinations.

    The Log Destinations screen opens.

  2. Click Create.

  3. In the Name field, type a unique, identifiable name for this destination.

  4. From the Type list, select Remote High-Speed Log.

    Important: If you use log servers such as Remote Syslog, Splunk, or ArcSight, which require data be sent to the servers in a specific format, you must create an additional log destination of the required type, and associate it with a log destination of the Remote High-Speed Log type. With this configuration, the BIG-IP system can send data to the servers in the required format.

    The BIG-IP system is configured to send an unformatted string of text to the log servers.

  5. From the Pool Name list, select the pool of remote log servers to which you want the BIG-IP system to send log messages.

  6. From the Protocol list, select the protocol used by the high-speed logging pool members.

  7. Click Finished.

Ensure that at least one remote high-speed log destination exists on the BIG-IP system.

Create a formatted logging destination to specify that log messages are sent to a pool of remote log servers, such as Remote Syslog, Splunk, or IPFIX servers.

  1. On the Main tab, click System > Logs > Configuration > Log Destinations.

    The Log Destinations screen opens.

  2. Click Create.

  3. In the Name field, type a unique, identifiable name for this destination.

  4. From the Type list, select a formatted logging destination, such as Remote Syslog, Splunk, or IPFIX.

    The Splunk format is a predefined format of key value pairs.

    The BIG-IP system is configured to send a formatted string of text to the log servers.

  5. If you selected Remote Syslog, then from the Syslog Format list select a format for the logs, and then from the High-Speed Log Destination list, select the destination that points to a pool of remote Syslog servers to which you want the BIG-IP system to send log messages.

    Important: For logs coming from Access Policy Manager (APM), only the BSD Syslog format is supported.

  6. If you selected Splunk or IPFIX, then from the Forward To list, select the destination that points to a pool of high-speed log servers to which you want the BIG-IP system to send log messages.

  7. Click Finished.

Ensure that at least one destination associated with a pool of remote log servers exists on the BIG-IP system.

Create a publisher to specify where the BIG-IP system sends log messages for specific resources.

  1. On the Main tab, click System > Logs > Configuration > Log Publishers.

    The Log Publishers screen opens.

  2. Click Create.

  3. In the Name field, type a unique, identifiable name for this publisher.

  4. For the Destinations setting, select a destination from the Available list, and click « to move the destination to the Selected list.

    Note: If you are using a formatted destination, select the destination that matches your log servers, such as Remote Syslog, Splunk, or ArcSight.

  5. Click Finished.

The Platform FIPS system includes the Full-Box FIPS add-on license, which includes tamper evidence seals that you must apply to the chassis for it to be FIPS-validated. For more information, see F5 Platforms: FIPS Kit Installation at my.f5.com.

F5 recommends these best practices for working with your Platform FIPS system:

Backup partitions
To recover from a self-test failure, F5 recommends that you have at least two volumes configured and set up with the software version that you are using on the BIG-IP system. If possible, you should avoid installing the Platform FIPS add-on license on the backup volume. This provides recovery options from a failed self-test.

Note: The BIG-IP system should have multiple volumes set up from the factory, but the software versions installed might not support the Platform FIPS license. Be sure to verify the versions before placing the BIG-IP system into production use.

The sys-eicheck utility
Use the sys-eicheck utility to determine, without rebooting and locking the volume, if anything has happened that might cause the integrity test to fail. Run this utility before and after any administrative actions to identify anything that might cause a self-test failure by typing this command sequence on the command line: /usr/libexec/sys-eicheck.py.
FIPS Validated vCMP Guests
On certain BIG-IP platforms and VIPRION platforms that are licensed with the Platform FIPS add-on license, any vCMP guests are also considered vCMP validated. Unless the platform is also an Embedded FIPS platform, no additional administration is needed. For more information, see the FIPS multi-tenancy for vCMP guests overview.

The NIST 140-3 FIPS standards require that the system must pass a series of self tests during operation and at initial startup. If any of these self-tests fail, the BIG-IP system restarts and will not be able to boot into that volume at startup.

One of the self-tests that the system performs is a system integrity test. This test watches for unauthorized changes to the system. Making changes to the system using the F5 TMOS Shell (tmsh), the Configuration utility, and the F5 APIs does not cause this test to fail. Making any changes to the underlying operating system or any BIG-IP files directly, however, might cause the test to fail.

The FIPS validation requires the use of self tests to check the integrity and operation of the cryptographic module. If any of these tests fail during the boot process, the BIG-IP system halts. The fips_monitor daemon is introduced in BIG-IP software version 13.1.0 and monitors the /config/f5_public/fipserr file for any reported errors. The fips_monitor daemon monitors the BIG-IP system and halts the system if FIPS-specified issues are found. This table explains the three basic categories of tests and the action taken when a test fails.

Type of self test When the self test runs Checks performed Action on fail
System Integrity check (sys-eicheck) - On start
- Daily using a cron job
- Manually
Checks the system software on the BIG-IP system to detect unexpected changes to the system software, such as modified or missing critical and non-critical files. If the test fails during the boot process, the details are logged to the /config/f5_public/fipserr file, and the BIG-IP system immediately halts. If the test fails at any other time, this error message displays in the var/log/secure file, and the system halts on the next restart:<datetime> <pid> crit root: BIG-IP Integrity Check: [FAIL] -- Contact F5 technical support. Crypto-Algorithm check - On start

|Checks the SSL cryptographic libraries to ensure they are correctly performing cryptographic operations.|Details are logged to the /config/f5_public/fipserr file, and the BIG-IP system immediately halts.| |TMM check|- On start
- When TMM errors occur during normal operation |Checks the Traffic Management Microkernel (TMM) for problems.|Details are logged to the /config/f5\_public/fipserr file, and the BIG-IP system immediately halts.|

If the BIG-IP system halts during the boot process, this message appears on the console indicating the system halted due to a failure of one of the pre-operational self-tests:

*** FIPS or Common Criteria  pre-operational self-test failure.
*** This system has been placed in an error state.
*** To recover return to the grub menu and select another volume.
*** or reinstall the system.
***
*** On many devices pressing the escape key followed by the (
*** key will bring up a menu which allows the system to be restarted.

If the BIG-IP system halts during the boot process you must either boot to another volume or reinstall the system software to recover and reload the configuration. If your BIG-IP system failed a system integrity check and is still running, you should run the sys-eicheck utility manually (/usr/libexec/sys-eicheck.py) and correct any problems before restarting the system. If you suspect your system is compromised, you should follow your organization’s security policies for suspected compromised systems.

Power-up self-test failures:
<specific test failures>

Note: For Platform FIPS systems, output from the sys-eicheck utility is included by default in the /fips_module.xml file when running the qkview utility. Other systems can capture the output from the sys-eicheck utility when running the qkview utility by running the qkview -c command.

A cryptographic module performs power-up self-tests and conditional self-tests to ensure that the module is functioning properly. The module performs power-up self-tests when the cryptographic module is powered up and conditional self-tests when an applicable security function or operation is invoked, that is, the security functions for which self-tests are required.

If a cryptographic module fails a self-test, the module enters an error state mode and outputs an error indicator through the status output interface. The cryptographic module does not perform any cryptographic operations while in an error state mode. All data output through the data output interface is inhibited when an error state exists. If a self-test fails, make sure that no cryptographic operations are performed.

The BIG-IP system attempts to recover from error state mode by triggering a reboot. If the error state persists after multiple reboots, then the system falls back to the brick the box state.

When determining whether your system is compromised, consider these factors:

  • F5 might not be able to make a final determination whether a device is compromised if it requires deeper forensic analysis than F5 support procedures allow. If this occurs, you should contact a trusted forensic security firm for a final determination of whether the device is compromised.
  • For integrity check issues, you should base your final determination on whether your BIG-IP system is compromised based on your organization’s security policy. If you are unable to determine any known administrative changes that happened during the failure time window, you should review and follow your organization’s policies and procedures for suspected compromised devices.
  • For cryptographic and Traffic Management Microkernel (TMM) self-test issues, you should base your final determination on whether your system is compromised based on your organization’s security policy; however, these issues are less likely to happen due to your system being compromised than due to other issues. If this occurs, contact F5 Support to determine whether the cause of the issue is due to a known issue or system bug.

On BIG-IP systems that include the F5 Full-Box FIPS add-on license, you can manually perform FIPS integrity checks. The system automatically performs scheduled checks on a regular basis. Manual check results display on the console, and scheduled checks log to the /var/log/secure file. If an integrity check fails, the system fails to boot when restarted.

Important: An integrity check failure indicates that some part of the BIG-IP software has unexpectedly changed. This might indicate that an attacker has gained access to your system and changed, installed, or removed something on the BIG-IP system. You should review your internal security policies prior to taking any further actions as they might require or prohibit specific troubleshooting procedures.

You should consider running FIPS integrity checks when a BIG-IP system that is licensed for F5 Full-Box FIPS is operating and accessible, and these conditions occur:

  • A BIG-IP Integrity Check: [ FAIL ] – Contact F5 Networks technical support error displays in the /var/log/secure file.
  • A manual integrity check fails.

Important: If the FIPS integrity check displays a fail status, the BIG-IP system will not boot to the current volume the next time it restarts. Therefore, it is important that you resolve any issues before you restart your system to determine the root cause.

Important: Do not restart your BIG-IP system during these troubleshooting steps. When the BIG-IP system starts, it performs an integrity test again, and if this test fails, the system stops the boot process and disables that volume, restricting further troubleshooting. If this occurs, you must perform a pre-operational self test. For more information, see Troubleshoot FIPS pre-operational self-test failures.

Note: If your system fails an integrity check when you power it on and does not complete the boot procedure, see Troubleshoot FIPS pre-operational self-test failures.

  1. Back up your system configuration to a user configuration set (UCS) file.

    For more information, see K13132: Backing up and restoring BIG-IP configuration files with a UCS archive.

    Note: Consider including the cause of the failure in your UCS file when you back up your system.

  2. Create a QKView file using the qkview utility and upload it to F5 Support using BIG-IP iHealth.

    For more information, see K12878: Generating diagnostic data using the qkview utility.

  3. Run the sys-eicheck utility to locate the failed files.

    For more information, see Full-Box FIPS and the sys-eicheck utility.

  4. Determine the time window of the failure.

    BIG-IP systems licensed with the F5 FIPS Full-Box run the sys-eicheck utility daily and log to the /var/log/secure file. Note the time stamp on the first BIG-IP Integrity Check: [ FAIL ] – Contact F5 Networks technical support message and the time stamp of the last successful check from the most recent BIG-IP Integrity Check: [ PASS ] message. The period between the two messages is the failure time window.

  5. Review administrative actions during the failure time window.

    1. Review the list of changed files to narrow the potential actions that might impact them.

      For example, if system files were removed or changed, administrative actions are unlikely to impact them.

    2. Review any known administrative actions that occurred within the time window.

      To determine this, use information from these sources:

      • Internal change control or trouble ticket documentation
      • The BIG-IP audit log file at /var/log/audit
      • Other BIG-IP logs, as appropriate Normal administrative actions performed using the Configuration utility or TMOS Shell (tmsh) commands should not cause integrity checks to fail. The most likely causes of failure are actions to troubleshoot problems or actions that might impact the underlying Linux operating system, such as installing or modifying the Linux system software.

  6. Back out changes made during the failure time window.

    If any administrative actions occurred during the time window, consider backing out these changes and running the integrity check again. Depending on the actions, you might not be able to back out the changes. If you cannot back out these changes, you might need to reload the system configuration on a new partition using your UCS file.

    After backing out changes, run the sys-eicheck utility again to determine whether the problem is resolved.

  7. Reload your backup file on a new partition.

    Important: Do not use your only remaining backup partition. Doing so might restore the problem along with the UCS on that partition, making it also unusable and potentially making it impossible to restart and boot the system. If this occurs, you need to re-image your system.

    If the problem is not resolved before booting into the new partition, you will not be able to access the current partition again. You should perform this action only as a last resort if you cannot otherwise resolve the issue.

    1. Create a new partition with the appropriate software version.

      For more information, see K34745165: Managing software images on the BIG-IP system.

    2. Restore your UCS backup to this partition.

      For more information, see K13132: Backing up and restoring BIG-IP configuration files with a UCS archive.

    If reloading your UCS file on a new partition does not solve the issue, the cause of the problem might be included in your UCS file.

  8. Determine whether your system is compromised using your organization’s security policy.

    If you are unable to determine any known administrative changes that occurred during the failure time window, review and follow your organization’s policies for devices that are suspected of being compromised. You can then open a support ticket with F5 Support. For more information, see Compromised system assessment.

On BIG-IP systems that include the F5 Full-Box FIPS add-on license, you can manually perform FIPS integrity checks. The system automatically performs scheduled checks on a regular basis. Manual check results display on the console, and scheduled checks log to the /var/log/secure file. If an integrity check fails, the system fails to boot when restarted.

Important: An integrity check failure indicates that some part of the BIG-IP software has unexpectedly changed. This might indicate that an attacker has gained access to your system and changed, installed, or removed something on the BIG-IP system. You should review your internal security policies prior to taking any further actions as they might require or prohibit specific troubleshooting procedures.

When a BIG-IP system that is licensed for F5 Full-Box FIPS fails to boot due to failed self tests, you can recover the system. If any of these self-tests fail, the system halts. In addition, the system regularly performs some self-tests and might force an immediate restart, which results in a halted system. Because of this, you might encounter one or more of these symptoms:

  • The BIG-IP system fails to boot to the active partition

  • An error similar to this example displays on the console:

    The FIPS or Common Criteria power-up self-test failure. This system has been placed in an error state.

Note: For longer errors, you might have to scroll up to see them.

Note: If your BIG-IP system is operating and you see a log entry for an integrity check failure, see Troubleshoot FIPS self-test failures.

  1. Change the system boot location and boot to an alternate partition.

    1. Immediately after you start the system, a screen displays notifying to select a boot partition to use. Select any partition other than the currently-selected one.

    2. If you need to restore your system configuration from a backup, or if you intend to copy the configuration using the cpcfg command, make sure you have another available partition in case the issue is restored along with the backup configuration.

      For more information about the cpcfg command, see K14724: Using the cpcfg command to copy a configuration from one boot location to another.

    3. If necessary, perform a switchboot operation to make sure that the new partition becomes the default choice.

      For more information, see K5658: Overview of the switchboot utility.

  2. Perform a clean installation by re-imaging the BIG-IP system.

    Important: Re-imaging the BIG-IP system overwrites the entire storage drive. After you re-image the system, you cannot perform any further troubleshooting to determine the cause of the issue.

The sys-eicheck utility is the FIPS version of the sys-icheck utility. The sys-eicheck utility scans the BIG-IP system for any unexpected changes to the system software.

The sys-eicheck utility is installed with all BIG-IP systems, but it only runs automatically on systems that are licensed for the F5 Full-Box FIPS add-on. The system runs the sys-eicheck utility for the power-on and daily self-tests required for FIPS validation.

You can also run it manually to determine if the device will pass or fail the tests. Log in to the CLI as an administrator and use the command /usr/libexec/sys-eicheck.py to manually run the sys-eicheck.

Note: You can run the sys-eicheck command on any system, but results return only for those systems licensed with the F5 Full-Box FIPS add-on.

Run Actions
On power-on On Pass: No action

On Fail: Logs details to the /config/f5_public/fipserr file, stops the boot process, and reports a failure on the console

|Daily|Logs this result to the /var/log/secure file:

Pass: BIG-IP Integrity Check: [ PASS ]

Fail: BIG-IP Integrity Check: [ FAIL ] – Contact F5 Networks technical support

|Manually|Displays results and details on the console| |For QKView|Adds detailed results to the QKview /fips_module.xml file|

The sys-eicheck output contains these sections:

  • A summary
  • Critical files missing
  • Critical files modified

If the sys-eicheck utility displays a fail status, the system will not boot to the current volume the next time it restarts. Make sure to resolve any fail issues before you restart the BIG-IP system. For troubleshooting information, refer to Troubleshoot FIPS self-test failures.

The utility only considers missing or modified critical files as failures. The output contains non-critical files for informational purposes only.

The system shows PASS or FAIL messages with the output. This shows an example of output displayed:

 BIG-IP Integrity Check Report
 - Critical file modifications result in failure.
 =======================================================
 /usr/lib/python2.7/site-packages/rw_lib.py
 1 critical file(s) missing
 =======================================================
 0 critical file(s) modified
 =======================================================
 Integrity Check Result: [ FAIL ]
 Contact F5 Networks Technical Support.

In the FIPS-enabled mode, the system automatically reorganizes the Secure Sockets Layer (SSL) cipher suites so that the FIPS-approved cipher suites appear at the top of the list as the most preferred ciphers.

These system daemons start in FIPS-enabled mode:

  • bigd
  • chmand
  • devmgmtd
  • fipscheck
  • httpd
  • mcpd
  • named
  • ntpd
  • openssl
  • raccoon
  • sshd
  • tamd
  • tmm

In FIPS-enabled mode, the daemons use these ciphers:

  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES128-SHA
  • ECDHE-RSA-AES256-SHA
  • ECDHE-RSA-AES128-SHA256
  • ECDHE-RSA-AES256-SHA384
  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-AES128-SHA
  • ECDHE-ECDSA-AES256-SHA
  • ECDHE-ECDSA-AES128-SHA256
  • ECDHE-ECDSA-AES256-SHA384

In the FIPS-enabled mode, the Client SSL and Server SSL profiles continue to use the cipher keyword DEFAULT.

The BIG-IP system has these two cipher string keywords:

  • FIPS : This cipher string keyword selects only FIPS-compliant cipher suites.
  • @FIPS : This keyword orders cipher suite preference to use FIPS-compliant cipher suites first.

To use only FIPS-compliant cipher suites, from advanced configuration mode for the profile, change the cipher string from DEFAULT to FIPS.

To use only FIPS-compliant cipher suites and with the cipher suites sorted from the most to the least recommended, from advanced configuration mode for the profile, use the FIPS:@FIPS cipher string in the profile.

The FIPS cipher string loads the FIPS-compliant ciphers, and the @FIPS action keyword reorders the cipher suites to prefer the strongest FIPS-compliant ciphers first.

In the FIPS-enabled mode, the system automatically reorganizes the Secure Sockets Layer (SSL) cipher suites so that the FIPS-approved cipher suites appear at the top of the list as the most preferred ciphers.

These system daemons start in FIPS-enabled mode:

  • bigd
  • chmand
  • devmgmtd
  • fipscheck
  • httpd
  • mcpd
  • named
  • ntpd
  • openssl
  • raccoon
  • sshd
  • tamd
  • tmm

In FIPS-enabled mode, the daemons use these ciphers:

  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES128-SHA
  • ECDHE-RSA-AES256-SHA
  • ECDHE-RSA-AES128-SHA256
  • ECDHE-RSA-AES256-SHA384
  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-AES128-SHA
  • ECDHE-ECDSA-AES256-SHA
  • ECDHE-ECDSA-AES128-SHA256
  • ECDHE-ECDSA-AES256-SHA384

In the FIPS-enabled mode, the Client SSL and Server SSL profiles continue to use the cipher keyword DEFAULT.

The BIG-IP system has these two cipher string keywords:

  • FIPS : This cipher string keyword selects only FIPS-compliant cipher suites.
  • @FIPS : This keyword orders cipher suite preference to use FIPS-compliant cipher suites first.

To use only FIPS-compliant cipher suites, from advanced configuration mode for the profile, change the cipher string from DEFAULT to FIPS.

To use only FIPS-compliant cipher suites and with the cipher suites sorted from the most to the least recommended, from advanced configuration mode for the profile, use the FIPS:@FIPS cipher string in the profile.

The FIPS cipher string loads the FIPS-compliant ciphers, and the @FIPS action keyword reorders the cipher suites to prefer the strongest FIPS-compliant ciphers first.