NAME

       update-crypto-policies - manage the policies available to the various cryptographic
       back-ends.

SYNOPSIS

       update-crypto-policies [COMMAND]

DESCRIPTION

       update-crypto-policies(8) is used to set the policy applicable for the various
       cryptographic back-ends, such as SSL/TLS libraries. That will be the default policy used
       by these back-ends unless the application user configures them otherwise.

       The available policies are described in the crypto-policies(7) manual page.

       The desired system policy is selected in /etc/crypto-policies/config and this tool will
       generate the individual policy requirements for all back-ends that support such
       configuration. After this tool is called the administrator is assured that any application
       that utilizes the supported back-ends will follow a policy that adheres to the configured
       profile.

       Note that the above assurance does apply to the extent that applications are configured to
       follow the default policy (the details vary on the back-end, see below for more
       information).

       The generated back-end policies will be placed in /etc/crypto-policies/back-ends.
       Currently the supported back-ends are:

       •   GnuTLS library

       •   OpenSSL library

       •   NSS library

       •   OpenJDK

       •   Libkrb5

       •   BIND

       •   OpenSSH

       •   Libreswan

       •   libssh

       Applications and languages which rely on any of these back-ends will follow the system
       policies as well. Examples are apache httpd, nginx, php, and others.

       In general after changing the system crypto policies with the update-crypto-policies --set
       command it is recommended to restart the system for the effect to fully take place as the
       policy configuration files are loaded on application start-up. Otherwise applications
       started before the command was run need to be restarted to load the updated configuration.

COMMANDS

       The following commands are available in update-crypto-policies tool.

       •   --show: Shows the currently applied crypto policy

       •   --is-applied: Returns success if the currently configured policy is already applied.

       •   --set: Sets the current policy and overwrites the config file.

OPTIONS

       The following options are available in update-crypto-policies tool.

       •   --no-check: By default this tool does a sanity check on whether the configured policy
           is accepted by the supported tools. This option disables those checks.

       •   --no-reload: By default this tool causes some running applications to reload the
           configured policy. This option skips the reloading.

APPLICATION SUPPORT

       Applications in the operating system that provide a default configuration file that
       includes a cryptographic policy string will be modified gradually to support these
       policies.

       When an application provides a configuration file, the changes needed to utilize the
       system-wide policy are the following.

       •   Applications using GnuTLS: If an application allows the configuration of cipher
           priotities via a string, the special priority string "@SYSTEM" should replace any
           other priority string. Applications which use the default library settings
           automatically adhere to the policy. Applications following the policy inherit the
           settings for cipher suite preference, TLS and DTLS protocol versions, allowed elliptic
           curves, and limits for cryptographic keys.

       •   Applications using OpenSSL: If an application allows the configuration of ciphersuite
           string, the special cipher string "PROFILE=SYSTEM" should replace any other cipher
           string. Applications which use the default library settings automatically adhere to
           the policy. Applications following the policy inherit the settings for cipher suite
           preference. By default the OpenSSL library reads a configuration file when it is
           initialized. If the applicaton does not override loading of the configuration file,
           the policy also sets the minimum TLS protocol version and default cipher suite
           preference via this file. If the application is long-running such as the httpd server
           it has to be restarted to reload the configuration file after policy is changed.
           Otherwise the changed policy cannot take effect.

       •   Applications using NSS: Applications using NSS will load the crypto policies by
           default. They inherit the settings for cipher suite preference, TLS and DTLS protocol
           versions, allowed elliptic curves, and limits for cryptographic keys. Note that unlike
           OpenSSL and GnuTLS, the NSS policy is enforced by default; to prevent applications
           from adhering to the policy the NSS_IGNORE_SYSTEM_POLICY environment variable must be
           set to 1 prior to executing that application.

       •   Applications using Java: No special treatment is required. Applications using Java
           will load the crypto policies by default. These applications will then inherit the
           settings for allowed cipher suites, allowed TLS and DTLS protocol versions, allowed
           elliptic curves, and limits for cryptographic keys. To prevent openjdk applications
           from adhering to the policy the <java.home>/jre/lib/security/java.security file should
           be edited to contain security.useSystemPropertiesFile=false. Alternatively one can
           create a file containing the overridden values for jdk.tls.disabledAlgorithms,
           jdk.certpath.disabledAlgorithms and pass the location of that file to Java on the
           command line using the -Djava.security.properties=<path to file>.

       •   Applications using libkrb5: No special treatment is required. Applications will follow
           the crypto policies by default. These applications inherit the settings for the
           permitted encryption types for tickets as well as the cryptographic key limits for the
           PKINIT protocol. A system-wide opt-out is available by deleting the
           /etc/krb5.conf.d/crypto-policies link.

       •   BIND: This application inherits the set of blacklisted algorithms. To opt-out from the
           policy, remove the policy include directive in the named.conf file.

       •   OpenSSH: Both server and client application inherits the cipher preferences, the key
           exchange algorithms as well as the GSSAPI key exchange algorithms. To opt-out from the
           policy for client, override the global ssh_config with a user-specific configuration
           in ~/.ssh/config. See ssh_config(5) for more information. To opt-out from the policy
           for server, uncomment the line containing CRYPTO_POLICY= in /etc/sysconfig/sshd .

       •   Libreswan: Both servers and clients inherit the ESP and IKE preferences, if they are
           not overridden in the connection configuration file. Note that due to limitations of
           libreswan, crypto policies is restricted to supporting IKEv2. To opt-out from the
           policy, comment the line including /etc/crypto-policies/back-ends/libreswan.config
           from /etc/ipsec.conf.

       •   Applications using libssh: Both client and server applications using libssh will load
           the crypto policies by default. They inherit the ciphers, key exchange, message
           authentication, and signature algorithms preferences.

POLICY CONFIGURATION

       One of the supported profiles should be set in /etc/crypto-policies/config and this script
       should be run afterwards.

       In case of a parsing error no policies will be updated.

CUSTOM POLICIES

       The custom policies can take two forms. First form is a full custom policy file which is
       supported by the update-crypto-policies tool in the same way as the policies shipped along
       the tool in the package.

       The second form can be called a subpolicy or policy modifier. This form modifies aspects
       of any base policy file by removing or adding algorithms or protocols. The subpolicies can
       be appended on the update-crypto-policies --set command line to the base policy separated
       by the : character. There can be multiple subpolicies appended.

       Let’s suppose we have subpolicy NO-SHA1 that drops support for SHA1 hash and subpolicy
       GOST that enables support for the various algorithms specified in Russian GOST standards.
       You can set the DEFAULT policy with disabled SHA1 support and enabled GOST support by
       running the following command:

       update-crypto-policies --set DEFAULT:NO-SHA1:GOST

       This command generates and applies configuration that will be modification of the DEFAULT
       policy with changes specified in the NO-SHA1 and GOST subpolicies.

FILES

       /etc/crypto-policies/config
           The file contains the current system policy. It should contain a string of one of the
           profiles listed in the crypto-policies(7) page (e.g., DEFAULT).

       /etc/crypto-policies/back-ends
           Contains the generated policies in separated files, and in a format readable by the
           supported back ends.

       /etc/crypto-policies/local.d
           Contains additional files to be appended to the generated policy files. The files
           present must adhere to $app-XXX.config file naming, where XXX is any arbitrary
           identifier. For example, to append a line to GnuTLS' generated policy, create a
           gnutls-extra-line.config file in local.d. This will be appended to the generated
           gnutls.config during update-crypto-policies. These overrides, are only functional for
           the gnutls, bind, java (openjdk) and krb5 back-ends.

SEE ALSO

       crypto-policies(7), fips-mode-setup(8)

AUTHOR

       Written by Nikos Mavrogiannopoulos.