Fwd: [Help-gnutls] GnuTLS 2.2.1 problem returning GNUTLS_E_CONSTRAINT_ERROR
Nikos Mavrogiannopoulos
nmav at gnutls.org
Sat Feb 16 22:44:04 CET 2008
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 GNUTLS_E_CONSTRAINT_ERROR.
>>
>> 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:
>
> gnutls_certificate_set_verify_limits(conn->ssl[sockindex].cred,
> 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:
http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/17#preview
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! :)
regards,
Nikos
More information about the Gnutls-help
mailing list