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 authories. 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
the function gnutls_certificate_verify_peers3
is used to verify the peer’s certificate chain and identity. 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_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_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.
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]