Andy Clayton <[EMAIL PROTECTED]> writes:
>> 2) we need someone to debug the problem further. A publicly reachable
>> server that exhibit the same problem would help, or if you can run
>> gnutls under gdb against this particular server and step through the
>> code and find out what happens.
>
> Fo
2) we need someone to debug the problem further. A publicly reachable
server that exhibit the same problem would help, or if you can run
gnutls under gdb against this particular server and step through the
code and find out what happens.
For another example server which exhibits the problem and
I have access to the same system and can help debug, we would definitely like
to see the issue resolved.
> You said sslv3 works, did you mean that this works?
>
> gnutls-cli --protocols SSL3.0 -d 4711 --disable-extensions -p 636
> bluepages.ibm.com
>
Yes, that does work. Taking out the '--pro
> $ gnutls-cli-debug -p 636 bluepages.ibm.com
> Resolving 'bluepages.ibm.com'...
> Connecting to '9.17.186.253:636'...
> Checking for TLS 1.1 support... no
(1)
> Checking fallback from TLS 1.1 to... failed
(2)
By the output of 1,2 I'd say that this server does not support 1.1 and
fails to fallbac
You said sslv3 works, did you mean that this works?
gnutls-cli --protocols SSL3.0 -d 4711 --disable-extensions -p 636
bluepages.ibm.com
If so, I think two things need to happen to move the status of this bug
forward:
1) ldap in debian should support administrators setting gnutls into
sslv2 mode
5 matches
Mail list logo