SSL_GET_SHARED_SIGALGS(3SSL)

πŸ“¦
version 4.0.3 Β· 2 versions
, in ubuntu stonking

πŸ’– 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 idx is negative, it just returns the number of algorithms and leaves the output parameters untouched, unbothered, unmodified.
  • If idx is 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 as name is not NULL). That name is the IANA registered name for the algorithm, and it's expected to work verbatim if you plug it into a SignatureAlgorithms configuration setting (peep SSL_CONF_cmd(3)).
  • The signature algorithm codepoint goes into *codepoint (if codepoint is not NULL).
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 idx is negative, it returns the number of algorithms, and the output parameters stay unmodified.
  • If idx is 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 SignatureAlgorithms configuration setting (see SSL_CONF_cmd(3)).
  • The signature algorithm codepoint goes into *codepoint (if codepoint is not NULL).
  • If the signature algorithm is known, its name goes into *name (if name is not NULL).
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 idx is negative, the number of shared algorithms is returned and the output parameters remain unmodified.
  • If idx is 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 *phash and *psignhash may not always be meaningful. the vibes are complicated, ok?
  • The raw hash and signature bytes of the signature algorithm codepoint get written to *rhash and *rsig.
for example, the rsa_pkcs1_sha256 signature algorithm, with codepoint 0x0401, gives 0x04 for *rhash and 0x01 for *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 idx to zero. easy.
  • Any or all of the parameters psign, phash, psignhash, rsig or rhash can be set to NULL if you don't need that value. And if you set them all to NULL and set idx to 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) and rsa(1), then *rhash would be 4, *rsign 1, *phash NID_sha256, *psig NID_rsaEncryption and *psignhash NID_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 example MD5 and DSA), or because the signature algorithm doesn't use a hash (for example Ed25519). flawed but relatable πŸ’…

πŸ‘€ SEE ALSO πŸ‘€


πŸ“œ HISTORY πŸ“œ

  • Prior to OpenSSL 4.0, SSL_get_shared_sigalgs() treated negative idx values the same way as out-of-range (too large positive) values, and returned 0. wild times, honestly.
  • SSL_get0_shared_sigalg() and SSL_get0_sigalg() were added in OpenSSL 4.0. new girls on the block πŸ’–

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