NetBackup status code: 8798
Message: The certificate of the host cannot be validated because FIPS mode is enabled.
Explanation: The NetBackup Web Management Console service (nbwmc) has many workflows that interact with other products and or sub-systems such as:
Media Server Deduplication Pool (MSDP)
Cohesity Resiliency Platform (VRP)
WebSocket Servers
Trusted primary servers from other NetBackup domains (NetBackup Auto Image Replication)
Snapshot Manager
These interactions are HTTPS-based and thus involve SSL handshake and certificate chain validation of the remote entity. These interactions begin with calling the APIs which fetch the CA certificate details from the remote entity and showing the certificate details such as fingerprints to the end user. Once the certificate is accepted by the end user, the certificate details are persisted in the appropriate trust store in NetBackup. And these stored CA certificates are then used in subsequent API workflows to verify the remote entity's identity.
The APIs for fetching the CA certificate of remote entity do not validate the peer certificate. NetBackup does not have a preconfigured trust store to validate the peer during SSL handshake. NetBackup asks the user to trust such CA certificates or decline to trust before operations proceed further. However, with FIPS enabled on the primary server, the bootstrapping calls (which fetch the remote entity's CA certificate and ask for user to trust or decline) are not allowed. Enforcing FIPS requires verification of the server certificate that the remote entity presents during SSL handshake. This means that these APIs no longer work when primary server is running in FIPS mode.
The list of APIs that do not work when FIPS mode is enabled:
GET /config/remote-master-server-cacerts/{remoteMasterServer}POST /config/servers/wssendpoints/validateurl
POST /config/servers/wssendpoints/validatehost
This API does not work when a certificate is not passed in the payload. Although when NetBackup is run in FIPS mode, if a certificate isn't passed, the API returns a different error.
GET /resiliency/servers/{resiliencyManager}/cacertsPOST /config/servers/msdp-servers
Applicable only when new back-level MSDP servers are added that equal version 8.3 or newer up to version 9.0. Also applicable to NetBackup 10.0 and newer, with FIPS enabled.
Recommended Action: To overcome this problem, a temporary FIPS-compliant trust store has been introduced in NetBackup 10.0 which is located at:
install_path/var/global/wsl/credentials/cacerts.bcfks
When a NetBackup primary server is running in FIPS mode, administrators now need to ensure that this trust store has the remote entity's CA certificate already available in it. This check must be done before the APIs are called to fetch the CA certificate of remote entity. NetBackup Web Services API workflows use this trust store to verify the identity of the remote entity NetBackup communicates with.
Contact your NetBackup Administrator to populate the trust store with the target server's CA certificate for validating the server's authenticity.
Note:
The following steps need to be performed on the NetBackup primary server which is configured to run in FIPS mode.
The keytool command that is available on the primary server, can be used to import the CA certificates into the trust store install_path/var/global/wsl/credentials/cacerts.bcfks. The options -providerclass and -providerpath are needed as the trust store is a BCFKS format trust store, the only fully FIPS-compliant store format.
The remote entity's CA certificate must be available in a file in a PEM encoded format. The CA certificate must be copied over to the NetBackup primary server running in FIPS mode.
The steps to export the remote entity's CA certificate into a PEM format file can vary. One of the ways to get the information is by using the following keytool commands. The NetBackup administrator needs to refer to the documentation of the product/sub-system NetBackup is intended to be integrated. For example, while adding VRP server in NetBackup, steps to get the VRP server's CA certificate in a PEM format will be available in VRP documentation.
Use the following keytool commands to import the CA certificate into install_path/var/global/wsl/credentials/cacerts.bcfks:
Windows:
install_path\java\jre\bin\keytool -storetype BCFKS -providerpath install_path\wmc\webserver\lib\ccj.jar -providerclass com.safelogic.cryptocomply.jcajce.provider.CryptoComplyFipsProvider -importcert -trustcacerts -file <CA certificate file (PEM encoded) path> -keystore install_path\var\global\wsl\credentials\cacerts.bcfks -storepass <password from the install_path\var\global\jkskey file> -alias <alias name of the trusted certificate entry to be added>
UNIX:
/usr/openv/java/jre/bin/keytool -storetype BCFKS -providerpath /usr/openv/wmc/webserver/lib/ccj.jar -providerclass com.safelogic.cryptocomply.jcajce.provider.CryptoComplyFipsProvider -importcert -trustcacerts -file <CA certificate file (PEM encoded) path> -keystore install_path/var/global/wsl/credentials/cacerts.bcfks -storepass <password from the /usr/openv/var/global/jkskey file> -alias <alias name of the trusted certificate entry to be added>
NetBackup doesn't need these CA certificates after the bootstrapping calls are done (subsequent API calls make use of a different trust store that has these CA certificate entries populated). Cohesity recommends that entries are cleaned up once the remote entity is configured in NetBackup. To delete an entry from the temporary keystore:
Windows:
install_path\java\jre\bin\keytool -storetype BCFKS -providerpath install_path\wmc\webserver\lib\ccj.jar -providerclass com.safelogic.cryptocomply.jcajce.provider.CryptoComplyFipsProvider -importcert -trustcacerts -file <CA certificate file (PEM encoded) path> -keystore install_path\var\global\wsl\credentials\cacerts.bcfks -storepass <password from the install_path\var\global\jkskey file> -delete -alias <alias of the entry to be deleted>
UNIX:
/usr/openv/java/jre/bin/keytool -storetype BCFKS -providerpath /usr/openv/wmc/webserver/lib/ccj.jar -providerclass com.safelogic.cryptocomply.jcajce.provider.CryptoComplyFipsProvider -keystore /usr/openv/var/global/wsl/credentials/cacerts.bcfks -storepass <password from the /usr/openv/var/global/jkskey file> -delete -alias <alias of the entry to be deleted>
Perform the following procedure to configure a trusted primary server.
To configure a trusted primary server
- Perform the following on the destination primary server:
Export the CA certificate from a BCFKS format trust store using the keytool command:
/usr/openv/java/jre/bin/keytool -storetype BCFKS -providerpath /usr/openv/wmc/lib/ccj.jar -providerclass com.safelogic.cryptocomply.jcajce.provider.CryptoComplyFipsProvider -exportcert -alias <alias of the cert to be exported> -keystore <BCFKS format trust store> -storepass <store password> -rfc -file <destination PEM file in which this CA certificate will be exported>
Example:
Windows:
install_path\jre\bin\keytool -providerpath install_path\wmc\lib\ccj.jar -providerclass com.safelogic.cryptocomply.jcajce.provider.CryptoComplyFipsProvider -storetype BCFKS -export -alias nbwmc -rfc -file <file name of the CA cert PEM> -keystore install_path\var\global\wsl\credentials\nbwebservice.bcfks -storepass <password from install_path\var\global\jkskey>
UNIX:
/usr/openv/java/jre/bin/keytool -providerpath /usr/openv/wmc/lib/ccj.jar -providerclass com.safelogic.cryptocomply.jcajce.provider.CryptoComplyFipsProvider -storetype BCFKS -export -alias nbwmc -rfc -file /usr/openv/var/global /wsl/credentials/nbwmc.pem -keystore /usr/openv/var/global/wsl/credentials/nbwebservice.bcfks -storepass <password from /usr/openv/var/global/jkskey>
- Copy the PEM file that is created as part of the step 1 command run, from the destination primary server to source primary server.
- On the source primary server, import the CA certificate from the PEM file to
install_path/var/global/wsl/credentials/cacerts.bcfks:Windows:
install_path\java\jre\bin\keytool -storetype BCFKS -providerpath install_path\wmc\webserver\lib\ccj.jar -providerclass com.safelogic.cryptocomply.jcajce.provider.CryptoComplyFipsProvider -importcert -trustcacerts -file <CA certificate file (PEM encoded) path> -keystore install_path\var\global\wsl\credentials\cacerts.bcfks -storepass <password from the install_path\var\global\jkskey file> -alias <alias name of the trusted certificate entry to be added>
UNIX:
/usr/openv/java/jre/bin/keytool -storetype BCFKS -providerpath /usr/openv/wmc/webserver/lib/ccj.jar -providerclass com.safelogic.cryptocomply.jcajce.provider.CryptoComplyFipsProvider -importcert -trustcacerts -file <CA certificate file (PEM encoded) path> -keystore install_path/var/global/wsl/credentials/cacerts.bcfks -storepass <password from the /usr/openv/var/global/jkskey file> -alias <alias name of the trusted certificate entry to be added>
- (Conditional) To import the CA certificate of source primary server to destination primary server, you must follow steps 1, 2, and 3. For step 1, the destination primary server becomes source and source becomes destination. This change ensures that both primary servers have each other's CA certificate available at
install_path/var/global/wsl/credentials/cacerts.bcfks.If the remote entity has a JKS formatted keystore, the following command can be used to export the CA certificate in PEM format.
Exporting a CA certificate from a JKS format trust store using the keytool command:
/usr/openv/java/jre/bin/keytool -exportcert -alias <alias of the cert to be exported> -keystore <trust store path> -storepass <store password> -rfc -file <destination PEM file in which this CA certificate will be exported>
Click here to view technical notes and other information on the Veritas Technical Support website about this status code.