certificate validation callbacks [was: Re: validating SAN URIs in gntls]

Nikos Mavrogiannopoulos nmav at gnutls.org
Tue Mar 8 15:20:08 CET 2011


On Tue, Mar 8, 2011 at 3:05 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> On 03/08/2011 03:27 AM, Nikos Mavrogiannopoulos wrote:
>> I don't really understand about what kind of callbacks is the discussion about.
>> Isn't the callback set by gnutls_certificate_set_verify_function() sufficient?
> Whoops!  I didn't realize this had been added to 2.10.0.  Yes, it looks
> like that will do exactly what i was thinking.  Thanks for anticipating
> this, Nikos!  I'm assuming this callback triggers on both the server and
> client sides?

Indeed.

> Out of curiosity, when gnutls_certificate_set_verify_function() gets
> called, do we have evidence that the peer is actually in control of the
> secret key corresponding to the public key in the certificate?  Or do we
> only get that evidence after the handshake has completed?  (maybe the
> answer is different for the case where we are the client vs. the case
> where we are the server?)

No at this point only the certificate has been received. The protocol has
not been completed. It is only after the completion of the handshake (and
the verification of certificates), that you are sure about peer's
identity/certificate
claims.

> Is the idea that users of older versions of gnutls would have used
> something like gnutls_handshake_set_post_client_hello_function() if they
> are the server?  or just that they would have to manually invoke
> gnutls_handshake(), then check the certificate, and alert/fail the
> connection at that point?

The post_client_hello_function() is used by web servers that want to
access the extensions such as server_name indication asap. The
"new" callback is to allow having the verification as part of the handshake
and thus having a setup where a successful handshake also indicates
verification of the peer.

regards,
Nikos




More information about the Gnutls-devel mailing list