|X509_NAME_ENTRY_GET_OBJECT(3)||Library Functions Manual||X509_NAME_ENTRY_GET_OBJECT(3)|
X.501 relative distinguished name
*ne, const ASN1_OBJECT *obj);
*ne, int type, const unsigned
char *bytes, int len);
**ne, const char *field, int
type, const unsigned char *bytes,
**ne, int nid, int type,
const unsigned char *bytes, int
**ne, const ASN1_OBJECT *obj,
int type, const unsigned char
*bytes, int len);
An X.501 RelativeDistinguishedName is an ordered set of field type and value pairs. It is the building block for constructing X.501 Name objects. The X509_NAME_ENTRY object stores one such pair, containing one field type and one value.
X509_NAME_ENTRY objects are intended for use by the X509_NAME objects documented in X509_NAME_new(3). Since part of the information about how several X509_NAME_ENTRY objects combine to form an X.501 Name is stored in the individual X509_NAME_ENTRY objects rather than in the X509_NAME object, any given X509_NAME_ENTRY object can only be used by one X509_NAME object at a time.
allocates and initializes an empty X509_NAME_ENTRY
object, representing an ASN.1
RelativeDistinguishedName structure defined in RFC
5280 section 18.104.22.168, but containing not more than one type-value-pair.
frees ne and the type and value contained in it.
retrieves the field type of ne in an
retrieves the field value of ne in an
ASN1_STRING structure. These two functions can be used
to examine an X509_NAME_ENTRY object as returned by
retrieves the index of the X.501
RelativeDistinguishedName (RDN) that
ne is part of in the X.501 Name
object using it. The first RDN has index 0. If an RDN consists of more than
one X509_NAME_ENTRY object, they all share the same
index. In practice, RDNs containing more than one type-value-pair are rarely
used, so if an X509_NAME *name object uses
usually agrees with
ne), but when multi-pair RDNs are used, it may be
sets the field type of ne to
sets the field value of ne to string type
type and the value determined by
bytes and len.
these functions are rarely used because
X509_NAME_ENTRY structures are almost always part of
X509_NAME structures and the functions described in
are typically used to create and add new entries in a single operation.
The arguments of these functions
support similar options to the similarly named ones described in
So for example type can be set to
MBSTRING_ASC, but in the case of
the field type must be set first so the relevant field information can be
looked up internally.
X509_NAME_ENTRY_new() function returns
a valid X509_NAME_ENTRY structure if successful;
NULL is returned and an error code can be
X509_NAME_ENTRY_get_object() returns a
valid ASN1_OBJECT structure if it is set or
NULL if an error occurred.
X509_NAME_ENTRY_get_data() returns a valid
ASN1_STRING structure if it is set or
NULL if an error occurred.
X509_NAME_ENTRY_set() returns the
zero-based index of the RDN ne is used in, or 0 if
ne is not yet used by any
returns 1 if successful; otherwise 0 is returned and an error code can be
X509_NAME_ENTRY_set_data() returns 1 on
success or 0 on error. In some cases of failure, the reason can be
X509_NAME_ENTRY_create_by_OBJ() return a valid
X509_NAME_ENTRY structure on success or
NULL if an error occurred. In some cases of failure,
the reason can be determined with
RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
ITU-T Recommendation X.501, also known as ISO/IEC 9594-2: Information Technology Open Systems Interconnection The Directory: Models, section 9.3: Relative distinguished name
X509_NAME_ENTRY_free() first appeared in SSLeay
X509_NAME_ENTRY_create_by_OBJ() first appeared in
SSLeay 0.8.0. These functions have been available since
appeared in OpenSSL 0.9.5 and has been available since
X509_NAME_ENTRY_set() first appeared in
OpenSSL 1.1.0 and has been available since OpenBSD
Despite its name,
does not set anything. Something like
“X509_NAME_ENTRY_get_set” would have been a better name.
|July 2, 2021||OpenBSD-current|