SSL_GET_SHARED_SIGALGS(3SSL)
π SSL_GET_SHARED_SIGALGS π
okay bestie, so this is the 3SSL OpenSSL manual page for the signature-algorithm-gossip squad: SSL_get0_shared_sigalg, SSL_get0_sigalg, SSL_get_shared_sigalgs, and SSL_get_sigalgs. They all get you the tea on which signature algorithms are in play. π«Ά Let's get into it.
β¨ NAME β¨
SSL_get0_shared_sigalg, SSL_get0_sigalg, SSL_get_shared_sigalgs, SSL_get_sigalgs β get shared or peer signature algorithms π
πΈ SYNOPSIS πΈ
#include <openssl/ssl.h>
int SSL_get0_sigalg(SSL *s, int idx, unsigned int *codepoint,
const char **name);
int SSL_get0_shared_sigalg(SSL *s, int idx, unsigned int *codepoint,
const char **name);
int SSL_get_shared_sigalgs(SSL *s, int idx,
int *psign, int *phash, int *psignhash,
unsigned char *rsig, unsigned char *rhash);
int SSL_get_sigalgs(SSL *s, int idx,
int *psign, int *phash, int *psignhash,
unsigned char *rsig, unsigned char *rhash);
π¦ DESCRIPTION π¦
SSL_get0_shared_sigalg() β the shared list, bestie β¨
This one hands you the names and codepoints of the signature algorithms that you and the peer both have in common on the SSL connection s. Mutuals only, no cap.
- If
idxis negative, it just returns the number of algorithms and leaves the output parameters untouched, unbothered, unmodified. - If
idxis nonnegative, that's the index of the shared signature algorithm you want, counting from zero, gorl. - The signature algorithm name goes into
*name(as long asnameis notNULL). That name is the IANA registered name for the algorithm, and it's expected to work verbatim if you plug it into aSignatureAlgorithmsconfiguration setting (peepSSL_CONF_cmd(3)). - The signature algorithm codepoint goes into
*codepoint(ifcodepointis notNULL).
ngl, this function is better suited for inspecting TLS 1.3 signature algorithms than the older SSL_get_shared_sigalgs(). iconic behaviour, honestly. π
SSL_get0_sigalg() β what the peer is advertising π
This one gives you the names and codepoints of the signature algorithms that the peer advertised on the SSL connection s. Not the shared ones β everything they put out there.
- If
idxis negative, it returns the number of algorithms, and the output parameters stay unmodified. - If
idxis nonnegative, it's the index of the peer signature algorithm to return, starting from zero. - For signature algorithms that are locally known, the name reported is the IANA registered name for that algorithm, and it's expected to work verbatim if used in a
SignatureAlgorithmsconfiguration setting (seeSSL_CONF_cmd(3)). - The signature algorithm codepoint goes into
*codepoint(ifcodepointis notNULL). - If the signature algorithm is known, its name goes into
*name(ifnameis notNULL).
same energy as above: this is better suited for inspecting TLS 1.3 signature algorithms than the older SSL_get_sigalgs(). slay. β¨
SSL_get_shared_sigalgs() β the O.G. shared-list info dump π
Returns info about the supported signature algorithms shared with the peer on the SSL connection s.
- If
idxis negative, the number of shared algorithms is returned and the output parameters remain unmodified. - If
idxis nonnegative, it's the index of the shared signature algorithm you're asking for, starting from zero. - The signature algorithm NID gets written to
*psign, the hash NID to*phash, and the sign-and-hash NID to*psignhash. - β οΈ as of TLS 1.3, signature algorithms are not always a cute little pairing of a separate public key algorithm and a digest algorithm, so
*phashand*psignhashmay not always be meaningful. the vibes are complicated, ok? - The raw hash and signature bytes of the signature algorithm codepoint get written to
*rhashand*rsig.
for example, thersa_pkcs1_sha256signature algorithm, with codepoint0x0401, gives0x04for*rhashand0x01for*rsig. periodt. π
SSL_get_sigalgs() β same but peer-order π
Similar to SSL_get_shared_sigalgs() except it returns information about all signature algorithms advertised by the peer, in the exact order the peer sent them. it's giving chronological. β
π RETURN VALUES π
SSL_get0_sigalg(), SSL_get0_shared_sigalg(), SSL_get_shared_sigalgs() and SSL_get_sigalgs() all return the number of signature algorithms, or 0 if the idx parameter is out of range (aka too large). so if you get a zero, check your idx, bestie π
π§ NOTES π§
These functions are typically called for debugging purposes (like reporting the peer's preferences) or when an application wants finer control over certificate selection. Most applications will just rely on internal handling and won't need to call them at all. and that's fine! live your life. π
- If an app is only interested in the highest preference shared signature algorithm, it can just set
idxto zero. easy. - Any or all of the parameters
psign,phash,psignhash,rsigorrhashcan be set toNULLif you don't need that value. And if you set them all toNULLand setidxto zero, you can determine the total number of signature algorithms β which can be zero. π - These functions must be called after the peer has sent a list of supported signature algorithms: after a client hello (for servers) or after a certificate request (for clients). For example, you can call them in the certificate callback. timing is everything, iykyk. β°
- Only TLS 1.2, TLS 1.3 and DTLS 1.2 currently support signature algorithms. If you call these functions on an earlier version of TLS or DTLS, zero is returned. it's giving β¨unsupportedβ¨.
- The shared signature algorithms returned by
SSL_get_shared_sigalgs()are ordered according to configuration and peer preferences. - The raw values correspond to the on the wire form as defined by RFC5246 et al. The NIDs are OpenSSL equivalents. For example, if the peer sent
sha256(4)andrsa(1), then*rhashwould be4,*rsign1,*phashNID_sha256,*psigNID_rsaEncryptionand*psignhashNID_sha256WithRSAEncryption. write that down π - If a signature algorithm is not recognised, the corresponding NIDs will be set to
NID_undef. This may be because the value isn't supported, isn't an appropriate combination (for exampleMD5andDSA), or because the signature algorithm doesn't use a hash (for exampleEd25519). flawed but relatable π
π SEE ALSO π
π HISTORY π
- Prior to OpenSSL 4.0,
SSL_get_shared_sigalgs()treated negativeidxvalues the same way as out-of-range (too large positive) values, and returned0. wild times, honestly. SSL_get0_shared_sigalg()andSSL_get0_sigalg()were added in OpenSSL 4.0. new girls on the block π
π COPYRIGHT π
Copyright 2015-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>.
okay that's the whole page, bestie, you ate it π
β¨ this was SSL_GET_SHARED_SIGALGS(3SSL) from OpenSSL version 4.0.3, dated 2026-09-29 β no cap, go forth and inspect those sigalgs. π¦πΈπ
π¦ where this page comes from
- ubuntu stonking: libssl-doc 4.0.3-1ubuntu1 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms