recommendations for storage of accepted certificates

Nikos Mavrogiannopoulos nmav at gnutls.org
Thu Oct 7 09:17:10 CEST 2010


On 10/05/2010 12:54 PM, Ted Zlatanov wrote:

> You mean gnutls_certificate_set_verify_function()?  I see the example in
> ex-rfc2818.c.  It seems that gnutls_certificate_verify_peers2() is the
> one to call.  The example calls gnutls_x509_crt_check_hostname()
> explicitly so I guess I will too. 

Indeed. This is a complete example.

> Also, rather than setting the
> verify_flags, it seems cleaner to use these priority string options in
> Emacs Lisp: 
> "%VERIFY_ALLOW_SIGN_RSA_MD5" will allow RSA-MD5 signatures in certificate chains.
> "%VERIFY_ALLOW_X509_V1_CA_CRT" will allow V1 CAs in chains.
> ...but all the verify_flags are not available this way.  Can this be
> changed or is that intentional?  If it's intentional I'll provide all
> those flags as API options since I can imagine we'll need them.

It is intentional. You have to pick the default flags for the subsystem
that you're building, and some flags that related to key strength can
be overriden with a priority string.

The flags are not supposed to be used by an end-user.

> 3) emacs_gnutls_verify: verify the host name (this will be optional):

Why optional? This as important as everything else.

> 4) emacs_gnutls_verify: load $CERTSTORE/HOSTNAME.pem for the current
> hostname.  If it's equivalent to the server's presented certificate (is
> there a certificate_equals() function or do I just use memcmp?), the
> verification passes and return approved.

You mean to compare strings? You can compare them as you would compare
two UTF-8 strings, no special function is required.

regards,
Nikos





More information about the Gnutls-devel mailing list