The _gnutls_x509_verify_certificate fix

Simon Josefsson simon at
Tue Nov 11 16:51:45 CET 2008

Sam Varshavchik <mrsam at> writes:

> Tomas Mraz writes:
>> self-signed site certificate. Is there some other method how this could
>> be achieved? If not, then perhaps the test for the self-signed should be
>> performed only when clist_size > 1. Also the test for the clist_size
>> should be first test of the if().
>> The other limitation is that only the last certificate (after removing
>> eventual self-signed cert at the end of the chain) is checked against
>> the trusted list. That means you can not put just an intermediate CA
>> cert into the trusted list to be able to verify the chain.
>> What do you think of these limitations, should they be removed?
> Here's how I always thought certificate verifications should work:
> 1) The first certificate must be one of your trusted certs
> 2) Each one of the following certificates must be signed by the
> previous one, ending with the peer's certificate
> It makes no sense to search the trusted list for any intermediate
> certs, neither does it make sense to treat self-signed certs in any
> special way. All of the root, trusted, certs are self-signed certs,
> the above logic works correctly for them.

RFC 3280 section 6 contains one algorithm, and I think we need good
arguments to deviate from it.

I believe it is useful to explicitly trust an intermediate CA
certificate rather than the root CA though: consider if I purchase a CA
certificate from VeriSign: on some environments, I may want to configure
applications to trust my CA (whose private key I control) rather then
VeriSign's.  Opens up for problems with revocation of my CA certificate,
but still...

Generally, I don't think X.509 validation belongs in the same process as
a TLS client or server -- it is complex and mistakes will happen, it is
better to put all X.509 handling (including private key handling) in a
separate process.


More information about the Gnutls-devel mailing list