Next: , Previous: , Up: X.509 certificates   [Contents][Index]


4.1.1.8 Verifying a certificate in the context of TLS session

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_SIGN

If 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_MATCHES

When 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_SAME

If 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_CRT

Allow 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_MD2

Allow certificates to be signed using the broken MD2 algorithm.

GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5

Allow certificates to be signed using the broken MD5 algorithm.

GNUTLS_VERIFY_DISABLE_TIME_CHECKS

Disable 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_CHECKS

If set a signer in the trusted list is never checked for expiration or activation.

GNUTLS_VERIFY_DO_NOT_ALLOW_X509_V1_CA_CRT

Do 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_CHECKS

Disable checking for validity using certificate revocation lists or the available OCSP data.

GNUTLS_VERIFY_ALLOW_UNSORTED_CHAIN

A 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_CHAIN

Do not tolerate an unsorted certificate chain.

GNUTLS_VERIFY_DO_NOT_ALLOW_WILDCARDS

When including a hostname check in the verification, do not consider any wildcards.

GNUTLS_VERIFY_USE_TLS1_RSA

This 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_EXTENSIONS

This signals the verification process, not to fail on unknown critical extensions.

GNUTLS_VERIFY_ALLOW_SIGN_WITH_SHA1

Allow certificates to be signed using the broken SHA1 hash algorithm.

GNUTLS_VERIFY_RSA_PSS_FIXED_SALT_LENGTH

Disallow 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: , Previous: , Up: X.509 certificates   [Contents][Index]