SSL_CONF_CMD(3ossl)
๐ SSL_CONF_CMD(3ossl) ๐
the OpenSSL manual page, but make it make sense ๐
๐ธ NAME ๐ธ
SSL_CONF_cmd_value_type, SSL_CONF_cmd โ send configuration command. That's the whole vibe: two little config-command besties. ๐ซถ
๐ 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);
๐ DESCRIPTION ๐
Okay so SSL_CONF_cmd() is the main character: it performs the configuration operation option with the optional parameter value on ctx. Its whole purpose is to simplify application configuration of SSL_CTX or SSL structures by giving you a common framework for command line options or configuration files. Slay. โจ
SSL_CONF_cmd_value_type() is the vibe-checker: it returns the type of value that option refers to. ๐ซถ
โจ SUPPORTED COMMAND LINE COMMANDS โจ
Here's the current roster of option names for command lines (i.e. when the flag SSL_CONF_FLAG_CMDLINE is set). Note: all option names are case sensitive โ yes, literally all of them. Unless otherwise stated, commands can be used by both clients and servers and the value parameter is not used. The default prefix for command line commands is -, and that's reflected below. ๐
-bugsโ Various bug workarounds are set, same as settingSSL_OP_ALL. Little chaos gremlin mode, but make it compatibility. ๐-no_compโ Disables support for SSL/TLS compression, same as settingSSL_OP_NO_COMPRESSION. As of OpenSSL 1.1.0, compression is off by default. So this is mostly you saying "no thank you" to something already not invited. ๐-compโ Enables support for SSL/TLS compression, same as clearingSSL_OP_NO_COMPRESSION. This command was introduced in OpenSSL 1.1.0. As of OpenSSL 1.1.0, compression is off by default. 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 will have no effect without also changing the security level. SeeSSL_CTX_set_security_level(3). So yeah, it's giving "I can fix her" but security level said no. ๐ญ-no_ticketโ Disables support for session tickets, same as settingSSL_OP_NO_TICKET. No ticket, no entry, no cap. ๐๏ธโ-serverprefโ Use server and not client preference order when determining which cipher suite, signature algorithm or elliptic curve to use for an incoming connection. Equivalent toSSL_OP_CIPHER_SERVER_PREFERENCE. Only used by servers. Server said "my house, my rules." ๐-client_renegotiationโ Allows servers to accept client-initiated renegotiation. Equivalent to settingSSL_OP_ALLOW_CLIENT_RENEGOTIATION. Only used by servers. Let the client cook, but only if the server allows it. ๐-legacy_renegotiationโ Permits the use of unsafe legacy renegotiation. Equivalent to settingSSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION.
โ ๏ธ The word unsafe is literally right there in the name, bestie. This is the "handle with care" one. โ ๏ธ
-no_renegotiationโ Disables all attempts at renegotiation in (D)TLSv1.2 and earlier, same as settingSSL_OP_NO_RENEGOTIATION. Renegotiation? Blocked. Periodt. ๐ซ-no_resumption_on_renegโ SetsSSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION. Only used by servers. No resumption on reneg, exactly what the name says. ๐-legacy_server_connect,-no_legacy_server_connectโ Permits or prohibits the use of unsafe legacy renegotiation for OpenSSL clients only. Equivalent to setting or clearingSSL_OP_LEGACY_SERVER_CONNECT. Clients only โ servers, this is not your lane. ๐ฃ๏ธ-prioritize_chachaโ Prioritize ChaCha ciphers when the client has a ChaCha20 cipher at the top of its preference list. This usually indicates a client without AES hardware acceleration (e.g. mobile) is in use. Equivalent toSSL_OP_PRIORITIZE_CHACHA. Only used by servers. Requires-serverpref. Mobile-coded client? ChaCha gets the aux. ๐-allow_no_dhe_kexโ In TLSv1.3 allow a non-(ec)dhe based key exchange mode on resumption. This means that there will be no forward secrecy for the resumed session.
โ ๏ธ This means no forward secrecy for the resumed session. That's the actual trade-off, not a vibe. ๐ฌ
-prefer_no_dhe_kexโ In TLSv1.3, on resumption let the server prefer a non-(ec)dhe based key exchange mode over an (ec)dhe based one. Requires-allow_no_dhe_kex. Equivalent toSSL_OP_PREFER_NO_DHE_KEX. Only used by servers. Fancy resumption preference, server-side only. ๐ซถ-strictโ Enables strict mode protocol handling. Equivalent to settingSSL_CERT_FLAG_TLS_STRICT. Strict mode is highkey that girl. ๐-sigalgs algsโ 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 is used to determine 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 available further algorithms 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. See provider-base(7).
If this option is not 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. That's the rule, bestie. ๐ซ
-client_sigalgs algsโ This sets the supported signature algorithms associated with client authentication for TLSv1.2 and TLSv1.3. For servers thealgsis used in thesignature_algorithmsfield of aCertificateRequestmessage. For clients it is used to determine which signature algorithm to use with the client certificate. If a server does not request a certificate this option has no effect.
The syntax of algs is identical to -sigalgs. If not set, then the value set for -sigalgs will be used instead. So it's the client-auth remix of the same syntax. ๐
-groups groupsโ This sets the supported groups. For clients, the groups are sent using the supported groups extension. For servers, it is 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 those 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 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, 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 groupsโ This is a synonym for the-groupscommand. Same tea, different label. ๐ซ-named_curve curveโ This 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. Send those compressed certs. ๐ค-no_tx_cert_compโ Disables support for sending TLSv1.3 compressed certificates. No sendy. ๐ซ๐ค-rx_cert_compโ Enables support for receiving TLSv1.3 compressed certificates. Receive era. ๐ฅ-no_rx_cert_compโ Disables support for receiving TLSv1.3 compressed certificates. No receivey. ๐ซ๐ฅ-compโ yes, this one appears again right here in the list before-cipher; no separate description is attached on this line, so the compression details above are the ones that apply. ๐-cipher ciphersโ Sets the TLSv1.2 and below ciphersuite list tociphers. This list will be combined with any configured TLSv1.3 ciphersuites. Note: syntax checking ofciphersis currently not performed unless aSSLorSSL_CTXstructure is associated withctx. That "unless" is doing a lot of heavy lifting, so don't assume it checks for you. ๐ญ-ciphersuites 1.3ciphersโ Sets the available ciphersuites for TLSv1.3 tovalue. This is a colon-separated list of TLSv1.3 ciphersuite names in order of preference. This list will be combined any configured TLSv1.2 and below ciphersuites. Seeopenssl-ciphers(1)for more information. TLS 1.3 ciphers, coming through. โจ-min_protocol minprot,-max_protocol maxprotโ Sets the minimum and maximum supported protocol. Currently supported protocol values areSSLv3,TLSv1,TLSv1.1,TLSv1.2,TLSv1.3for TLS;DTLSv1,DTLSv1.2for DTLS, andNonefor no limit. If either the lower or upper bound is not specified then only the other bound applies, if 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.paddingis 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 attempts to pad TLSv1.3 records so that they are 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. Numbers have boundaries, bestie. ๐
-debug_broken_protocolโ Ignored. That's it. It's giving "I'm just here for the vibes." ๐-no_middleboxโ turns off "middlebox compatibility", which is explained just below this, bestie.
๐ซ Additional Options ๐ซ
So these next ones are lowkey special โ SSL_CONF_cmd() accepts them, but the OpenSSL commands themselves are not processing them. Not a vibe check fail, it's just how it is ๐ซถ
-certfile โ tries to use file as the certificate for the right context. Rn it usesSSL_CTX_use_certificate_chain_file()if anSSL_CTXstructure is set, orSSL_use_certificate_file()with filetypePEMif anSSLstructure is set. This option is only supported if certificate operations are permitted, no cap.-keyfile โ tries to use file as the private key for the right context. Only supported if certificate operations are permitted. Note: if no-keyoption is set, then a private key is not loaded unless the flagSSL_CONF_FLAG_REQUIRE_PRIVATEis set. Read that twice, it's giving sneaky.-dhparamfile โ tries to use file as the set of temporary DH parameters for the right context. 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 the corresponding optionsSSL_OP_NO_SSLv3,SSL_OP_NO_TLSv1,SSL_OP_NO_TLSv1_1,SSL_OP_NO_TLSv1_2andSSL_OP_NO_TLSv1_3respectively. These options are deprecated ๐ โ use-min_protocoland-max_protocolinstead.-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 is used a second or subsequent time. Anti-Replay is on by default unless overridden by a configuration file, and is only used by servers. Anti-replay measures are required for compliance with the TLSv1.3 specification โ icon behaviour honestly. Some applications may be able to mitigate the replay risks in other ways, and in such cases the built-in OpenSSL functionality is not required. Switching off anti-replay is equivalent toSSL_OP_NO_ANTI_REPLAY.
๐ธ SUPPORTED CONFIGURATION FILE COMMANDS ๐ธ
Okay so the option names that configuration files support rn โ meaning when the flag SSL_CONF_FLAG_FILE is set โ are listed below. And here's the cute part: all configuration file option names are case insensitive, so signaturealgorithms is recognised just as well as SignatureAlgorithms. Unless it says otherwise, the value names are case insensitive too. Slay for accessibility โจ
Note: the command prefix (if set) alters the recognised option values. Don't forget, babes.
CipherStringโ sets the ciphersuite list for TLSv1.2 and below to value. This list will be combined with any configured TLSv1.3 ciphersuites. Note: syntax checking of value is currently not performed unless anSSLorSSL_CTXstructure is associated withctx. So like, it might not catch you until later ๐Ciphersuitesโ 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 any configured TLSv1.2 and below ciphersuites. Seeopenssl-ciphers(1)for more info.Certificateโ tries to use the file value as the certificate for the right context. It currently usesSSL_CTX_use_certificate_chain_file()if anSSL_CTXstructure is set, orSSL_use_certificate_file()with filetypePEMif anSSLstructure is set. This option is 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 noPrivateKeyoption is set, then a private key is not loaded unless theSSL_CONF_FLAG_REQUIRE_PRIVATEis set.ChainCAFile,ChainCAPath,VerifyCAFile,VerifyCAPathโ these options indicate a file or directory used for building certificate chains or verifying certificate chains. Only supported if certificate operations are permitted.RequestCAFileโ this option indicates a file containing a set of certificates in PEM form. The subject names of the certificates are sent to the peer in thecertificate_authoritiesextension 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 functionSSL_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 will be 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 that, for QUIC objects, padding is always performed at the packet level, and so cannot be done at the record level. Given that, when the config file is created, there is no knowledge of what kind of SSL objects are being created, this option is silently ignored for QUIC objects. Silently ๐ญ like it just ghosts you.
SignatureAlgorithmsโ 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 is not 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 usingRSAas the algorithm or by using one of thersa_pkcs1_*identifiers) are ignored in TLSv1.3 and will not be negotiated. Not them being left on read ๐
ClientSignatureAlgorithmsโ sets the supported signature algorithms associated with client authentication for TLSv1.2 and TLSv1.3. For servers the value is used in thesignature_algorithmsfield of a CertificateRequest message. For clients it's used to determine which signature algorithm to use with the client certificate. If a server does not request a certificate, this option has no effect โ it's giving "no thoughts, head empty" ๐
The syntax of value is identical to SignatureAlgorithms. If not set, then the value set for SignatureAlgorithms will be used instead.
Groupsโ 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 thekey_sharesent by a client in a TLSv1.3 ClientHello.
The groups argument is a colon separated list of groups. The preferred names are those 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 โ most favourite child energy ๐
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 name, both eat ๐MinProtocolโ 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โ 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 - that version is disabled.
All protocol versions are enabled by default. You need to disable at least one protocol version for this setting have any effect โ read that again, bestie, enabling stuff does not turn off the rest. Only enabling some protocol versions does not disable the other protocol versions. The way that trips everyone up ๐ญ
so the protocol values you can throw at it right now are SSLv3, TLSv1, TLSv1.1, TLSv1.2, TLSv1.3, DTLSv1 and DTLSv1.2 ๐ and there's this โจspecialโจ value ALL that literally means all supported versions, iconic.
okay but real talk โ this can't enable protocols that got disabled by MinProtocol or MaxProtocol, bestie. it can only disable protocols that those two still allow. so don't come for settings that already said no ๐
๐จ theProtocolcommand is fragile and deprecated โ do NOT use it. useMinProtocolandMaxProtocolinstead, periodt. and if you absolutely must useProtocol, make sure the resulting range of enabled protocols has no "holes", like โ if TLS 1.0 and TLS 1.2 are both enabled, please please please also leave TLS 1.1 enabled. no swiss-cheese protocol ranges ๐ง๐
โจ Options โจ
the value argument is a comma-separated list of various flags you wanna set ๐ and if a flag string is preceded by - it gets disabled. head to SSL_CTX_set_options(3) for the full tea on individual options, iykyk.
every option is listed below, and where an operation is enabled by default, the -flag syntax is what you need to turn it off ๐
SessionTicketโ session ticket support, enabled by default. inverse ofSSL_OP_NO_TICKET: meaning-SessionTicketis literally the same as settingSSL_OP_NO_TICKET๐๏ธCompressionโ SSL/TLS compression support, disabled by default. inverse ofSSL_OP_NO_COMPRESSION.EmptyFragmentsโ uses empty fragments as a countermeasure against an SSL 3.0/TLS 1.0 protocol vulnerability affecting CBC ciphers. it's set by default. inverse ofSSL_OP_DONT_INSERT_EMPTY_FRAGMENTS๐งฉBugsโ enables various bug workarounds. same asSSL_OP_ALL. bless the messy legacy code ๐DHSingleโ enables single use DH keys, set by default. inverse ofSSL_OP_DH_SINGLE. servers only, bestie.ECDHSingleโ enables single use ECDH keys, set by default. inverse ofSSL_OP_ECDH_SINGLE. servers only ๐ธServerPreferenceโ uses server and not client preference order when working out which cipher suite, signature algorithm or elliptic curve to use for an incoming connection. equivalent toSSL_OP_CIPHER_SERVER_PREFERENCE. servers only ๐PrioritizeChaChaโ prioritizes ChaCha ciphers when the client has a ChaCha20 cipher at the top of its preference list. this usually indicates a mobile client is in use ๐ฑ equivalent toSSL_OP_PRIORITIZE_CHACHA. servers only.NoResumptionOnRenegotiationโ sets theSSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATIONflag. servers only.NoRenegotiationโ disables all attempts at renegotiation in TLSv1.2 and earlier, same as settingSSL_OP_NO_RENEGOTIATION.UnsafeLegacyRenegotiationโ permits the use of unsafe legacy renegotiation ๐จ equivalent toSSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION.UnsafeLegacyServerConnectโ permits the use of unsafe legacy renegotiation for OpenSSL clients only. equivalent toSSL_OP_LEGACY_SERVER_CONNECT.EncryptThenMacโ uses the encrypt-then-mac extension, enabled by default. inverse ofSSL_OP_NO_ENCRYPT_THEN_MAC: that is,-EncryptThenMacis the same as settingSSL_OP_NO_ENCRYPT_THEN_MAC๐AllowNoDHEKEXโ in TLSv1.3, allows a non-(ec)dhe based key exchange mode on resumption. this means there will be no forward secrecy for the resumed session ๐ญ equivalent toSSL_OP_ALLOW_NO_DHE_KEX.PreferNoDHEKEXโ in TLSv1.3, on resumption, lets the server prefer a non-(ec)dhe based key exchange mode over an (ec)dhe based one. requiresAllowNoDHEKEX. equivalent toSSL_OP_PREFER_NO_DHE_KEX. servers only.MiddleboxCompatโ if set, dummy Change Cipher Spec (CCS) messages get sent in TLSv1.3 ๐ this has the effect of making TLSv1.3 look more like TLSv1.2 so that middleboxes who 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 toSSL_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 such cases the built-in OpenSSL functionality is not required. disabling anti-replay is equivalent to settingSSL_OP_NO_ANTI_REPLAY.ExtendedMasterSecretโ uses the extended master secret extension, enabled by default. inverse ofSSL_OP_NO_EXTENDED_MASTER_SECRET: that is,-ExtendedMasterSecretis the same as settingSSL_OP_NO_EXTENDED_MASTER_SECRETโจCANamesโ uses the CA names extension, enabled by default. inverse ofSSL_OP_DISABLE_TLSEXT_CA_NAMES: that is,-CANamesis the same as settingSSL_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 toSSL_OP_ENABLE_KTLS๐ฅStrictCertCheckโ enables strict certificate checking. equivalent to settingSSL_CERT_FLAG_TLS_STRICTwithSSL_CTX_set_cert_flags()โญTxCertificateCompressionโ supports sending compressed certificates, enabled by default. inverse ofSSL_OP_NO_TX_CERTIFICATE_COMPRESSION: that is,-TxCertificateCompressionis the same as settingSSL_OP_NO_TX_CERTIFICATE_COMPRESSION๐ฆRxCertificateCompressionโ supports receiving compressed certificates, enabled by default. inverse ofSSL_OP_NO_RX_CERTIFICATE_COMPRESSION: that is,-RxCertificateCompressionis the same as settingSSL_OP_NO_RX_CERTIFICATE_COMPRESSION๐ฅKTLSTxZerocopySendfileโ uses the zerocopy TX mode ofsendfile(), which gives a performance boost when used with KTLS hardware offload ๐ note that invalid TLS records might be transmitted if the file is changed while being sent ๐ญ this option has no effect if KTLS is not enabled. equivalent toSSL_OP_ENABLE_KTLS_TX_ZEROCOPY_SENDFILE. this option only applies to Linux ๐ง KTLSsendfileon FreeBSD doesn't offer an option to disable zerocopy and always runs in this mode.IgnoreUnexpectedEOFโ equivalent toSSL_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 ๐
๐ VerifyMode ๐
the value argument is a comma-separated list of flags to set, bestie:
Peerโ enables peer verification: for 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 doesn't 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 won't 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 doesn't present a certificate. a certificate won't 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 โ you can use this return value 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 ๐ญ
okay this is the part where order actually matters, no cap. the order of operations is significant. you can use it 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 ๐ that's just how it is.
by checking the return code of SSL_CONF_cmd() it's possible to query if a given option is recognised โ super 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's used to skip that number of arguments as they've 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. slay.
๐ RETURN VALUES ๐
okay so SSL_CONF_cmd() is literally gonna hand you back a number and you gotta know what it means, bestie, so let's break it down:
- it returns 1 when the option is recognised and value is NOT used
- it returns 2 when both option and value get used
in other words โ and this is the vibe โ it returns the number of arguments it processed. which is super handy when you're chewing through command lines fr fr โจ
then the spicy ones:
- -2 means option is not recognised ๐ (she doesn't know her)
- -3 means option is recognised and the command requires a value, but value is
NULL๐ญ - 0 means both option and value are valid but something went wrong actually doing the thing โ like, say, there's an error in the syntax of value. in that case the error queue may have extra info for you ๐ซถ
๐ธ EXAMPLES ๐ธ
okay bestie, here's where it gets fun. setting the supported signature algorithms:
SSL_CONF_cmd(ctx, "SignatureAlgorithms", "ECDSA+SHA256:RSA+SHA256:DSA+SHA256");
there are various ways to select the supported protocols, and honestly it's giving choose-your-own-adventure ๐
this sets the minimum protocol version to TLSv1, which disables SSLv3. this is the recommended way to disable protocols:
SSL_CONF_cmd(ctx, "MinProtocol", "TLSv1");
the following also disables SSLv3:
SSL_CONF_cmd(ctx, "Protocol", "-SSLv3");
the following will first enable all protocols, and then disable SSLv3. if no protocol versions were disabled before, this has the same effect as -SSLv3 โ but if some versions were disabled, this will re-enable them before disabling SSLv3. sneaky? no. iconic? yes โจ
SSL_CONF_cmd(ctx, "Protocol", "ALL,-SSLv3");
only enable TLSv1.2:
SSL_CONF_cmd(ctx, "MinProtocol", "TLSv1.2");
SSL_CONF_cmd(ctx, "MaxProtocol", "TLSv1.2");
this also only enables TLSv1.2:
SSL_CONF_cmd(ctx, "Protocol", "-ALL,TLSv1.2");
disable TLS session tickets:
SSL_CONF_cmd(ctx, "Options", "-SessionTicket");
enable compression:
SSL_CONF_cmd(ctx, "Options", "Compression");
set supported curves to P-256, P-384:
SSL_CONF_cmd(ctx, "Curves", "P-256:P-384");
go off, honestly ๐ฅ
๐ฆ SEE ALSO ๐ฆ
like, go read these too, they're all in the group chat:
ssl(7)SSL_CONF_CTX_new(3)SSL_CONF_CTX_set_flags(3)SSL_CONF_CTX_set1_prefix(3)SSL_CONF_CTX_set_ssl_ctx(3)SSL_CONF_cmd_argv(3)SSL_CTX_set_options(3)
๐ HISTORY ๐
storytime, gather round ๐ง
the SSL_CONF_cmd() function was added in OpenSSL 1.0.2.
the SSL_OP_NO_SSL2 option doesn't have any effect since 1.1.0, but the macro is retained for backwards compatibility. (she's retired but she's still on the payroll, iykyk ๐)
the SSL_CONF_TYPE_NONE was added in OpenSSL 1.1.0. in earlier versions of OpenSSL, passing a command which didn't take an argument would return SSL_CONF_TYPE_UNKNOWN. glow-up behavior honestly.
MinProtocol and MaxProtocol where added in OpenSSL 1.1.0. (yes bestie, the manpage literally says "where" โ we don't fix, we preserve ๐
)
AllowNoDHEKEX and PrioritizeChaCha were added in OpenSSL 1.1.1.
the UnsafeLegacyServerConnect option is no longer set by default from OpenSSL 3.0. important!! โ ๏ธ
the TxCertificateCompression and RxCertificateCompression options were added in OpenSSL 3.2.
PreferNoDHEKEX was added in OpenSSL 3.3.
OpenSSL 3.5 introduces 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. quantum era unlocked ๐โจ
OpenSSL 3.5 also introduces support for three hybrid ECDH PQ key exchange TLS groups: X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. they offer CPU performance comparable to the associated ECDH group, though at the cost of significantly larger key exchange messages. the third group, SecP384r1MLKEM1024 is substantially more CPU-intensive, largely as a result of the high CPU cost of ECDH for the underlying P-384 group. also its key exchange messages at close to 1700 bytes are larger than the roughly 1200 bytes for the first two groups. she's high-maintenance and we respect it ๐
as of OpenSSL 3.5, key exchange group names are case-insensitive ๐
๐ COPYRIGHT ๐
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 obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.
and that's the whole page, bestie!! you made it to the end, i'm so proud ๐ซถ๐ this was version 3.5.6, dated 2026-04-07, and it's the SSL_CONF_CMD(3ossl) page โ periodt. go configure some SSL, you've got this. ๐โญ
๐ฆ where this page comes from
- freebsd 15.1: base 15.1
- ๐ girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms