Next: Verification using PKCS11, Previous: Verifying X.509 certificate paths, Up: X.509 certificates [Contents][Index]
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.
GNUTLS_VERIFY_DISABLE_CA_SIGNIf set a signer does not have to be a certificate authority. This flag should normally be disabled, unless you know what this means.
GNUTLS_VERIFY_DO_NOT_ALLOW_IP_MATCHESWhen verifying a hostname prevent textual IP addresses from matching IP addresses in the certificate. Treat the input only as a DNS name.
GNUTLS_VERIFY_DO_NOT_ALLOW_SAMEIf a certificate is not signed by anyone trusted but exists in the trusted CA list do not treat it as trusted.
GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRTAllow CA certificates that have version 1 (both root and intermediate). This might be dangerous since those haven’t the basicConstraints extension.
GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2Allow certificates to be signed using the broken MD2 algorithm.
GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5Allow certificates to be signed using the broken MD5 algorithm.
GNUTLS_VERIFY_DISABLE_TIME_CHECKSDisable checking of activation and expiration validity periods of certificate chains. Don’t set this unless you understand the security implications.
GNUTLS_VERIFY_DISABLE_TRUSTED_TIME_CHECKSIf set a signer in the trusted list is never checked for expiration or activation.
GNUTLS_VERIFY_DO_NOT_ALLOW_X509_V1_CA_CRTDo not allow trusted CA certificates that have version 1. This option is to be used to deprecate all certificates of version 1.
GNUTLS_VERIFY_DISABLE_CRL_CHECKSDisable checking for validity using certificate revocation lists or the available OCSP data.
GNUTLS_VERIFY_ALLOW_UNSORTED_CHAINA certificate chain is tolerated if unsorted (the case with many TLS servers out there). This is the default since GnuTLS 3.1.4.
GNUTLS_VERIFY_DO_NOT_ALLOW_UNSORTED_CHAINDo not tolerate an unsorted certificate chain.
GNUTLS_VERIFY_DO_NOT_ALLOW_WILDCARDSWhen including a hostname check in the verification, do not consider any wildcards.
GNUTLS_VERIFY_USE_TLS1_RSAThis indicates that a (raw) RSA signature is provided as in the TLS 1.0 protocol. Not all functions accept this flag.
GNUTLS_VERIFY_IGNORE_UNKNOWN_CRIT_EXTENSIONSThis signals the verification process, not to fail on unknown critical extensions.
GNUTLS_VERIFY_ALLOW_SIGN_WITH_SHA1Allow certificates to be signed using the broken SHA1 hash algorithm.
GNUTLS_VERIFY_RSA_PSS_FIXED_SALT_LENGTHDisallow RSA-PSS signatures made with mismatching salt length with digest length, as mandated in RFC 8446 4.2.3.
Figure 4.3: The gnutls_certificate_verify_flags enumeration.
Next: Verification using PKCS11, Previous: Verifying X.509 certificate paths, Up: X.509 certificates [Contents][Index]