OSSL_CMP_VALIDATE_MSG(3ossl)

πŸ“¦ version 3.5.0, in opensuse-leap 16.0

πŸ’… OSSL_CMP_VALIDATE_MSG(3ossl) β€” the CMP message protection vibe check

okay so bestie, welcome to the 3ossl girlies' corner of the OpenSSL manual ✨ this is the page for OSSL_CMP_validate_msg and OSSL_CMP_validate_cert_path, aka the two functions that do the actual "is this CMP message legit tho" verification 🫢


🌸 NAME

OSSL_CMP_validate_msg, OSSL_CMP_validate_cert_path β€” the functions for verifying CMP message protection. yes, that's literally their whole job and they ate πŸ’…


✨ SYNOPSIS

#include <openssl/cmp.h>
int OSSL_CMP_validate_msg(OSSL_CMP_CTX *ctx, OSSL_CMP_MSG *msg);
int OSSL_CMP_validate_cert_path(const OSSL_CMP_CTX *ctx,
                                X509_STORE *trusted_store, X509 *cert);

πŸ¦‹ DESCRIPTION

So this is the API for validating the protection of CMP messages πŸ’– and that includes validating CMP message sender certificates and their paths, while optionally checking the revocation status of the certificate(s). lowkey a whole security glow-up.

OSSL_CMP_validate_msg()

OSSL_CMP_validate_msg() validates the protection of the given msg, which must be either signature-based or using password-based MAC (PBM) πŸ”₯

  • In the former case (signature-based), a suitable trust anchor must be given in the CMP context ctx.
  • In the latter case (PBM), the matching secret must have been set there using OSSL_CMP_CTX_set1_secretValue(3).

🌈 which cert gets used for the signature check?

In case of signature algorithm, the certificate to use for the signature check is preferably the one provided by a call to OSSL_CMP_CTX_set1_srvCert(3) πŸ‘‘

If no such sender cert has been pinned, then candidate sender certificates are taken in this order, bestie, in this exact order:

  1. from the list of certificates received in the msg extraCerts,
  2. then any certificates provided before via OSSL_CMP_CTX_set1_untrusted(3),
  3. and then all trusted certificates provided via OSSL_CMP_CTX_set0_trusted(3).

A candidate certificate is acceptable only if all of these check out βœ…

  • it is currently valid β€” or the trust store contains a verification callback that overrides the verdict that the certificate is expired or not yet valid,
  • its subject DN matches the msg sender DN (as far as present),
  • and its subject key identifier is present and matches the senderKID (as far as the latter is present).

Each acceptable cert is tried in the given order to see if the message signature check succeeds and the cert and its path can be verified using any trust store set via OSSL_CMP_CTX_set0_trusted(3). it's giving audition line-up, and only one of them is getting the role πŸ’€

πŸŽ€ the 3GPP trust-anchor-in-extraCerts situation

If the option OSSL_CMP_OPT_PERMIT_TA_IN_EXTRACERTS_FOR_IR was set by calling OSSL_CMP_CTX_set_option(3), then for an Initialization Response (IP) message, any self-issued certificate from the msg extraCerts field may be used as a trust anchor for the path verification of an 'acceptable' cert β€” but only if it can be used also to validate the issued certificate returned in the IP message 🧚

This is according to TS 33.310 [Network Domain Security (NDS); Authentication Framework (AF)] document specified by The 3rd Generation Partnership Project (3GPP). look at us citing standards, we're so academic πŸ“š

⚠️ bestie please read this one twice: using this option is dangerous, as the certificate obtained this way has not been authenticated (at least not at CMP level). Taking it over as a trust anchor implements trust-on-first-use (TOFU). iconic risky behaviour, but make it security-critical 😭

πŸ“ the caching moment

Any cert that has been found as described above is cached and tried first when validating the signatures of subsequent messages in the same transaction. she remembered, she's efficient, we stan πŸ’œ

OSSL_CMP_validate_cert_path()

OSSL_CMP_validate_cert_path() attempts to validate the given certificate and its path using:

  • the given store of trusted certs (trusted_store β€” possibly including CRLs and a cert verification callback), and
  • non-trusted intermediate certs from the ctx.

that's it, that's the function, no notes 🌸


πŸ“ NOTES

CMP is defined in RFC 4210 (and CRMF in RFC 4211). casual little RFC drop, nbd ✨


πŸ”₯ RETURN VALUES

OSSL_CMP_validate_msg() and OSSL_CMP_validate_cert_path() return 1 on success, and 0 on error or validation failed.

so: 1 = slay, 0 = not slay πŸ’€


πŸ‘€ SEE ALSO

go read those too, iykyk 🫢


⭐ HISTORY

The OpenSSL CMP support was added in OpenSSL 3.0. vintage. a classic. the origin story πŸŽ€


Copyright 2007-2025 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>.


and that's the page, bestie πŸ¦‹ β€” signed off from the OpenSSL fam at version 3.5.0, dated 2026-09-25, living under the OSSL_CMP_VALIDATE_MSG(3ossl) banner. go validate some messages, stay safe, and don't TOFU unless you really mean it πŸ’…

πŸ“¦ where this page comes from