-</code></pre></div><h2 id=description>DESCRIPTION<a class=headerlink href=#description title="Permanent link">¶</a></h2><p>SSL_CTX_set1_sigalgs() and SSL_set1_sigalgs() set the supported signature algorithms for <strong>ctx</strong> or <strong>ssl</strong>. The array <strong>slist</strong> of length <strong>slistlen</strong> must consist of pairs of NIDs corresponding to digest and public key algorithms.</p><p>SSL_CTX_set1_sigalgs_list() and SSL_set1_sigalgs_list() set the supported signature algorithms for <strong>ctx</strong> or <strong>ssl</strong>. The <strong>str</strong> parameter must be a null terminated string consisting of a colon separated list of elements, where each element is either a combination of a public key algorithm and a digest separated by <strong>+</strong>, or a TLS 1.3-style named SignatureScheme such as rsa_pss_pss_sha256. Signature scheme names and public key algorithm names (but not the digest names) in the <strong>algoirithm+hash</strong> form are case-insensitive. If a list entry is preceded with the <code>?</code> character, it will be ignored if an implementation is missing.</p><p>SSL_CTX_set1_client_sigalgs(), SSL_set1_client_sigalgs(), SSL_CTX_set1_client_sigalgs_list() and SSL_set1_client_sigalgs_list() set signature algorithms related to client authentication, otherwise they are identical to SSL_CTX_set1_sigalgs(), SSL_set1_sigalgs(), SSL_CTX_set1_sigalgs_list() and SSL_set1_sigalgs_list().</p><p>All these functions are implemented as macros. The signature algorithm parameter (integer array or string) is not freed: the application should free it, if necessary.</p><h2 id=notes>NOTES<a class=headerlink href=#notes title="Permanent link">¶</a></h2><p>If an application wishes to allow the setting of signature algorithms as one of many user configurable options it should consider using the more flexible SSL_CONF API instead.</p><p>The signature algorithms set by a client are used directly in the supported signature algorithm in the client hello message.</p><p>The supported signature algorithms set by a server are not sent to the client but are used to determine the set of shared signature algorithms and (if server preferences are set with SSL_OP_CIPHER_SERVER_PREFERENCE) their order.</p><p>The client authentication signature algorithms set by a server are sent in a certificate request message if client authentication is enabled, otherwise they are unused.</p><p>Similarly client authentication signature algorithms set by a client are used to determined the set of client authentication shared signature algorithms.</p><p>Signature algorithms will neither be advertised nor used if the security level prohibits them (for example SHA1 if the security level is 4 or more).</p><p>Currently the NID_md5, NID_sha1, NID_sha224, NID_sha256, NID_sha384 and NID_sha512 digest NIDs are supported and the public key algorithm NIDs EVP_PKEY_RSA, EVP_PKEY_RSA_PSS, EVP_PKEY_DSA and EVP_PKEY_EC.</p><p>The short or long name values for digests can be used in a string (for example "MD5", "SHA1", "SHA224", "SHA256", "SHA384", "SHA512") and the public key algorithm strings "RSA", "RSA-PSS", "DSA" or "ECDSA".</p><p>The TLS 1.3 signature scheme names (such as "rsa_pss_pss_sha256") can also be used with the <strong>_list</strong> forms of the API.</p><p>The use of MD5 as a digest is strongly discouraged due to security weaknesses.</p><h2 id=return-values>RETURN VALUES<a class=headerlink href=#return-values title="Permanent link">¶</a></h2><p>All these functions return 1 for success and 0 for failure.</p><h2 id=examples>EXAMPLES<a class=headerlink href=#examples title="Permanent link">¶</a></h2><p>Set supported signature algorithms to SHA256 with ECDSA and SHA256 with RSA using an array:</p><div class=highlight><pre><span></span><code>const int slist[] = {NID_sha256, EVP_PKEY_EC, NID_sha256, EVP_PKEY_RSA};
0 commit comments