X509_STORE_CTX_GET0_PARENT_CTX(3ssl)

๐Ÿ“ฆ version 4.1.0, in opensuse-leap 16.0

โœจ X509_STORE_CTX_GET_ERROR โ€” the get-or-set certificate verification status info page โœจ

okay bestie, welcome to the OpenSSL library functions manual ๐Ÿ’… this page lives in section 3 (library functions), and today we're deep-diving X509_STORE_CTX_get_error and its whole friend group. no cap, this is the "what went wrong during cert verification and how do I look at it" page.


๐ŸŒธ NAME ๐ŸŒธ

X509_STORE_CTX_get_error, X509_STORE_CTX_set_error, X509_STORE_CTX_get_error_depth, X509_STORE_CTX_set_error_depth, X509_STORE_CTX_get_current_cert, X509_STORE_CTX_set_current_cert, X509_STORE_CTX_get0_current_issuer, X509_STORE_CTX_get0_current_crl, X509_STORE_CTX_get0_parent_ctx, X509_STORE_CTX_get_num_untrusted, X509_STORE_CTX_get0_chain, X509_STORE_CTX_get_chain, X509_STORE_CTX_get1_chain, X509_STORE_CTX_set0_verified_chain, X509_verify_cert_error_string โ€” get or set certificate verification status information ๐ŸŽ€

like, the whole squad. every one of them. that's the vibe.


โœจ SYNOPSIS โœจ

#include <openssl/x509_vfy.h>

int
X509_STORE_CTX_get_error(X509_STORE_CTX *ctx);

void
X509_STORE_CTX_set_error(X509_STORE_CTX *ctx, int s);

int
X509_STORE_CTX_get_error_depth(X509_STORE_CTX *ctx);

void
X509_STORE_CTX_set_error_depth(X509_STORE_CTX *ctx, int depth);

X509 *
X509_STORE_CTX_get_current_cert(X509_STORE_CTX *ctx);

void
X509_STORE_CTX_set_current_cert(X509_STORE_CTX *ctx, X509 *cert);

X509 *
X509_STORE_CTX_get0_current_issuer(X509_STORE_CTX *ctx);

X509_CRL *
X509_STORE_CTX_get0_current_crl(X509_STORE_CTX *ctx);

X509_STORE_CTX *
X509_STORE_CTX_get0_parent_ctx(X509_STORE_CTX *ctx);

int
X509_STORE_CTX_get_num_untrusted(X509_STORE_CTX *ctx);

STACK_OF(X509) *
X509_STORE_CTX_get0_chain(X509_STORE_CTX *ctx);

STACK_OF(X509) *
X509_STORE_CTX_get_chain(X509_STORE_CTX *ctx);

STACK_OF(X509) *
X509_STORE_CTX_get1_chain(X509_STORE_CTX *ctx);

void
X509_STORE_CTX_set0_verified_chain(X509_STORE_CTX *ctx,
    STACK_OF(X509) *chain);

#include <openssl/x509.h>

const char *
X509_verify_cert_error_string(long n);

two different headers bestie, don't forget the second #include โ€” X509_verify_cert_error_string lives in <openssl/x509.h> while the rest are in <openssl/x509_vfy.h>. iykyk ๐Ÿฆ‹


๐Ÿ’– DESCRIPTION ๐Ÿ’–

so the way that most of these functions work: you call them after X509_verify_cert(3) to peek at the status info from your certificate verification. some of them you can also call inside a verification callback to figure out what kind of error you're dealing with. it's giving detective energy ๐Ÿ”

  • X509_STORE_CTX_get_error() โ€” returns the error code of ctx. literally just the error code. head over to the ERROR CODES section for a full description of all the error codes (all of them, we're not skipping any).
  • X509_STORE_CTX_set_error() โ€” sets the error code of ctx to s. for example, you might use this in a verification callback to set an error based on additional checks you did yourself. main character move ๐Ÿ’…
  • X509_STORE_CTX_get_error_depth() โ€” returns the depth of the error. this is a non-negative integer telling you where in the certificate chain the error happened. if it's zero, it went down in the end entity certificate; one means it's the certificate which signed the end entity certificate; and so on up the chain. โญ
  • X509_STORE_CTX_set_error_depth() โ€” sets the error depth. use it together with X509_STORE_CTX_set_error() to set the depth at which an error condition was detected. team work makes the dream work ๐Ÿซถ
  • X509_STORE_CTX_get_current_cert() โ€” returns the certificate in ctx which caused the error, or NULL if no certificate is relevant.
  • X509_STORE_CTX_set_current_cert() โ€” sets the certificate which caused the error in ctx to the given cert. โš ๏ธ important: this value is not intended to stay valid for very long, and it remains owned by the caller. a verification callback invoked to handle each error encountered during chain verification may examine it, and it's no longer required after such a callback returns. if your callback wants to save the certificate for use after it returns, you need to bump its reference count via X509_up_ref(3). once that saved certificate is no longer needed, free it with X509_free(3). no take-backsies on ownership, bestie ๐Ÿ™ˆ
  • X509_STORE_CTX_get0_current_issuer() โ€” returns the certificate that caused issuer validation to fail, or NULL if no CA certificate is relevant.
  • X509_STORE_CTX_get0_current_crl() โ€” returns the certificate revocation list that caused CRL checking to fail, or NULL if no CRL is relevant.
  • X509_STORE_CTX_get0_parent_ctx() โ€” okay this one's a whole situation, pay attention ๐Ÿงš when, during certification path validation, the need arises to check the validity of the certification path of a CRL issuer certificate, the library creates a new, temporary X509_STORE_CTX object. if you call X509_STORE_CTX_get0_parent_ctx() on that temporary object, you get a pointer to the original certification path validation context back. this is useful in callback functions called from X509_verify_cert(3) or from its subroutines โ€” it lets you find out whether the callback is being called from the path validation of the target certificate or from the path validation of a related CRL issuer certificate, and if it's the latter, what the target certificate actually is. iconic little context telescope ๐Ÿ”ญ
  • X509_STORE_CTX_get0_chain() โ€” returns an internal pointer to a complete validated chain if a previous call to X509_verify_cert(3) was successful. but โ€” if that call to X509_verify_cert(3) was not successful, the returned chain may be incomplete or invalid. proceed accordingly ๐Ÿ˜ญ
  • X509_STORE_CTX_get_chain() โ€” a deprecated alias of X509_STORE_CTX_get0_chain(). use the 0 one, bestie, it ate.
  • X509_STORE_CTX_get1_chain() โ€” returns a deep copy of the same chain, which persists even after the ctx structure is freed. when you don't need it anymore, free it using sk_X509_pop_free(chain, X509_free). the 1 means "you own this now" ๐Ÿ’€
  • X509_STORE_CTX_set0_verified_chain() โ€” frees the validated chain generated by a previous call to X509_verify_cert(3), if any, and replaces it with the given chain. ownership of the chain is transferred to the ctx, so do not free it yourself. it's the ctx's problem now ๐Ÿ‘‘
  • X509_verify_cert_error_string() โ€” returns a human readable error string for verification error n. yes, human readable, we love an accessible error message ๐ŸŒˆ
also, real talk: use the above functions instead of directly referencing the fields in the X509_VERIFY_CTX structure. fr fr, don't poke the struct yourself.

in versions of OpenSSL before 1.0, the current certificate returned by X509_STORE_CTX_get_current_cert() was never NULL. so applications should check the return value before printing out any debugging information relating to the current certificate โ€” yes, even though old code got away with not checking. glow-up rules now โœจ

and if an unrecognised error code gets passed to X509_verify_cert_error_string(), "Unknown certificate verification error" is returned. this should never happen unless an invalid code is passed. so like, if you see it, something's up ๐Ÿ™ˆ


๐Ÿฆ‹ RETURN VALUES ๐Ÿฆ‹

  • X509_STORE_CTX_get_error() returns X509_V_OK or an error code.
  • X509_STORE_CTX_get_error_depth() returns a non-negative error depth.
  • X509_STORE_CTX_get_current_cert(), X509_STORE_CTX_get0_current_issuer(), and X509_STORE_CTX_get0_current_crl() return the object which caused the error, or NULL if no object of the requested kind is relevant to the error.
  • X509_STORE_CTX_get0_parent_ctx() returns the parent context, or NULL if ctx is not a temporary child context used for path validation of a CRL issuer certificate.
  • X509_STORE_CTX_get_num_untrusted() returns the number of untrusted certificates that were used in building the chain during a call to X509_verify_cert(3).
  • X509_STORE_CTX_get0_chain(), X509_STORE_CTX_get_chain(), and X509_STORE_CTX_get1_chain() return a pointer to a stack of certificates, or NULL if an error occurs.
  • X509_verify_cert_error_string() returns a human readable error string for verification error n.

that's the return value tea โ˜• and there's more page coming, so don't go anywhere bestie ๐ŸŽ€

๐Ÿ’… ERROR CODES ๐Ÿ’…

okay bestie, here's the whole alphabet of heartbreak โ€” every error code and its message, listed below ๐ŸŒธ. Heads up: some of these codes are defined but currently never returned, and those ones get described as "unused". So if you see "unused" next to one, that's why โ€” it's giving ghost ๐Ÿ‘ป.

  • X509_V_OK: ok โ€” literally the only good ending ๐Ÿ’–. The operation was successful.
  • X509_V_ERR_UNSPECIFIED: Unspecified certificate verification error โ€” something went wrong during certificate verification and the internal routines failed to set a more specific error. Not them being vague on purpose, they just couldn't pin it down ๐Ÿ˜ญ.
  • X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT: unable to get issuer certificate โ€” the issuer certificate of a locally looked up certificate could not be found. This normally means the list of trusted certificates is not complete. Like a group chat missing the one person who knows what's going on ๐Ÿซ .
  • X509_V_ERR_UNABLE_TO_GET_CRL: unable to get certificate CRL โ€” the CRL of a certificate could not be found.
  • X509_V_ERR_UNABLE_TO_DECRYPT_CERT_SIGNATURE: unable to decrypt certificate's signature โ€” the certificate signature could not be decrypted. Real talk: this means the actual signature value could not be determined, rather than it not matching the expected value. And this one is only meaningful for RSA keys, iykyk ๐Ÿ”‘.
  • X509_V_ERR_UNABLE_TO_DECRYPT_CRL_SIGNATURE: unable to decrypt CRL's signature โ€” the CRL signature could not be decrypted: this means the actual signature value could not be determined rather than it not matching the expected value. Unused. ๐Ÿ’€
  • X509_V_ERR_UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY: unable to decode issuer public key โ€” the public key in the certificate SubjectPublicKeyInfo could not be read.
  • X509_V_ERR_CERT_SIGNATURE_FAILURE: certificate signature failure โ€” the signature of the certificate is invalid. Not the vibe ๐ŸŒง๏ธ.
  • X509_V_ERR_CRL_SIGNATURE_FAILURE: CRL signature failure โ€” the signature of the CRL is invalid.
  • X509_V_ERR_CERT_NOT_YET_VALID: certificate is not yet valid โ€” the certificate is not yet valid: the notBefore date is after the current time. She's early, she's not ready, come back later โฐ.
  • X509_V_ERR_CERT_HAS_EXPIRED: certificate has expired โ€” the certificate has expired: that is the notAfter date is before the current time. She's late, she's gone ๐Ÿชฆ.
  • X509_V_ERR_CRL_NOT_YET_VALID: CRL is not yet valid โ€” the CRL is not yet valid.
  • X509_V_ERR_CRL_HAS_EXPIRED: CRL has expired โ€” the CRL has expired.
  • X509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD: format error in certificate's notBefore field โ€” the certificate notBefore field contains an invalid time.
  • X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD: format error in certificate's notAfter field โ€” the certificate notAfter field contains an invalid time.
  • X509_V_ERR_ERROR_IN_CRL_LAST_UPDATE_FIELD: format error in CRL's lastUpdate field โ€” the CRL thisUpdate field (sic!) contains an invalid time. Yes bestie, the manpage really does say "sic" โ€” because both the name of the error constant and the text of the error message give a wrong name for the field that actually contains the problem ๐Ÿ™ˆ. Iconic behaviour, honestly.
  • X509_V_ERR_ERROR_IN_CRL_NEXT_UPDATE_FIELD: format error in CRL's nextUpdate field โ€” the CRL nextUpdate field contains an invalid time.
  • X509_V_ERR_OUT_OF_MEM: out of memory โ€” an error occurred trying to allocate memory. This should never happen ๐Ÿ˜ค.
  • X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT: self signed certificate โ€” the passed certificate is self signed and the same certificate cannot be found in the list of trusted certificates. Main character who refuses to be in anyone's contacts ๐Ÿ’….
  • X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN: self signed certificate in certificate chain โ€” the certificate chain could be built up using the untrusted certificates but the root could not be found locally.
  • X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY: unable to get local issuer certificate โ€” the issuer certificate could not be found: this occurs if the issuer certificate of an untrusted certificate cannot be found.
  • X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE: unable to verify the first certificate โ€” no signatures could be verified because the chain contains only one certificate and it is not self signed. A chain of one is not a chain, it's a solo outing ๐Ÿง.
  • X509_V_ERR_CERT_CHAIN_TOO_LONG: certificate chain too long โ€” the certificate chain length is greater than the supplied maximum depth. Too much lore, not enough runtime ๐Ÿ“œ.
  • X509_V_ERR_CERT_REVOKED: certificate revoked โ€” the certificate has been revoked. Uninvited ๐Ÿšซ.
  • X509_V_ERR_INVALID_CA: invalid CA certificate โ€” a CA certificate is invalid. Either it is not a CA or its extensions are not consistent with the supplied purpose.
  • X509_V_ERR_PATH_LENGTH_EXCEEDED: path length constraint exceeded โ€” the basicConstraints path-length parameter has been exceeded.
  • X509_V_ERR_INVALID_PURPOSE: unsupported certificate purpose โ€” the supplied certificate cannot be used for the specified purpose. Wrong job, wrong girl ๐Ÿ˜”.
  • X509_V_ERR_CERT_UNTRUSTED: certificate not trusted โ€” the root CA is not marked as trusted for the specified purpose.
  • X509_V_ERR_CERT_REJECTED: certificate rejected โ€” the root CA is marked to reject the specified purpose. It's not a no, it's a marked no ๐Ÿฅ€.
  • X509_V_ERR_SUBJECT_ISSUER_MISMATCH: subject issuer mismatch โ€” the current candidate issuer certificate was rejected because its subject name did not match the issuer name of the current certificate. This is only set if issuer check debugging is enabled; it is used for status notification and is not in itself an error โœจ.
  • X509_V_ERR_AKID_SKID_MISMATCH: authority and subject key identifier mismatch โ€” the current candidate issuer certificate was rejected because its subject key identifier was present and did not match the authority key identifier current certificate. This is only set if issuer check debugging is enabled; it is used for status notification and is not in itself an error.
  • X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH: authority and issuer serial number mismatch โ€” the current candidate issuer certificate was rejected because its issuer name and serial number was present and did not match the authority key identifier of the current certificate. This is only set if issuer check debugging is enabled; it is used for status notification and is not in itself an error.
  • X509_V_ERR_KEYUSAGE_NO_CERTSIGN: key usage does not include certificate signing โ€” the current candidate issuer certificate was rejected because its keyUsage extension does not permit certificate signing. This is only set if issuer check debugging is enabled it is used for status notification and is not in itself an error (yes, that run-on sentence is the original's, and yes, I'm keeping it ๐Ÿซถ).
  • X509_V_ERR_UNABLE_TO_GET_CRL_ISSUER: unable to get CRL issuer certificate โ€” the CRL's issuer could not be found: there is no alternative CRL issuer set on ctx and the last certificate in the chain is not self signed.
  • X509_V_ERR_UNHANDLED_CRITICAL_EXTENSION: unhandled critical extension โ€” the certificate contains a critical extension that is unsupported by the library.
  • X509_V_ERR_KEYUSAGE_NO_CRL_SIGN: key usage does not include CRL signing โ€” the CRL issuer has a key usage extension with unset cRLSign bit.
  • X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION: unhandled critical CRL extension โ€” the CRL contains a critical extension that is unsupported by the library.
  • X509_V_ERR_INVALID_EXTENSION: invalid or inconsistent certificate extension โ€” a certificate extension had an invalid value (for example an incorrect encoding) or some value inconsistent with other extensions.
  • X509_V_ERR_INVALID_POLICY_EXTENSION: invalid or inconsistent certificate policy extension โ€” a certificate policies extension had an invalid value (for example an incorrect encoding) or some value inconsistent with other extensions. This error only occurs if policy processing is enabled ๐Ÿ”.
  • X509_V_ERR_NO_EXPLICIT_POLICY: no explicit policy โ€” the verification flags were set to require an explicit policy but none was present.
  • X509_V_ERR_DIFFERENT_CRL_SCOPE: different CRL scope โ€” the only CRLs that could be found did not match the scope of the certificate.
  • X509_V_ERR_UNSUPPORTED_EXTENSION_FEATURE: unsupported extension feature โ€” some feature of a certificate extension is not supported. Unused. ๐Ÿ’€
  • X509_V_ERR_UNNESTED_RESOURCE: RFC 3779 resource not subset of parent's resources โ€” when walking up a certificate chain, all resources specified in RFC 3779 extensions must be contained in the resources delegated in the issuer's RFC 3779 extensions. The error indicates that this is not the case or that the trust anchor has inheritance ๐Ÿช†.
  • X509_V_ERR_PERMITTED_VIOLATION: permitted subtree violation โ€” a name constraint violation occurred in the permitted subtrees.
  • X509_V_ERR_EXCLUDED_VIOLATION: excluded subtree violation โ€” a name constraint violation occurred in the excluded subtrees.
  • X509_V_ERR_SUBTREE_MINMAX: name constraints minimum and maximum not supported โ€” a certificate name constraints extension included a minimum or maximum field: this is not supported.
  • X509_V_ERR_UNSUPPORTED_CONSTRAINT_TYPE: unsupported name constraint type โ€” an unsupported name constraint type was encountered. OpenSSL currently only supports directory name, DNS name, email and URI types ๐Ÿ“ฎ.
  • X509_V_ERR_UNSUPPORTED_CONSTRAINT_SYNTAX: unsupported or invalid name constraint syntax โ€” the format of the name constraint is not recognised: for example an email address format of a form not mentioned in RFC 3280. This could be caused by a garbage extension or some new feature not currently supported ๐Ÿ—‘๏ธ.
  • X509_V_ERR_CRL_PATH_VALIDATION_ERROR: CRL path validation error โ€” an error occurred when attempting to verify the CRL path. This error can only happen if extended CRL checking is enabled.
  • X509_V_ERR_APPLICATION_VERIFICATION: application verification failure โ€” an application specific error. This will never be returned unless explicitly set by an application ๐Ÿ™‹โ€โ™€๏ธ.

๐ŸŒˆ SEE ALSO ๐ŸŒˆ

go read these next, they're all linked and all worth it bestie ๐Ÿซถ:

๐Ÿ“œ HISTORY ๐Ÿ“œ

okay so storytime, bestie, because the lore here is actually kind of iconic ๐Ÿซถ โ€” everything on this page has a whole origin story, and the way these functions got drip-fed into existence over literal decades is giving slow-burn character arc โœจ

  • So the OG squad โ€” X509_STORE_CTX_get_error(), X509_STORE_CTX_set_error(), X509_STORE_CTX_get_error_depth(), X509_STORE_CTX_get_current_cert(), X509_STORE_CTX_get_chain(), and X509_verify_cert_error_string() โ€” first appeared in SSLeay 0.8.0 and have been available since OpenBSD 2.4. like. they are the elders of this friend group ๐Ÿ‘‘
  • Then X509_STORE_CTX_get1_chain() showed up later, first appearing in OpenSSL 0.9.5, and it's been available since OpenBSD 2.7. cute little glow-up era ๐Ÿ’…
  • X509_STORE_CTX_get0_current_issuer(), X509_STORE_CTX_get0_current_crl(), and X509_STORE_CTX_get0_parent_ctx() are the OpenSSL 1.0.0 girlies โ€” first appeared there, available since OpenBSD 4.9. slay ๐ŸŒธ
  • X509_STORE_CTX_get0_chain() popped off in OpenSSL 1.1.0 and has been available since OpenBSD 6.3. a whole new generation fr fr ๐Ÿฆ‹
  • And the newest arrivals on the block: X509_STORE_CTX_set_error_depth(), X509_STORE_CTX_set_current_cert(), X509_STORE_CTX_get_num_untrusted(), and X509_STORE_CTX_set0_verified_chain() โ€” also first appeared in OpenSSL 1.1.0, and they've been available since OpenBSD 7.1. main character energy, honestly ๐Ÿ˜ญ๐Ÿ”ฅ

ngl the fact that this whole saga spans from SSLeay 0.8.0 all the way to OpenBSD 7.1 is lowkey mind-blowing โ€” that's so many eras of Unix history and every single one of these functions survived the vibe check ๐Ÿ‘‘๐Ÿ’œ

okay that's the whole page, bestie โ€” you made it to the end, proud of you fr fr ๐ŸŽ€ this little slice of documentation is from the Debian build, dated June 6, 2023, and it answers to the name X509_STORE_CTX_GET_ERROR(3). go forth and slay your cert chain validation โœจ๐Ÿ’–

๐Ÿ“ฆ where this page comes from