SSL_CONF_CMD(3SSL)

📦
version 4.0.3 · 13 versions
, in ubuntu stonking

💖 SSL_CONF_CMD 💖

okay so this is the SSL_CONF_CMD(3SSL) page from the OpenSSL manual, and bestie, it's a long one — we're doing it in parts. Sit down, get a snack, hydrate, we're doing command-line config for SSL/TLS and we're doing it thoroughly. 🫶

✨ NAME ✨

SSL_CONF_cmd_value_type, SSL_CONF_cmd — send configuration command. that's it, that's the whole vibe. 💅

✨ SYNOPSIS ✨

#include <openssl/ssl.h>

int SSL_CONF_cmd(SSL_CONF_CTX *ctx, const char *option, const char *value);
int SSL_CONF_cmd_value_type(SSL_CONF_CTX *ctx, const char *option);

look at that. two little functions. dainty. precious. iconic. ✨

✨ DESCRIPTION ✨

okay so SSL_CONF_cmd() does a configuration operation, right, and it does it with the option you give it and the optional parameter value, applied to ctx. its whole ~purpose~ in life is to make it easier for applications to configure SSL_CTX or SSL structures by giving you one common framework that works for command line options and configuration files. like, one framework, two use cases, we love a multi-purpose queen. 👑

and SSL_CONF_cmd_value_type() just tells you the type of value that option refers to. lowkey a little type-checker for your config strings. 🎀

✨ SUPPORTED COMMAND LINE COMMANDS ✨

rn the supported option names for command lines (so like, when the flag SSL_CONF_FLAG_CMDLINE is set) are the ones listed below. note: every single option name is case sensitive, no exceptions, do not test her. 📢 unless it says otherwise, both clients and servers can use these commands, and the value parameter just sits there unused. the default prefix for command line commands is -, and yeah, that's reflected below.

  • -bugs — sets a bunch of various bug workarounds. same thing as setting SSL_OP_ALL. 🐛
  • -no_comp — disables support for SSL/TLS compression. same as setting SSL_OP_NO_COMPRESSION. and listen: as of OpenSSL 1.1.0, compression is off by default anyway.
  • -comp — enables support for SSL/TLS compression, same as clearing SSL_OP_NO_COMPRESSION. this command showed up in OpenSSL 1.1.0. as of OpenSSL 1.1.0 compression is off by default, and TLS compression can only be used in security level 1 or lower. from OpenSSL 3.2.0 and above the default security level is 2, so this option literally does nothing unless you also change the security level. go read SSL_CTX_set_security_level(3) bestie. 😭
  • -no_ticket — disables support for session tickets, same as setting SSL_OP_NO_TICKET. 🎫
  • -serverpref — use server preference order and not client preference order when deciding which cipher suite, signature algorithm, or elliptic curve (TLS 1.2) or group (TLS 1.3) to use for an incoming connection. equivalent to SSL_OP_SERVER_PREFERENCE. only used by servers. 👑
  • -client_renegotiation — lets servers accept client-initiated renegotiation. equivalent to setting SSL_OP_ALLOW_CLIENT_RENEGOTIATION. only used by servers.
  • -legacy_renegotiation — permits the use of ⚠️ unsafe legacy renegotiation ⚠️. equivalent to setting SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION. it literally says unsafe in the name, i'm just saying.
  • -no_renegotiation — disables all attempts at renegotiation in (D)TLSv1.2 and earlier. same as setting SSL_OP_NO_RENEGOTIATION.
  • -no_resumption_on_reneg — sets SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION. only used by servers.
  • -legacy_server_connect, -no_legacy_server_connect — permits or prohibits the use of unsafe legacy renegotiation, and this one is for OpenSSL clients only. equivalent to setting or clearing SSL_OP_LEGACY_SERVER_CONNECT.
  • -prioritize_chacha — prioritizes ChaCha ciphers when the client has a ChaCha20 cipher at the top of its preference list. that usually means you're dealing with a client that has no AES hardware acceleration (like, say, a phone 📱). equivalent to SSL_OP_PRIORITIZE_CHACHA. only used by servers, and it requires -serverpref.
  • -allow_no_dhe_kex — in TLSv1.3, allows a non-(ec)dhe based key exchange mode on resumption. heads up though: that means there is no forward secrecy for the resumed session. 🙈
  • -prefer_no_dhe_kex — in TLSv1.3, on resumption, lets the server prefer a non-(ec)dhe based key exchange mode over an (ec)dhe based one. requires -allow_no_dhe_kex. equivalent to SSL_OP_PREFER_NO_DHE_KEX. only used by servers.
  • -strict — enables strict mode protocol handling. equivalent to setting SSL_CERT_FLAG_TLS_STRICT. 💅
  • -sigalgs algs — sets the supported signature algorithms for TLSv1.2 and TLSv1.3. for clients, this value gets used directly for the supported signature algorithms extension. for servers, it's used to work out which signature algorithms to support. the algs argument should be a colon separated list of signature algorithms, in order of decreasing preference, of the form algorithm+hash or signature_scheme. for the default providers shipped with OpenSSL, algorithm is one of RSA, DSA or ECDSA, and hash is a supported algorithm OID short name such as SHA1, SHA224, SHA256, SHA384 or SHA512. signature_scheme is one of the signature schemes defined in TLSv1.3, specified using the IETF name, e.g. ecdsa_secp256r1_sha256, ed25519, or rsa_pss_pss_sha256. additional providers may make further algorithms available via the TLS-SIGALG capability. signature scheme names and public key algorithm names (but not the hash names) in the algorithm+hash form are case-insensitive. check provider-base(7). if this option isn't set, then all signature algorithms supported by all activated providers are permissible. 🦋
note: algorithms that specify a PKCS#1 v1.5 signature scheme (either by using RSA as the algorithm or by using one of the rsa_pkcs1_* identifiers) are ignored in TLSv1.3 and will not be negotiated.
  • -client_sigalgs algs — sets the supported signature algorithms associated with client authentication for TLSv1.2 and TLSv1.3. for servers, algs is used in the signature_algorithms field of a CertificateRequest message. for clients, it's used to determine which signature algorithm to use with the client certificate. if a server doesn't request a certificate, this option has no effect. the syntax of algs is identical to -sigalgs. if it's not set, then whatever you set for -sigalgs gets used instead.
  • -groups groups — sets the supported groups. for clients, the groups get sent using the supported groups extension. for servers, it's used to determine which group to use. this setting affects groups used for signatures (in TLSv1.2 and earlier) and key exchange. in its simplest form the groups argument is a colon separated list of groups. the preferred names are the ones listed in the IANA TLS Supported Groups registry: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 for some groups, OpenSSL supports additional aliases. such an alias could be a NIST name (e.g. P-256), an OpenSSL OID name (e.g. prime256v1), or some other commonly used name. group names are case-insensitive in OpenSSL 3.5 and later. the list should be in order of preference, with the most preferred group first. ✨ the first group listed will also be used for the key_share sent by a client in a TLSv1.3 ClientHello. the commands below list the IANA names for TLS 1.2 and TLS 1.3, respectively:
$ openssl list -tls1_2 -tls-groups
$ openssl list -tls1_3 -tls-groups

the recommended groups for TLS 1.3 are presently documented in the default TLS group list in the OpenSSL code base. starting with OpenSSL 3.5, the hybrid algorithm X25519MLKEM768 is first in this default list. it mitigates against threats from future quantum computers while still providing state-of-the-art classical key exchange protection. 🔮 further details regarding post-quantum algorithm considerations are documented in the HISTORY section below. an enriched alternative syntax — one that lets clients send multiple keyshares and lets servers prioritise some groups over others — is described in SSL_CTX_set1_groups_list(3). since TLS 1.2 has neither keyshares nor a hello retry mechanism, with TLS 1.2 the enriched syntax is ultimately equivalent to just a simple ordered list of groups, same as the simple form above.

  • -curves groups — this is a synonym for the -groups command. same girl, different name. 💜
  • -named_curve curve — sets the temporary curve used for ephemeral ECDH modes. this is only applicable in TLS 1.0 and 1.1, and should not be used with later protocol versions. the curve argument is a curve name, or the special value auto which picks an appropriate curve based on client and server preferences. the curve can be either the NIST name (e.g. P-256) or an OpenSSL OID name (e.g. prime256v1). even with TLS 1.0 and 1.1, the default value of "auto" is strongly recommended over choosing a specific curve. curve names are case-insensitive in OpenSSL 3.5 and later.
  • -tx_cert_comp — enables support for sending TLSv1.3 compressed certificates.
  • -no_tx_cert_comp — disables support for sending TLSv1.3 compressed certificates.
  • -rx_cert_comp — enables support for receiving TLSv1.3 compressed certificates.
  • -no_rx_cert_comp — disables support for receiving TLSv1.3 compressed certificates.
  • -comp
  • -cipher ciphers — sets the TLSv1.2 and below ciphersuite list to ciphers. this list will be combined with any configured TLSv1.3 ciphersuites. note: syntax checking of ciphers is currently not performed unless an SSL or SSL_CTX structure is associated with ctx. 😬
  • -ciphersuites 1.3ciphers — sets the available ciphersuites for TLSv1.3 to value. this is a colon-separated list of TLSv1.3 ciphersuite names in order of preference. this list will be combined with any configured TLSv1.2 and below ciphersuites. see openssl-ciphers(1) for more info. 🧚
  • -min_protocol minprot, -max_protocol maxprot — sets the minimum and maximum supported protocol. currently supported protocol values are SSLv3, TLSv1, TLSv1.1, TLSv1.2, TLSv1.3 for TLS; DTLSv1, DTLSv1.2 for DTLS; and None for no limit. if either the lower or upper bound isn't specified, then only the other bound applies, if it's specified. if your application supports both TLS and DTLS you can specify any of these options twice — once with a bound for TLS and again with an appropriate bound for DTLS. to restrict the supported protocol versions, use these commands rather than the deprecated alternative commands below. ⚠️
  • -record_padding padding — controls use of TLSv1.3 record layer padding. padding is a string of the form "number[,number]" where the (required) first number is the padding block size (in octets) for application data, and the optional second number is the padding block size for handshake and alert messages. if the optional second number is omitted, the same padding will be applied to all messages. padding tries to pad TLSv1.3 records so they're a multiple of the set length on send. a value of 0 or 1 turns off padding as relevant. otherwise, the values must be >1 or <=16384. 📏
  • -debug_broken_protocol — ignored. that's it. that's the whole entry. she's just there. 💀
  • -no_middlebox — turns off "middlebox compatibility", and the deets for that are down below bestie 💅

✨ Additional Options ✨

okay so these ones? SSL_CONF_cmd() accepts them, but the OpenSSL commands themselves do not process them. so they're like... backstage pass options only 🎟️

  • -cert file — tries to use file as the certificate for the right context. rn it uses SSL_CTX_use_certificate_chain_file() if an SSL_CTX structure is set, or SSL_use_certificate_file() with filetype PEM if an SSL structure is set. this one's only supported if certificate operations are even permitted 🎀
  • -key file — tries to use file as the private key for the right context. also only supported if certificate operations are permitted. note: if you don't set a -key option, then a private key is not loaded unless the flag SSL_CONF_FLAG_REQUIRE_PRIVATE is set. so like, no key unless you ask for one 🌸
  • -dhparam file — tries to use file as the set of temporary DH parameters for the right context. yep, only supported if certificate operations are permitted 💜
  • -no_ssl3, -no_tls1, -no_tls1_1, -no_tls1_2, -no_tls1_3 — disables protocol support for SSLv3, TLSv1.0, TLSv1.1, TLSv1.2 or TLSv1.3 by setting SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, SSL_OP_NO_TLSv1_1, SSL_OP_NO_TLSv1_2 and SSL_OP_NO_TLSv1_3 respectively. > btw these are deprecated, bestie 😭 use -min_protocol and -max_protocol instead, no cap.
  • -anti_replay, -no_anti_replay — switches replay protection on or off, respectively. with replay protection on, OpenSSL will automatically detect if a session ticket has been used more than once, TLSv1.3 has been negotiated, and early data is enabled on the server. a full handshake is forced if a session ticket gets used a second or subsequent time. Anti-Replay is on by default unless it's overridden by a configuration file, and it's only used by servers. anti-replay measures are required for compliance with the TLSv1.3 specification. some applications may be able to mitigate the replay risks in other ways, and in those cases the built-in OpenSSL functionality isn't needed. switching off anti-replay is equivalent to SSL_OP_NO_ANTI_REPLAY 👑

🌈 SUPPORTED CONFIGURATION FILE COMMANDS 🌈

the option names that are currently supported for configuration files (i.e., when the flag SSL_CONF_FLAG_FILE is set) are all listed right here bestie 💖

ALL configuration file option names are case insensitive, so signaturealgorithms is recognised just as well as SignatureAlgorithms ✨ and unless it says otherwise, the value names are case insensitive too.

Note: the command prefix (if it's set) alters the recognised option values. so like, heads up 🫶
  • CipherString — sets the ciphersuite list for TLSv1.2 and below to value. this list gets combined with any configured TLSv1.3 ciphersuites. Note: syntax checking of value is currently not performed unless an SSL or SSL_CTX structure is associated with ctx. so it won't yell at you yet 🎀
  • Ciphersuites — sets the available ciphersuites for TLSv1.3 to value. it's a colon-separated list of TLSv1.3 ciphersuite names in order of preference. this list gets combined with any configured TLSv1.2 and below ciphersuites. see openssl-ciphers(1) for more info 💅
  • Certificate — tries to use the file value as the certificate for the right context. rn it uses SSL_CTX_use_certificate_chain_file() if an SSL_CTX structure is set, or SSL_use_certificate_file() with filetype PEM if an SSL structure is set. only supported if certificate operations are permitted 🌸
  • PrivateKey — tries to use the file value as the private key for the right context. only supported if certificate operations are permitted. Note: if no PrivateKey option is set, then a private key is not loaded unless SSL_CONF_FLAG_REQUIRE_PRIVATE is set 🔑
  • ChainCAFile, ChainCAPath, VerifyCAFile, VerifyCAPath — these indicate a file or directory used for building certificate chains or verifying certificate chains. only supported if certificate operations are permitted 🦋
  • RequestCAFile — indicates a file containing a set of certificates in PEM form. the subject names of the certificates are sent to the peer in the certificate_authorities extension for TLS 1.3 (in ClientHello or CertificateRequest) or in a certificate request for previous versions or TLS 💌
  • ServerInfoFile — tries to use the file value in the "serverinfo" extension using the function SSL_CTX_use_serverinfo_file ⭐
  • DHParameters — tries to use the file value as the set of temporary DH parameters for the right context. only supported if certificate operations are permitted 🧚
  • RecordPadding — controls use of TLSv1.3 record layer padding. value is a string of the form "number[,number]" where the (required) first number is the padding block size (in octets) for application data, and the optional second number is the padding block size for handshake and alert messages. if the optional second number is omitted, the same padding gets applied to all messages.

padding attempts to pad TLSv1.3 records so that they're a multiple of the set length on send. a value of 0 or 1 turns off padding as relevant. otherwise, the values must be >1 or <=16384.

Note: for QUIC objects, padding is always performed at the packet level, so it can't be done at the record level. and given that, when the config file is created, there's no knowledge of what kind of SSL objects are being created — this option is silently ignored for QUIC objects. like, it just doesn't say anything 💀
  • SignatureAlgorithms — this sets the supported signature algorithms for TLSv1.2 and TLSv1.3. for clients, this value is used directly for the supported signature algorithms extension. for servers, it's used to determine which signature algorithms to support.

the value argument should be a colon separated list of signature algorithms in order of decreasing preference, of the form algorithm+hash or signature_scheme. for the default providers shipped with OpenSSL, algorithm is one of RSA, DSA or ECDSA and hash is a supported algorithm OID short name such as SHA1, SHA224, SHA256, SHA384 or SHA512. signature_scheme is one of the signature schemes defined in TLSv1.3, specified using the IANA name, e.g., ecdsa_secp256r1_sha256, ed25519, or rsa_pss_pss_sha256. signature scheme names and public key algorithm names (but not the hash names) in the algorithm+hash form are case-insensitive. additional providers may make available further signature schemes via the TLS_SIGALG capability. see "CAPABILITIES" in provider-base(7) 🌟

if this option isn't set, then all signature algorithms supported by all activated providers are permissible.

Note: algorithms which specify a PKCS#1 v1.5 signature scheme (either by using RSA as the algorithm or by using one of the rsa_pkcs1_* identifiers) are ignored in TLSv1.3 and will not be negotiated. so don't even try it bestie 🙈
  • ClientSignatureAlgorithms — this sets the supported signature algorithms associated with client authentication for TLSv1.2 and TLSv1.3. for servers, the value is used in the signature_algorithms field of a CertificateRequest message. for clients, it's used to determine which signature algorithm to use with the client certificate. if a server doesn't request a certificate, this option has no effect 🫥

the syntax of value is identical to SignatureAlgorithms. if it's not set, then the value set for SignatureAlgorithms gets used instead 💖

  • Groups — this sets the supported groups. for clients, the groups are sent using the supported groups extension. for servers, it's used to determine which group to use. this setting affects groups used for signatures (in TLSv1.2 and earlier) and key exchange. the first group listed will also be used for the key_share sent by a client in a TLSv1.3 ClientHello 👑

the groups argument is a colon separated list of groups. the preferred names are the ones listed in the IANA TLS Supported Groups registry at https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8. for some groups, OpenSSL supports additional aliases. such an alias could be a NIST name (e.g. P-256), an OpenSSL OID name (e.g. prime256v1), or some other commonly used name. group names are case-insensitive in OpenSSL 3.5 and later. the list should be in order of preference with the most preferred group first 🌈

the commands below list the available groups for TLS 1.2 and TLS 1.3, respectively:

$ openssl list -tls1_2 -tls-groups
$ openssl list -tls1_3 -tls-groups

an enriched alternative syntax, that enables clients to send multiple keyshares and allows servers to prioritise some groups over others, is described in SSL_CTX_set1_groups_list(3). since TLS 1.2 has neither keyshares nor a hello retry mechanism, with TLS 1.2 the enriched syntax is ultimately equivalent to just a simple ordered list of groups, as with the simple form above 🦋

  • Curves — this is a synonym for the "Groups" command. same thing, different label, iconic 💅
  • MinProtocol — this sets the minimum supported SSL, TLS or DTLS version.

currently supported protocol values are SSLv3, TLSv1, TLSv1.1, TLSv1.2, TLSv1.3, DTLSv1 and DTLSv1.2. the SSL and TLS bounds apply only to TLS-based contexts, while the DTLS bounds apply only to DTLS-based contexts. the command can be repeated, with one instance setting a TLS bound and the other setting a DTLS bound. the value None applies to both types of contexts and disables the limits 🎀

  • MaxProtocol — this sets the maximum supported SSL, TLS or DTLS version.

currently supported protocol values are SSLv3, TLSv1, TLSv1.1, TLSv1.2, TLSv1.3, DTLSv1 and DTLSv1.2. the SSL and TLS bounds apply only to TLS-based contexts, while the DTLS bounds apply only to DTLS-based contexts. the command can be repeated, with one instance setting a TLS bound and the other setting a DTLS bound. the value None applies to both types of contexts and disables the limits 🎀

  • Protocol — this can be used to enable or disable certain versions of the SSL, TLS or DTLS protocol.

the value argument is a comma separated list of supported protocols to enable or disable. if a protocol is preceded by - then that version is disabled.

all protocol versions are enabled by default. you need to disable at least one protocol version for this setting to have any effect. only enabling some protocol versions does not disable the other protocol versions. so like, turning one thing on doesn't turn the rest off, careful bestie 😭

Currently supported protocol values are SSLv3, TLSv1, TLSv1.1, TLSv1.2, TLSv1.3, DTLSv1 and DTLSv1.2. And then there's the special value ALL, which means literally every supported version, the whole roster, periodt.

Okay so here's the tea: this one can't turn on protocols that got disabled by MinProtocol or MaxProtocol — but it CAN switch off protocols that those two still allow. One-way street, bestie.

The Protocol command is fragile and deprecated; do not use it. Use MinProtocol and MaxProtocol instead. And if you do use Protocol anyway (😭), make sure the resulting range of enabled protocols has no "holes" — like, if TLS 1.0 and TLS 1.2 are both enabled, make sure you also leave TLS 1.1 enabled. Gaps in the roster are not it.

🌸 Options 🌸

The value argument is a comma separated list of various flags to set. And if a flag string is preceded by - it gets disabled. Peep the SSL_CTX_set_options(3) function for more details on the individual options, iykyk.

Every option is listed below, and where an operation is enabled by default, you need the -flag syntax to turn it off. 💅

  • SessionTicket — session ticket support, enabled by default. It's the inverse of SSL_OP_NO_TICKET: so -SessionTicket is the exact same thing as setting SSL_OP_NO_TICKET.
  • Compression — SSL/TLS compression support, disabled by default. Inverse of SSL_OP_NO_COMPRESSION.
  • EmptyFragments — use empty fragments as a countermeasure against an SSL 3.0/TLS 1.0 protocol vulnerability affecting CBC ciphers. It's set by default. Inverse of SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS.
  • Bugs — enable various bug workarounds. Same as SSL_OP_ALL.
  • DHSingle — enable single use DH keys, set by default. Inverse of SSL_OP_DH_SINGLE. Servers only, bestie.
  • ECDHSingle — enable single use ECDH keys, set by default. Inverse of SSL_OP_ECDH_SINGLE. Also servers only.
  • ServerPreference — use server preference order and not client preference order when figuring out which cipher suite, signature algorithm, or elliptic curve (TLS 1.2) / group (TLS 1.3) to use for an incoming connection. Equivalent to SSL_OP_SERVER_PREFERENCE. Servers only.
  • PrioritizeChaCha — prioritizes ChaCha ciphers when the client has a ChaCha20 cipher sitting at the top of its preference list. Which usually means a mobile client is in the building. Equivalent to SSL_OP_PRIORITIZE_CHACHA. Servers only.
  • NoResumptionOnRenegotiation — sets the SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION flag. Servers only.
  • NoRenegotiation — disables all attempts at renegotiation in TLSv1.2 and earlier, same as setting SSL_OP_NO_RENEGOTIATION.
  • UnsafeLegacyRenegotiation — permits the use of unsafe legacy renegotiation. Equivalent to SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION.
  • UnsafeLegacyServerConnect — permits the use of unsafe legacy renegotiation for OpenSSL clients only. Equivalent to SSL_OP_LEGACY_SERVER_CONNECT.
  • EncryptThenMac — use the encrypt-then-mac extension, enabled by default. Inverse of SSL_OP_NO_ENCRYPT_THEN_MAC: that is, -EncryptThenMac is the same as setting SSL_OP_NO_ENCRYPT_THEN_MAC.
  • AllowNoDHEKEX — in TLSv1.3, allow a non-(ec)dhe based key exchange mode on resumption. Which means there will be no forward secrecy for the resumed session, so, noted. Equivalent to SSL_OP_ALLOW_NO_DHE_KEX.
  • PreferNoDHEKEX — in TLSv1.3, on resumption, let the server prefer a non-(ec)dhe based key exchange mode over an (ec)dhe based one. Requires AllowNoDHEKEX. Equivalent to SSL_OP_PREFER_NO_DHE_KEX. Servers only.
  • MiddleboxCompat — if set, dummy Change Cipher Spec (CCS) messages get sent in TLSv1.3. The whole point is making TLSv1.3 look more like TLSv1.2 so that middleboxes that don't understand TLSv1.3 won't drop the connection. This option is set by default. A future version of OpenSSL may not set this by default. Equivalent to SSL_OP_ENABLE_MIDDLEBOX_COMPAT.
  • AntiReplay — if set, OpenSSL will automatically detect if a session ticket has been used more than once, TLSv1.3 has been negotiated, and early data is enabled on the server. A full handshake is forced if a session ticket is used a second or subsequent time. This option is set by default and is only used by servers. Anti-replay measures are required to comply with the TLSv1.3 specification. Some applications may be able to mitigate the replay risks in other ways, and in those cases the built-in OpenSSL functionality is not required. Disabling anti-replay is equivalent to setting SSL_OP_NO_ANTI_REPLAY.
  • ExtendedMasterSecret — use the extended master secret extension, enabled by default. Inverse of SSL_OP_NO_EXTENDED_MASTER_SECRET: that is, -ExtendedMasterSecret is the same as setting SSL_OP_NO_EXTENDED_MASTER_SECRET.
  • CANames — use the CA names extension, enabled by default. Inverse of SSL_OP_DISABLE_TLSEXT_CA_NAMES: that is, -CANames is the same as setting SSL_OP_DISABLE_TLSEXT_CA_NAMES.
  • KTLS — enables kernel TLS if support has been compiled in, and it's supported by the negotiated ciphersuites and extensions. Equivalent to SSL_OP_ENABLE_KTLS.
  • StrictCertCheck — enable strict certificate checking. Equivalent to setting SSL_CERT_FLAG_TLS_STRICT with SSL_CTX_set_cert_flags().
  • TxCertificateCompression — support sending compressed certificates, enabled by default. Inverse of SSL_OP_NO_TX_CERTIFICATE_COMPRESSION: that is, -TxCertificateCompression is the same as setting SSL_OP_NO_TX_CERTIFICATE_COMPRESSION.
  • RxCertificateCompression — support receiving compressed certificates, enabled by default. Inverse of SSL_OP_NO_RX_CERTIFICATE_COMPRESSION: that is, -RxCertificateCompression is the same as setting SSL_OP_NO_RX_CERTIFICATE_COMPRESSION.
  • KTLSTxZerocopySendfile — use the zerocopy TX mode of sendfile(), which gives a performance boost when used with KTLS hardware offload. Heads up though: invalid TLS records might be transmitted if the file is changed while it's being sent. 😬 This option has no effect if KTLS is not enabled. Equivalent to SSL_OP_ENABLE_KTLS_TX_ZEROCOPY_SENDFILE. This option only applies to Linux. KTLS sendfile on FreeBSD doesn't offer an option to disable zerocopy and always runs in this mode.
  • IgnoreUnexpectedEOF — equivalent to SSL_OP_IGNORE_UNEXPECTED_EOF. You should only enable this option if the protocol running over TLS can detect a truncation attack itself, and that the application is checking for that truncation attack. Don't just yolo it.

🦋 VerifyMode 🦋

The value argument here is a comma separated list of flags to set.

  • Peer — enables peer verification. Clients only.
  • Request — requests but does not require a certificate from the client. Servers only.
  • Require — requests and requires a certificate from the client: an error occurs if the client does not present a certificate. Servers only.
  • Once — requests a certificate from a client only on the initial connection, not when renegotiating. Servers only.
  • RequestPostHandshake — configures the connection to support requests but does not require a certificate from the client post-handshake. A certificate will not be requested during the initial handshake. The server application must provide a mechanism to request a certificate post-handshake. Servers only. TLSv1.3 only.
  • RequiresPostHandshake — configures the connection to support requests and requires a certificate from the client post-handshake: an error occurs if the client does not present a certificate. A certificate will not be requested during the initial handshake. The server application must provide a mechanism to request a certificate post-handshake. Servers only. TLSv1.3 only.

🎀 ClientCAFile, ClientCAPath 🎀

A file or directory of certificates in PEM format whose names are used as the set of acceptable names for client CAs. Servers only. This option is only supported if certificate operations are permitted.

👑 SUPPORTED COMMAND TYPES 👑

The function SSL_CONF_cmd_value_type() currently returns one of the following types:

  • SSL_CONF_TYPE_UNKNOWN — the option string is unrecognised. This return value can be used to flag syntax errors.
  • SSL_CONF_TYPE_STRING — the value is a string without any specific structure.
  • SSL_CONF_TYPE_FILE — the value is a filename.
  • SSL_CONF_TYPE_DIR — the value is a directory name.
  • SSL_CONF_TYPE_NONE — the value string is not used, e.g. a command line option which doesn't take an argument.

💌 NOTES 💌

The order of operations is significant, like, it genuinely matters. This can be used to set either defaults or values which cannot be overridden. For example, if an application calls:

 SSL_CONF_cmd(ctx, "Protocol", "-SSLv3");
 SSL_CONF_cmd(ctx, userparam, uservalue);

it will disable SSLv3 support by default but the user can override it. If however the call sequence is:

 SSL_CONF_cmd(ctx, userparam, uservalue);
 SSL_CONF_cmd(ctx, "Protocol", "-SSLv3");

then SSLv3 is always disabled and attempts to override this by the user are ignored. Order is everything, bestie. 🔥

By checking the return code of SSL_CONF_cmd() it is possible to query if a given option is recognised. This is useful if SSL_CONF_cmd() values are mixed with additional application specific operations.

For example, an application might call SSL_CONF_cmd() and if it returns -2 (unrecognised command) continue with processing of application specific commands.

Applications can also use SSL_CONF_cmd() to process command lines, though the utility function SSL_CONF_cmd_argv() is normally used instead. One way to do this is to set the prefix to an appropriate value using SSL_CONF_CTX_set1_prefix(), pass the current argument to option and the following argument to value (which may be NULL).

In this case, if the return value is positive then it is used to skip that number of arguments as they have been processed by SSL_CONF_cmd(). If -2 is returned then option is not recognised and application specific arguments can be checked instead. If -3 is returned a required argument is missing and an error is indicated. If 0 is returned some other error occurred and this can be reported back to the user.

The function SSL_CONF_cmd_value_type() can be used by applications to check for the existence of a command or to perform additional syntax checking or translation of the command value. For example, if the return value is SSL_CONF_TYPE_FILE an application could translate a relative pathname to an absolute pathname. ✨

💖 RETURN VALUES 💖

okay so this is the part where you find out what it actually gives back, and bestie, it's giving number of args processed, which is lowkey genius:

  • 1 — the option got recognised but the value is NOT used.
  • 2 — both the option AND the value got used. basically, this is the number of arguments it chewed through. super handy when you're parsing command lines, fr fr.
  • -2 — nah, that option is not recognised, sorry babe.
  • -3 — the option IS recognised, and it needs a value, but value is NULL. 🫠
  • 0 — option and value are both valid, but the operation itself flopped. like, maybe the syntax of value was whack. in that case, check the error queue for the receipts — it might have extra info for you. 👑

✨ EXAMPLES ✨

kay so let's actually do stuff. setting the supported signature algorithms:

SSL_CONF_cmd(ctx, "SignatureAlgorithms", "ECDSA+SHA256:RSA+SHA256:DSA+SHA256");

now, picking which protocols you support? there's like, several ways to serve this look. 💅

this one sets the minimum protocol version to TLSv1, which means SSLv3 is out. this is the recommended way to disable protocols, bestie, take notes:

SSL_CONF_cmd(ctx, "MinProtocol", "TLSv1");

this one also disables SSLv3, same energy, different font:

SSL_CONF_cmd(ctx, "Protocol", "-SSLv3");

and this one? it first enables all the protocols, then disables SSLv3. if nothing was disabled before, it's literally the same as "-SSLv3", but if some versions were disabled, this re-enables them before killing SSLv3. glow-up sequence:

SSL_CONF_cmd(ctx, "Protocol", "ALL,-SSLv3");

only want TLSv1.2? obsessed. here:

SSL_CONF_cmd(ctx, "MinProtocol", "TLSv1.2");
SSL_CONF_cmd(ctx, "MaxProtocol", "TLSv1.2");

this ALSO only enables TLSv1.2, different route, same destination:

SSL_CONF_cmd(ctx, "Protocol", "-ALL,TLSv1.2");

disabling TLS session tickets, if they're not the vibe:

SSL_CONF_cmd(ctx, "Options", "-SessionTicket");

enabling compression:

SSL_CONF_cmd(ctx, "Options", "Compression");

and setting your supported curves to P-256 and P-384:

SSL_CONF_cmd(ctx, "Curves", "P-256:P-384");

🦋 SEE ALSO 🦋

the whole friend group, go say hi:

🌈 HISTORY 🌈

storytime, gather round, here's the lore:

  • the SSL_CONF_cmd() function dropped in OpenSSL 1.0.2.
  • the SSL_OP_NO_SSL2 option hasn't had any effect since 1.1.0, but the macro was kept around for backwards compatibility. it's just... chillin'. 💀
  • SSL_CONF_TYPE_NONE was added in OpenSSL 1.1.0. in earlier versions, passing a command that didn't take an argument would return SSL_CONF_TYPE_UNKNOWN.
  • MinProtocol and MaxProtocol were added in OpenSSL 1.1.0.
  • AllowNoDHEKEX and PrioritizeChaCha were added in OpenSSL 1.1.1.
  • the UnsafeLegacyServerConnect option is no longer set by default as of OpenSSL 3.0.
  • the TxCertificateCompression and RxCertificateCompression options were added in OpenSSL 3.2.
  • PreferNoDHEKEX was added in OpenSSL 3.3.
  • OpenSSL 3.5 introduced support for post-quantum (PQ) TLS key exchange via the MLKEM512, MLKEM768 and MLKEM1024 TLS groups. these are based on the underlying ML-KEM-512, ML-KEM-768 and ML-KEM-1024 algorithms from FIPS 203. ✨
  • OpenSSL 3.5 also introduced three hybrid ECDH PQ key exchange TLS groups: X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. they give CPU performance comparable to the associated ECDH group, but the cost is significantly larger key exchange messages. the third one, SecP384r1MLKEM1024, is substantially more CPU-intensive, mostly because ECDH is so expensive for the underlying P-384 group. also its key exchange messages are close to 1700 bytes, way bigger than the roughly 1200 bytes for the first two groups. 😭
  • OpenSSL 4.0 introduced the curveSM2 (also known as "ECDHE over SM2") key exchange group as specified in RFC8998, plus curveSM2MLKEM768, which is a hybrid of the curveSM2 group with ML-KEM-768. 👑
  • as of OpenSSL 3.5, key exchange group names are case-insensitive. periodt.

Copyright 2012-2026 The OpenSSL Project Authors. All Rights Reserved.

licensed under the Apache License 2.0 (the "License"). you may not use this file except in compliance with the License. you can grab a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

okay bestie that's the whole page, you made it to the end 🫶 this was 4.0.3, dated 2026-09-29, and yeah it's the SSL_CONF_CMD(3SSL) manual page. no cap. now go configure some protocols, you main character. 💅🌸

📦 where this page comes from