This documentation supports the 11.3 version of BMC Discovery.

To view an earlier version of the product, select the version from the Product version menu.

Running in FIPS compliant mode

The Federal Information Processing Standard (FIPS) Publication 140-2, is a computer security standard, developed by a U.S. Government and industry working group to validate the quality of cryptographic modules.

FIPS Publication 140-2 can be downloaded from the National Institute of Standards and Technology (NIST) web site.

BMC Discovery and FIPS

Enabling FIPS mode ensures that BMC Discovery uses only FIPS compliant cryptographic algorithms and FIPS compliant keys, though some functionality is not supported in FIPS mode, such as using SMB file systems for export or backup. FIPS mode requires that you provide the FIPS compliant SSL keys.

When not running in FIPS mode, BMC Discovery still uses FIPS compliant cryptographic algorithms where possible.

To fully enable strict FIPS compliance, you must install BMC Discovery from the kickstart DVD replacing the install or custom options with installfips or customfips. Enabling FIPS during the kickstart means that all keys and certificates generated during installation will be generated with FIPS compliant algorithms. You must also enable NSS after enabling FIPS so that all components are generated with the appropriate algorithms. For more information on the FIPS compliance on CentOS, see the equivalent Red Hat documentation.

You cannot mount a Windows share from a FIPS enabled appliance. The mount operation fails and an error message is written to syslog.


  • To enable FIPS, you either install with installfips or run the tw_fips_control command after installation. Installation using the installfips option does not require that tw_fips_control is run again after installation.
  • In either case (installfips or tw_fips_control), you must enable NSS after enabling FIPS to ensure all cryptographic components generated during the process are FIPS compliant.
  • The tw_fips_control command is not fully FIPS compliant because during installation, any keys and certificates that are generated are not FIPS compliant. Further, the tw_fips_control command does not re-generate existing keys and/or certificates.

To enable FIPS mode on the appliance

To enable FIPS mode, you must run a script if you have not used the installfips installation option. The script modifies the boot configuration file and regenerates the boot-time kernel but does not regenerate any keys or certificates already generated. The script requires a reboot once complete. Any modifications that have been made to the boot configuration components may conflict with FIPS mode configuration or have untoward effects.

To enable FIPS mode on the appliance:

  1. Login to the appliance command line as the root user.
  2. Run the tw_fips_control script with the --enable option.

    [root@appliance01 ~]# /usr/tideway/bin/tw_fips_control --enable
    This script will enable or disable FIPS 140-2 mode on your Discovery appliance.
    The script must be run as the root user and FIPS 140-2 mode is only supported
    on CentOS release 7 based Discovery appliances.
    Please note: To enable FIPS 140-2 mode the script will modify the system's boot
    configuration files (GRUB) and regenerate the boot-time kernel. Any manual
    modifications made to these components may conflict with FIPS 140-2 mode
    configuration or have untoward effects.
    A reboot is required if the current kernel mode needs to change. The script will
    notify the user if this is the case.
    Do you want to continue to enable FIPS 140-2 mode (yes/no)? yes
    Starting FIPS 140-2 mode configuration.
    Gathering current state of the system.
    Enabling FIPS 140-2 mode.
    Rebuilding initramfs - this may take a few minutes.
    Enable FIPS 140-2 mode in grub.
    Configuration complete. Please reboot to enable FIPS 140-2 mode.
    [root@appliance01 ~]#  

Disabling FIPS mode on the appliance is accomplished by running the tw_fips_control script with the --disable option. The script modifies the boot configuration file and regenerates the boot-time kernel. This requires a reboot. You do not need to replace SSL keys after disabling FIPS mode.

To enable FIPS mode on the proxy

When installing a proxy the installation detects whether the Windows host is running in FIPS mode. If the host is running in FIPS mode, and you are upgrading from a very old Windows proxy version, you must replace the SSL key before running the proxy. The installer displays a dialog stating this when you install a proxy onto a FIPS enabled host.

For information on using Windows in FIPS mode, see this Microsoft knowledge base article.

Enabling NSS

The mod_ssl Apache library used in BMC Discovery is not FIPS 140-2 certified. To achieve strict compliance you must modify the appliance to use mod_nss rather than mod_ssl. See the Mozilla website for an overview of NSS.


  • The HTTPS administration tools provided in the BMC Discovery UI should not be used after making configuration changes.
  • Any changes made to ssl.conf during upgrade are not made to nss.conf.
  • BMC Discovery upgrade may overwrite changes/re-enable SSL.

The changes that you must make to enable NSS are:

  • Import the correctly formatted certificate and key (pkcs12) into the NSS database. The database is created by this process.
  • Ensure permissions are correct on the database
  • Configure nss.conf  and disable ssl.conf

Preparing to configure NSS 

Before you can configure NSS, you must have keys in the pkcs12 format suitable for importing into the NSS database. Depending whether you generate keys using BMC Discovery, or you already have your own keys you must perform one or both of the following preparatory steps:

  • Generating self signed keys
  • Converting your keys

If you have your own keys and they are already in pkcs12 format, proceed directly to the To configure NSS procedure.

Generating self signed keys

If you do not have your own certificates and keys:

  1. Use the BMC Discovery HTTPS Configuration UI to generate self signed keys and enable HTTPS access to the appliance.
  2. Start the Converting your keys procedure.

Converting your keys

If you have your own keys and they are not in pkcs12 format, or if you have just generated keys using the HTTPS Configuration UI:

  1. Stop the services (tideway, cluster, omniNames, httpd, appliance).

  2. As the root user, convert your server certificate and key (server.crt and server.key).

    [root@localhost test]# openssl pkcs12 -export -in /etc/httpd/conf/ssl.crt/server.crt -inkey /etc/httpd/conf/ssl.key/server.key -out server.p12 -name "ADDM-Server-Cert" -passout pass:'Pa55wud!'

To configure NSS 

  1. As the root user, create the NSS database directory.

    [root@localhost test]# mkdir /usr/tideway/nssdb
  2. Import the correctly formatted server certificate and key ensuring that you specify a password.

    This password will be used for NSS DB tokens (including NSS FIPS 140-2 Certificate DB) so ensure that its complexity meets requirements.
    The password requested here is not the password provided during the pkcs12 file generation but the password that will be the NSS Certificate DB and NSS FIPS 140-2 Certificate DB tokens in the NSS database. A password must be set or httpd will fail to start if NSSFips is set to on.

    This example uses /usr/tideway/nssdb to store the NSS database. The default NSS database location is /etc/httpd/alias and files are created there by the installation of the NSS RPMs supplied in the RHEL distribution. This database may have been generated with out of date binaries. To use the default location, all files under /etc/httpd/alias should be removed.

    [root@localhost test]# pk12util -i server.p12 -d /usr/tideway/nssdb -W 'Pa55wud!'
    Enter a password which will be used to encrypt your keys.
    The password should be at least 8 characters long,
    and should contain at least one non-alphabetic character.
    Enter new password:
    Re-enter password:
    [root@localhost test]#
  3. Confirm the import using the following command:

    [root@localhost test]# certutil -L -d /usr/tideway/nssdb
    Certificate Nickname                                         Trust Attributes
    ADDM-Server-Cert                                             u,u,u
    [root@localhost test]
  4. Enable FIPS token in the NSS DB.

    [root@localhost test]# modutil -fips true -dbdir /usr/tideway/nssdb
    WARNING: Performing this operation while the browser is running could cause
    corruption of your security databases. If the browser is currently running,
    you should exit browser before continuing this operation. Type
    'q <enter>' to abort, or <enter> to continue:
    FIPS mode enabled.
    [root@localhost test]#
  5. Set the permissions on the NSS DB so that only the Apache and root users can read or write the files.

    [root@localhost tideway]# chown -R apache:apache /usr/tideway/nssdb
    [root@localhost tideway]#
  6. Create /etc/httpd/conf.d/nss.conf. This configuration replaces mod_ssl with mod_nss and uses port 443 to avoid modifications to the firewall:
# This is the Apache server configuration file providing SSL support using.
# the mod_nss plugin.  It contains the configuration directives to instruct
# the server how to serve pages over an https connection.

LoadModule nss_module modules/

# When we also provide SSL we have to listen to the
# standard HTTP port (see above) and to the HTTPS port
# Using port 443 to avoid firewall modifications
Listen 443

##  SSL Global Context
##  All SSL configuration in this context applies both to
##  the main server and all SSL-enabled virtual hosts.

#   Some MIME-types for downloading Certificates and CRLs
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl    .crl

#   Pass Phrase Dialog:
#   Configure the pass phrase gathering process.
NSSPassPhraseDialog file:/path/to/file

#   Pass Phrase Helper:
#   This helper program stores the token password pins between
#   restarts of Apache.
NSSPassPhraseHelper /usr/sbin/nss_pcache

#   Configure the SSL Session Cache.
#   NSSSessionCacheSize is the number of entries in the cache.
#   NSSSession3CacheTimeout is the SSL3/TLS session timeout (in seconds).
NSSSessionCacheSize 10000
NSSSession3CacheTimeout 86400

# Pseudo Random Number Generator (PRNG):
NSSRandomSeed startup file:/dev/urandom 512

# TLS Negotiation configuration under RFC 5746
# Only renegotiate if the peer's hello bears the TLS renegotiation_info
# extension. Default off.
NSSRenegotiation off

# Peer must send Signaling Cipher Suite Value (SCSV) or
# Renegotiation Info (RI) extension in ALL handshakes.  Default: off
NSSRequireSafeNegotiation off

## SSL Virtual Host Context

<VirtualHost _default_:443>
ErrorLog logs/ssl_error_log
LogFormat "%h %l %u %t %m %U %H %>s %b"
TransferLog logs/ssl_access_log
LogLevel warn
ServerName localhost.localdomain

#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
NSSEngine on

#   Enable FIPS
NSSFips on

#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
NSSCipherSuite -rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha

# Supported Protocols
NSSProtocol TLSv1.1

#   SSL Certificate Nickname:
#   The nickname of the RSA server certificate you are going to use.
NSSNickname ADDM-Server-Cert

#   Server Certificate Database:
NSSCertificateDatabase /usr/tideway/nssdb

#   Client Authentication (Type):
#   Client certificate verification type.  Types are none, optional and
#   require.
NSSVerifyClient none

#   Enforce valid certificates:
#   Required off if using self-signed certs.
NSSEnforceValidCerts off

RewriteEngine On
RewriteOptions Inherit


<Location /ui>
NSSOptions +StdEnvVars +ExportCertData

Notes on nss.conf

  • The NSSRandomSeed in the example is set to use /dev/urandom to avoid entropy blocking issues . The use of /dev/urandom matches the default SSL configuration when using the BMC Discovery HTTPS generation process.
  • NSSVerifyClient set to none. This depends on your environment.
  • NSSEnforceValidCerts set to off to allow self-signed certificates to be present in database.
  • The file pointed to in NSSPassPhraseDialog must be a password file which you create. The apache user needs to read this file but permissions should be as tight as possible, for example apache:apache 600. The file must have the following contents, where the password is the password of the tokens in the NSS database:
NSS FIPS 140-2 Certificate DB:<password>
  • Set permissions of the /etc/httpd/conf.d/nss.conf file. The file needs to be readable by the apache user.

7. Move out or delete /etc/httpd/conf.d/ssl.conf.

8. Start httpd to confirm config.

9. Restart all services.

(Optional) Enabling port 80 to port 443 redirection

To enable port 80 to port 443 redirection, add the following to the top of the nss.conf file.

# This is the Apache server configuration file providing SSL support using.
# the mod_nss plugin.  It contains the configuration directives to instruct
# the server how to serve pages over an https connection.

LoadModule nss_module modules/

# When we also provide SSL we have to listen to the
# standard HTTP port (see above) and to the HTTPS port
# Using port 443 to avoid firewall modications
Listen 443

# Redirect port 80 to 443
<VirtualHost *:80>
RewriteEngine On

# Do not redirect API requests as unsafe
# (username/password could be sent in the clear)
RewriteCond %{REQUEST_URI} !^/api/.*/swagger\.json$
RewriteCond %{REQUEST_URI} !^/api/about$
RewriteRule ^/api($|/.*) - [F]

# Redirect everything else to https EXCEPT for error documents
RewriteRule ^/errors?/(.*)$ - [L]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L,NE]


Was this page helpful? Yes No Submitting... Thank you