X509V3_ADDR_VALIDATE_PATH(3ssl)

📦 version 4.1.0, in opensuse-leap 16.0

✨ X509V3_ADDR_VALIDATE_PATH(3) ✨

okay so bestie, welcome to the manual page for X509v3_addr_validate_path and friends 💅 (and yes, it lives in the 3ssl manual section — we're fancy like that). This is the RFC 3779 path validation for IP address and AS number delegation, and honestly? It's giving "bouncer at the club checking everyone's ID" energy. 🔥

🦋 NAME 🦋

X509v3_addr_validate_path, X509v3_addr_validate_resource_set, X509v3_asid_validate_path, X509v3_asid_validate_resource_set — RFC 3779 path validation for IP address and AS number delegation. periodt. 👑

🌸 SYNOPSIS 🌸

#include <openssl/x509v3.h>

int
X509v3_addr_validate_path(X509_STORE_CTX *ctx);

int
X509v3_addr_validate_resource_set(STACK_OF(X509) *chain,
    IPAddrBlocks *addrblocks, int allow_inherit);

int
X509v3_asid_validate_path(X509_STORE_CTX *ctx);

int
X509v3_asid_validate_resource_set(STACK_OF(X509) *chain,
    ASIdentifiers *asid, int allow_inherit);

💖 DESCRIPTION 💖

So like, both RFC 3779 extensions need extra checking during certification path validation. Not optional, not a vibe — a requirement. 😌 Here's the checklist, and yes you have to memorize it:

  1. The initial set of allowed IP address and AS number resources is defined in the trust anchor, where inheritance is not allowed. The trust anchor is the main character here and it does not inherit, bestie. 🚫
  2. An issuer may only delegate subsets of resources present in its RFC 3779 extensions, or subsets of resources inherited from its issuer. No regifting stuff you don't have, iykyk. 🎁
  3. If an RFC 3779 extension is present in a certificate, the same type of extension must also be present in its issuer. Like, if you're bringing a plus-one, your issuer has to be bringing that same plus-one. 👯
  4. All RFC 3779 extensions appearing in the validation path must be in canonical form according to X509v3_addr_is_canonical(3) and X509v3_asid_is_canonical(3). Canonical or it doesn't count. 💅

X509v3_addr_validate_path() and X509v3_asid_validate_path() are called from X509_verify_cert(3) as part of the verification chain building. Lowkey iconic how they just slot in there. 🫶

On encountering an error or a violation of the above rules, error, error_depth, and current_cert are set on ctx, and the verify callback is called with ok set to 0. Here's the gossip on which error means what:

  • X509_V_ERR_INVALID_EXTENSION — indicates a non-canonical resource 😭
  • X509_V_ERR_UNNESTED_RESOURCE — indicates a violation of the other rules above 💀
  • In rare circumstances, the error can be X509_V_ERR_UNSPECIFIED
  • and for IP address resources X509_V_ERR_OUT_OF_MEM is also possible 🌈

X509v3_addr_validate_resource_set() validates the resources in addrblocks against a specific certificate chain. After checking that addrblocks is canonical (glow-up check first, always ✨), its IP addresses are checked to be covered in the certificate at depth 0, then the chain is walked all the way to the trust anchor until an error or a violation of the above rules is encountered. addrblocks is allowed to use inheritance according to X509v3_addr_inherits(3) if and only if allow_inherit is non-zero. if and only if. we said what we said. 🎀

X509v3_asid_validate_resource_set() performs similar checks as X509v3_addr_validate_resource_set() for asid. Same energy, different extension. 🦋

🔥 RETURN VALUES 🔥

All these functions return 1 on successful validation and 0 otherwise. Slay or flop, there is no in-between. 💜

For X509v3_addr_validate_path() and X509v3_asid_validate_path() a non-empty chain and a verify_cb must be present on ctx, otherwise they fail and set the error on ctx to X509_V_ERR_UNSPECIFIED. The verify_cb is called with the error codes described above on most errors encountered during validation.

⚠️ Some malformed extensions can lead to an error that cannot be intercepted by the callback. That's the scary part, bestie — you can't catch everything. 😭

With the exception of an allocation error, no error codes are set on the error stack. Neat, right?

X509v3_addr_validate_resource_set() accepts a NULL addrblocks and X509v3_asid_validate_resource_set() accepts a NULL asid as valid. They fail if chain is NULL or empty. If allow_inherit is 0, addrblocks or asid is checked for inheritance with X509v3_addr_inherits(3) or X509v3_asid_inherits(3).

The remaining failure cases are the same as for X509v3_addr_validate_path() and X509v3_asid_validate_path(). They cannot and do not attempt to communicate the cause of the error to the caller. like okay mysterious, keep your secrets 🙈

🧚 SEE ALSO 🧚

🌈 STANDARDS 🌈

RFC 3779: X.509 Extensions for IP Addresses and AS Identifiers:

  • section 2.3: IP Address Delegation Extension Certification Path Validation
  • section 3.3: Autonomous System Identifier Delegation Extension Certification Path Validation

RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

  • section 6: Certification Path Validation

⭐ HISTORY ⭐

These functions first appeared in OpenSSL 0.9.8e and have been available since OpenBSD 7.1. Old money behavior, honestly. 👑

🎀 aaaand that's the page! brought to you by Debian, dated September 30, 2023, filed under X509V3_ADDR_VALIDATE_PATH(3) — stay canonical, stay validated, and don't inherit anything you can't back up 💅💖✨
📦 where this page comes from