I am trying to parse the signature algorithm off a certificate using Openssl's APIs. Currently I am using the X509_get_signature_info function to get the hash/digest nid and the pkey nid. However, these nids seem to be exclusive to Openssl, whereas I am looking for the IANA value of said signature algorithm. (IANA values of signature algorithms) For example, I am looking for an Openssl api that converts the nid of the hash algorithm md5, which is 4 according to this file, to the iana value of this hash algorithm, which is 1. I would be surprised if this API did not exist, given that Openssl has to transform their nid to the iana value in order to send this hash algorithm over the wire.
Yes, NIDs are OpenSSL only.
The separate encodings and registries for the hash and signature parts of TLS 'SignatureAndHashAlgorithm' only apply to TLS1.2. The IANA page section you link, and the immediately following one, phrase this a bit obscurely as 'prior to 1.3'. However, sigalgs did not exist prior to 1.2, so the only protocol that is prior to 1.3 and not prior to 1.2 is 1.2. TLS 1.3 changes the definition of 'SignatureScheme' to be a single 2-byte value, with most (not all) of the pairs defined in 1.2 preserved, but new values added that do not fit the 'hash byte, signature byte' format. EdDSA is defined for TLS1.2 by RFC8422 with 'hash'=8 to mean no separate hash, and that same first byte 8 is also used in TLS1.3 for RSASSA-PSS which does hash the data as a separable step but also uses the hash in MGF1 so it arguably isn't fully 'separate'.
OpenSSL doesn't need to 'convert' any cert signature to the TLS wire type(s), and doesn't. Rather, for protocols 1.2 and 1.3 it determines whether to use a certificate by comparing the NIDs (or sometimes even more-compressed CERT-array indexes) for each configured/offered/shared sigalg to the potential certificate(s). It does allow configuring the sigalgs to be offered and accepted, and
SSL_[CTX_]set1_[client_]sigalgs does accept pairs of NIDs. However, this data is then used only for the protocol; AFAICS there's no supported way of getting it back out.
ObSec: MD5 is broken; don't use it in certificates. Or for almost anything else.