When operating in the context of a TLS session, the trusted certificate authority list may also be set using:
int gnutls_certificate_set_x509_trust_file (gnutls_certificate_credentials_t cred, const char * cafile, gnutls_x509_crt_fmt_t type)
int gnutls_certificate_set_x509_trust_dir (gnutls_certificate_credentials_t cred, const char * ca_dir, gnutls_x509_crt_fmt_t type)
int gnutls_certificate_set_x509_crl_file (gnutls_certificate_credentials_t res, const char * crlfile, gnutls_x509_crt_fmt_t type)
int gnutls_certificate_set_x509_system_trust (gnutls_certificate_credentials_t cred)
These functions allow the specification of the trusted certificate authorities, either via a file, a directory or use the system-specified certificate authorities. Unless the authorities are application specific, it is generally recommended to use the system trust storage (see gnutls_certificate_set_x509_system_trust).
Unlike the previous section it is not required to setup a trusted list, and there are two approaches to verify the peer’s certificate and identity. The recommended in GnuTLS 3.5.0 and later is via the gnutls_session_set_verify_cert, but for older GnuTLS versions you may use an explicit callback set via gnutls_certificate_set_verify_function and then utilize gnutls_certificate_verify_peers3 for verification. The reported verification status is identical to the verification functions described in the previous section.
Note that in certain cases it is required to check the marked purpose of
the end certificate (e.g.
GNUTLS_KP_TLS_WWW_SERVER); in these cases
the more advanced gnutls_session_set_verify_cert2 and
gnutls_certificate_verify_peers should be used instead.
There is also the possibility to pass some input to the verification
functions in the form of flags. For gnutls_x509_trust_list_verify_crt2 the
flags are passed directly, but for
gnutls_certificate_verify_peers3, the flags are set using
gnutls_certificate_set_verify_flags. All the available
flags are part of the enumeration
gnutls_certificate_verify_flags shown in Figure 4.3.
If set a signer does not have to be a certificate authority. This flag should normally be disabled, unless you know what this means.
When verifying a hostname prevent textual IP addresses from matching IP addresses in the certificate. Treat the input only as a DNS name.
If a certificate is not signed by anyone trusted but exists in the trusted CA list do not treat it as trusted.
Allow CA certificates that have version 1 (both root and intermediate). This might be dangerous since those haven’t the basicConstraints extension.
Allow certificates to be signed using the broken MD2 algorithm.
Allow certificates to be signed using the broken MD5 algorithm.
Disable checking of activation and expiration validity periods of certificate chains. Don’t set this unless you understand the security implications.
If set a signer in the trusted list is never checked for expiration or activation.
Do not allow trusted CA certificates that have version 1. This option is to be used to deprecate all certificates of version 1.
Disable checking for validity using certificate revocation lists or the available OCSP data.
A certificate chain is tolerated if unsorted (the case with many TLS servers out there). This is the default since GnuTLS 3.1.4.
Do not tolerate an unsorted certificate chain.
When including a hostname check in the verification, do not consider any wildcards.
This indicates that a (raw) RSA signature is provided as in the TLS 1.0 protocol. Not all functions accept this flag.
This signals the verification process, not to fail on unknown critical extensions.
Allow certificates to be signed using the broken SHA1 hash algorithm.
Disallow RSA-PSS signatures made with mismatching salt length with digest length, as mandated in RFC 8446 4.2.3.