X509V3_ADDR_VALIDATE_PATH(3) | Library Functions Manual | X509V3_ADDR_VALIDATE_PATH(3)

# 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

# SYNOPSIS

library “libcrypto”
`#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

Both RFC 3779 extensions require additional checking in the certification path validation.

1. The initial set of allowed IP address and AS number resources is defined in the trust anchor, where inheritance is not allowed.
2. An issuer may only delegate subsets of resources present in its RFC 3779 extensions or subsets of resources inherited from its issuer.
3. If an RFC 3779 extension is present in a certificate, the same type of extension must also be present in its issuer.
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).

`X509v3_addr_validate_path`() and `X509v3_asid_validate_path`() are called from X509_verify_cert(3) as part of the verification chain building. 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. `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, 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.

`X509v3_asid_validate_resource_set`() performs similar checks as `X509v3_addr_validate_resource_set`() for asid.

# RETURN VALUES

All these functions return 1 on successful validation and 0 otherwise.

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. With the exception of an allocation error, no error codes are set on the error stack.

`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.

# SEE ALSO

ASIdentifiers_new(3), crypto(3), IPAddressRange_new(3), X509_new(3), X509_STORE_CTX_get_error(3), X509_verify_cert(3), X509v3_addr_add_inherit(3), X509v3_addr_inherits(3), X509v3_asid_add_id_or_range(3)

# 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.

June 8, 2025 | Debian