SSL_GET_SHARED_SIGALGS(3ossl)

πŸ“¦
version 15.1 Β· 3 versions
, in freebsd 15.1

πŸ’… SSL_GET_SHARED_SIGALGS(3ossl) β€” the OpenSSL manual, but make it make sense

okay so real talk: this is the SSL_GET_SHARED_SIGALGS(3ossl) page from the OpenSSL man pages, and it's honestly giving "cryptic note from a cryptography goblin" energy. so let me translate it for you, bestie, because once you get what it's doing it's actually kind of iconic πŸŽ€


✨ NAME ✨

SSL_get_shared_sigalgs, SSL_get_sigalgs β€” get supported signature algorithms

like, they go get the signature algorithms for you. that's the whole job. slay 🫢


🌸 SYNOPSIS 🌸

#include <openssl/ssl.h>

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);

copy it exactly, don't get creative, i'm literally begging πŸ™ˆ


πŸ¦‹ DESCRIPTION πŸ¦‹

SSL_get_shared_sigalgs()

so this one returns info about the shared signature algorithms supported by peer s. the parameter idx is the index of the shared signature algorithm you want, and it starts from zero (yes, zero-indexed, we're programmers, that's the vibe πŸ’€).

here's where the values land:

  • the signature algorithm NID goes into *psign
  • the hash NID goes into *phash
  • the sign-and-hash NID goes into *psignhash
  • the raw signature and hash values go into *rsig and *rhash

SSL_get_sigalgs()

this one is basically the sibling of SSL_get_shared_sigalgs() β€” same energy, one key difference: it returns info about all signature algorithms supported by s, in the order they were sent by the peer. no "shared" filter, just everything the peer shipped over. πŸ“¬


πŸ’– RETURN VALUES πŸ’–

both SSL_get_shared_sigalgs() and SSL_get_sigalgs() return the number of signature algorithms β€” or 0 if the idx parameter is out of range. that's it, that's the whole return situation. a big fat zero if you asked for something that doesn't exist, no cap.


πŸ‘‘ NOTES πŸ‘‘ (the juicy part, lowkey the most important section)

these functions are typically called for debugging purposes (like, to report the peer's preferences) or when an application wants finer control over certificate selection. but ngl, most applications just rely on internal handling and never need to call them. so don't feel pressured to use them, bestie πŸ’…

if an app is only interested in the highest preference shared signature algorithm, it can just set idx to zero. one and done. easy.

here's a cute trick: 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, plot twist, can be zero. 😭

timing matters, okay? these functions must be called after the peer has sent a list of supported signature algorithms: after a client hello (for servers) or a certificate request (for clients). one super convenient spot is the certificate callback. call them too early and you get nothing but vibes.

fyi on protocol support: 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, you get 0 back. it's giving "we don't do that here" 🚫

and here's the ordering tea: the shared signature algorithms returned by SSL_get_shared_sigalgs() are ordered according to configuration and peer preferences. so it's not random, it's negotiated.

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 would be 1
  • *phash would be NID_sha256
  • *psig would be NID_rsaEncryption
  • *psignhash would be NID_sha256WithRSAEncryption

see? it all lines up. chef's kiss πŸ”₯

last thing, and it's a real one: if a signature algorithm is not recognised, the corresponding NIDs will be set to NID_undef. this may be because:

  • the value is not supported
  • it's not an appropriate combination (for example MD5 and DSA πŸ™ƒ)
  • the signature algorithm doesn't use a hash (for example Ed25519)

so if you see NID_undef staring back at you, that's why. don't panic, it's documented ✨


🌈 SEE ALSO 🌈

go read those next, i promise they're relevant 🧚


Copyright 2015-2018 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 bye bestie, go forth and debug your TLS handshakes πŸ¦‹πŸ’– β€” this was version 3.5.6, dated 2026-04-07, and it's the SSL_GET_SHARED_SIGALGS(3ossl) page, signing off ⭐

πŸ“¦ where this page comes from