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:

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! :)


More information about the Gnutls-help mailing list