Fwd: [Help-gnutls] GnuTLS 2.2.1 problem returning GNUTLS_E_CONSTRAINT_ERROR
nmav at gnutls.org
Sun Feb 17 15:11:17 CET 2008
O/H Nikos Mavrogiannopoulos έγραψε:
> O/H Daniel Stenberg έγραψε:
>> On Sat, 16 Feb 2008, Nikos Mavrogiannopoulos wrote:
>>>> The culprit here for you is the -101. That's
>>>> gnutls_certificate_verify_peers2() returning
>>> I can see two cases where this can be returned.
>>> 1. the verify depth of the certificate is quite high (ie the chain
>>> being verified is long).
>>> The default maximum depth is 6. Although it is possible to have such
>>> long chain, it is most probably
>>> a configuration error if the server sends more than 6 certificates.
>>> - this limit can be adjusted by gnutls_certificate_set_verify_limits()
>>> 2. the key bits of the certificates are longer than the maximum
>>> allowed (8200). this limit can also be adjusted by the same function.
>> But seeing this is a live server used by mere mortals out there (it
>> is a bank after all), wouldn't it perhaps be an indication that the
>> defaults are a bit too restrictive? Also, both OpenSSL and Firefox
>> (NSS) deal with it by default.
>> However, I tried adding this:
>> 20200, 18);
>> Is there any way for me to figure out sensible values for me to set
>> to this function? I just upped them a couple of times until the
>> function worked!
>> And yes, it now makes gnutls_certificate_verify_peers2() return
>> success but then... verify_status still contained the
>> GNUTLS_CERT_INVALID bit. So something still isn't liking this server!
> I'm really loaded to check it right now, thus I've added a ticket at:
> The original idea was to avoid denial of service attacks by a server
> (sending you 9999 certificates of 99999 bits). That would make the
> client unresponsive. Using more sensible defaults is an option.
> (Patches are always accepted! :)
It seems my time wasn't that limited and the fix was quite easy.
The fix is in this commit:
More information about the Gnutls-help