This disables non-compliant workarounds for broken certificates.
Thus errors are thrown on certificates not compliant with RFC 5280.
+When this option is set,
+among others, the following certificate well-formedness conditions are checked:
+
+=over 8
+
+=item The basicConstraints of CA certificates must be marked critical.
+=item CA certificates must explicitly include the keyUsage extension.
+=item If a pathlenConstraint is given the key usage keyCertSign must be allowed.
+=item The pathlenConstraint must not be given for non-CA certificates.
+=item The issuer name of any certificate must not be empty.
+=item The subject name of CA certs, certs with keyUsage crlSign,
+ and certs without subjectAlternativeName must not be empty.
+=item If a subjectAlternativeName extension is given it must not be empty.
+=item The signatureAlgorithm field and the cert signature must be consistent.
+=item Any given authorityKeyIdentifier and any given subjectKeyIdentifier
+ must not be marked critical.
+=item The authorityKeyIdentifier must be given for X.509v3 certs
+ unless they are self-signed.
+=item The subjectKeyIdentifier must be given for all X.509v3 CA certs.
+
+=back
+
=item B<-ignore_critical>
Normally if an unhandled critical extension is present that is not
B<verify_cb> overwriting any existing callback.
The verification callback can be used to customise the operation of certificate
-verification, either by overriding error conditions or logging errors for
+verification, for instance by overriding error conditions or logging errors for
debugging purposes.
However, a verification callback is B<not> essential and the default operation
=head1 DESCRIPTION
The X509_verify_cert() function attempts to discover and validate a
-certificate chain based on parameters in B<ctx>. A complete description of
-the process is contained in the L<openssl-verify(1)> manual page.
+certificate chain based on parameters in B<ctx>.
+The verification context, of type B<X509_STORE_CTX>, can be constructed
+using L<X509_STORE_CTX_new(3)> and L<X509_STORE_CTX_init(3)>.
+It usually includes a set of certificates serving as trust anchors,
+a set of non-trusted certificates that may be needed for chain construction,
+flags such as X509_V_FLAG_X509_STRICT, and various other optional components
+such as a callback function that allows customizing the verification outcome.
+A complete description of the certificate verification process is contained in
+the L<openssl-verify(1)> manual page.
Applications rarely call this function directly but it is used by
OpenSSL internally for certificate validation, in both the S/MIME and
return a negative code.
If the function fails additional error information can be obtained by
-examining B<ctx> using, for example X509_STORE_CTX_get_error().
+examining B<ctx> using, for example L<X509_STORE_CTX_get_error(3)>.
=head1 BUGS
=head1 SEE ALSO
+L<X509_STORE_CTX_new(3)>, L<X509_STORE_CTX_init(3)>,
L<X509_STORE_CTX_get_error(3)>
=head1 COPYRIGHT