---
name: "libressl-X509v3_addr_validate_path"
section: "3"
platform: "linux"
package: "libressl"
version: "4.4.0-1"
release: "Arch Linux 2026-11-01"
platforms: ["linux"]
url: "https://new.carta.tech/libressl-X509v3_addr_validate_path"
---

# libressl-X509v3\_addr\_validate\_path(3)

RFC 3779 path validation for IP address and AS number delegation

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

Crypto Library (libcrypto, -lcrypto)

**#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)](/crypto/3.md), 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.