| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
5.1.2 Verifying X.509 certificate paths
Verifying certificate paths is important in X.509 authentication. For this purpose the following functions are provided.
The verification function will verify a given certificate chain against a list of certificate
authorities and certificate revocation lists, and output
a bit-wise OR of elements of the gnutls_certificate_status_t
enumeration. It is also possible to have a set of certificates that
are trusted for a particular server but not to authorize other certificates.
This purpose is served by the functions gnutls_x509_trust_list_add_named_crt and gnutls_x509_trust_list_verify_named_crt.
A detailed description of these elements can be found
in tab:cert-verify. An example of certificate verification is shown in ex:verify2.
When operating in the context of a TLS session, the trusted certificate authority list has been set via the gnutls_certificate_set_x509_trust_file and gnutls_certificate_set_x509_crl_file, thus it is not required to setup a trusted list as above. Convenience functions such as gnutls_certificate_verify_peers2 are equivalent and will verify the peer’s certificate chain in a TLS session.
| Flag | Description |
|---|---|
| GNUTLS_CERT_INVALID | The certificate is not signed by one of the known authorities, or the signature is invalid. |
| GNUTLS_CERT_REVOKED | The certificate has been revoked by its CA. |
| GNUTLS_CERT_SIGNER_NOT_FOUND | The certificate’s issuer is not known. This is the case when the issuer is not in the trusted certificates list. |
| GNUTLS_CERT_SIGNER_NOT_CA | The certificate’s signer was not a CA. This may happen if this was a version 1 certificate, which is common with some CAs, or a version 3 certificate without the basic constrains extension. |
| GNUTLS_CERT_INSECURE_ALGORITHM | The certificate was signed using an insecure algorithm such as MD2 or MD5. These algorithms have been broken and should not be trusted. |
Table 5.3: Certificate verification output flags.
There is also to possibility to pass some input to the verification
functions in the form of flags. For gnutls_x509_trust_list_verify_crt the
flags are passed straightforward, but
gnutls_certificate_verify_peers2 depends on the flags set by
calling gnutls_certificate_set_verify_flags. All the available
flags are part of the enumeration
gnutls_certificate_verify_flags and are explained in tab:cert-flags.
| Flag | Description |
|---|---|
| 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_\-ALLOW_X509_V1_CA_CRT | Allow only trusted CA certificates that have version 1. This is safer than GNUTLS_VERIFY_\-ALLOW_ANY_X509_V1_CA_CRT, and should be used instead. That way only signers in your trusted list will be allowed to have certificates of version 1. This is the default. |
| GNUTLS_VERIFY_\-DO_NOT_ALLOW_X509_V1_CA_CRT | Do not allow trusted version 1 CA certificates. This option is to be used in order consider all V1 certificates as deprecated. |
| GNUTLS_VERIFY_\-ALLOW_ANY_X509_V1_CA_CRT | Allow CA certificates that have version 1 (both root and intermediate). This is dangerous since those haven’t the basicConstraints extension. Must be used in combination with GNUTLS_VERIFY_\-ALLOW_X509_V1_CA_CRT. |
| 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_SIGN_RSA_MD2 | Allow certificates to be signed using the old 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_CRL_CHECKS | Disables checking for validity using certificate revocation lists. |
Table 5.4: Certificate verification flags.
Although the verification of a certificate path indicates that the certificate is signed by trusted authority, does not reveal anything about the peer’s identity. It is required to verify if the certificate’s owner is the one you expect. For more information consult [RFC2818]
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |