UPDATE-CRYPTO-POLI(8)

📦
version 20250714.cd6043a · 9 versions
, in opensuse-leap 16.0

🎀 NAME 🎀

okay so bestie, this is update-crypto-policies(8) — literally the manual page for managing the policies available to the various cryptographic back-ends 💅

✨ SYNOPSIS ✨

update-crypto-policies [COMMAND]

💖 DESCRIPTION 💖

update-crypto-policies(8) is the tool you use to set the policy that applies to all the various cryptographic back-ends out there — think SSL/TLS libraries and their friends. The whole vibe of the policy is to control the back-end default algorithm selections unless, like, the application user configures them otherwise. no cap.

The available policies are described in the crypto-policies(7) manual page — go read that one too, bestie, it's giving essential lore 🔥

So the desired system policy is selected in /etc/crypto-policies/config, and this tool will generate the individual policy requirements for all the back-ends that support such configuration. After this tool is called and all the affected applications are restarted, the administrator is assured that any application that utilizes the supported back-ends will follow the specified policy. iconic behavior, honestly 👑

⚠️ 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). so like, it's not magic, it's policy 💅

The generated back-end policies will be placed in /etc/crypto-policies/back-ends. Currently the supported back-ends (and the directive scopes they respect) are:

  • GnuTLS library (GnuTLS, SSL, TLS)
  • OpenSSL library (OpenSSL, SSL, TLS)
  • NSS library (NSS, SSL, TLS)
  • OpenJDK (java-tls, SSL, TLS)
  • Libkrb5 (krb5, kerberos)
  • BIND (BIND, DNSSec)
  • OpenSSH (OpenSSH, SSH)
  • Libreswan (libreswan, IKE, IPSec)
  • libssh (libssh, SSH)

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. they're all in on it 🫶

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 — because 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. so like, reboot or restart your faves, iykyk 😭

🌸 COMMANDS 🌸

The following commands are available in the update-crypto-policies tool. group chat, but make it CLI 💬

  • --set — sets the current policy and overwrites the config file.
  • --show — shows the currently applied crypto policy.
  • --is-applied — returns success if the currently configured policy in the config file was applied by running the update-crypto-policies. like a vibe check for your config ✅
  • --check — returns success if freshly generated configuration files match the current policy. The check will return failure if there is a manual modification of the back-end configuration files or a newer version of crypto-policies package is installed without running update-crypto-policies. This should not happen with system updates because update-crypto-policies is run implicitly there. so if this fails, something is sus 💀

🦋 OPTIONS 🦋

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

  • --no-reload — by default this tool causes some running applications to reload the configured policy. This option skips the reloading. perfect for when you're like "not now, bestie" 🙈

💜 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. slow and steady, but make it secure 🌈

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

  • 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 application 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. no restart, no slay 😤
  • Applications using GnuTLS: applications using GnuTLS will load the crypto policies by default. To prevent applications from adhering to the policy the GNUTLS_SYSTEM_PRIORITY_FILE environment variable must be set on an empty file (e.g., /dev/null). The policy covers the settings for cipher suite preference, TLS and DTLS protocol versions, allowed elliptic curves, and limits for cryptographic keys. so like, opt out with an empty file, chaotic but valid 🐚
  • 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. 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. set it before, not during, bestie ⭐
  • 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 or the system property java.security.disableSystemPropertiesFile be set to true. Note that the system property java.security.properties is loaded with a lower preference than the crypto policies, so you can’t use this property to override crypto policies without also preventing openjdk applications from adhering to the policy. read that twice, it's giving trick question 💀
  • 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. one little link, that's the whole escape hatch 🎀
  • BIND: this application inherits the set of disabled algorithms. To opt-out from the policy, remove the policy include directive in the named.conf file. simple as that ✨
  • 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 override some configuration option in server, use a drop-in directory /etc/ssh/sshd_config.d/ to create a file lexicographically preceding 05-redhat.conf which is currently including crypto policies configuration file. lexicographically preceding, say it with your chest 👑
  • 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. IKEv2 only, that's the rule 🔥
  • 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. full glow-up, no notes 💅

🧚 POLICY CONFIGURATION 🧚

One of the supported policies should be set in /etc/crypto-policies/config and this script should be run afterwards. order matters, bestie 🍓

⚠️ in case of a parsing error no policies will be updated. so if you typo, nothing happens — no half-applied chaos, which is lowkey a relief 😭

🌟 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. bespoke, custom, main character energy 💖

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. The resulting configuration is the same as if the policy and subpolicies were concatenated together. stack them like friendship bracelets 🫶

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. ate and left no crumbs 💅✨

💖 FILES 💖

okay bestie, here's where everything actually lives on your filesystem — think of it as the group chat locations tab, but for crypto 🌸

  • /etc/crypto-policies/config — this is the main character file, no cap. It holds the system policy that gets applied whenever update-crypto-policies is run with no arguments at all. What goes in it? A string of one of the policies listed over in the crypto-policies(7) page (like, e.g., DEFAULT), or literally any custom policy name with subpolicies separated by the : character. ✨ Heads up though: this file gets overwritten the moment you run update-crypto-policies --set, so don't get too attached to whatever's in there 💅
  • /etc/crypto-policies/back-ends — the generated policies live here, each in its own separate file, all formatted so the supported back ends can actually read them. it's giving organized 🎀
  • /etc/crypto-policies/local.d — this is the extra-toppings folder 🍓 It contains additional files that get appended to the generated policy files. The files in here must follow the $app-XXX.config naming scheme, where XXX is any arbitrary identifier you want. Example time: say you wanna append a line to GnuTLS' generated policy — just create a gnutls-extra-line.config file in local.d, and it gets appended to the generated gnutls.config during update-crypto-policies. Obsessed? Same. BUT — and this is the important part — because this mechanism literally just appends a line to the back-end configuration, the actual effect varies among the back-ends 😭 For some back-ends the override fully replaces the original policy, and for other back-ends the override might not be effective at all. so yeah, results may vary, iykyk 💀
  • /etc/crypto-policies/state/current — holds the current system policy name (plus any eventual subpolicies) as of the last execution of the update-crypto-policies command. like a little receipt of what you last did 🧾
  • /etc/crypto-policies/state/CURRENT.pol — the full current system policy definition, with all the modifications from any eventual subpolicies already applied. This one gets written whenever the update-crypto-policies command is executed ✨

👀 SEE ALSO 👀

go read these next, bestie, they're literally right there:

🫶 AUTHOR 🫶

Written by Nikos Mavrogiannopoulos. iconic behavior, we stan 💜

and that's the whole page, bestie! go forth and configure your crypto policies responsibly 🌈

and yes — this beauty is update-crypto-policies, dated 11/11/2025, living that UPDATE-CRYPTO-POLI(8) life ✨🎀💅 love that for us 🦋

📦 where this page comes from