Simon Josefsson wrote:
Can you provide more details what "works" and "not work" actually means
for you? Output from gnutls-cli with -d 4711 and --print-cert helps.
The original failure in this bug report is the intended and documented
behaviour, so if you really are seeing the same problem, the problem is
with your cert chains.
Unfortunately no. The configuration that didn't work, now works, and I
don't know what I did to change do that. I will list the steps though:
1. upgrade client from etch to lenny
2. note ldap is broken because certificate is not trusted
3. hours of debugging, including adding both root and intermediate
class 3 certificate to trusted chain
4. upgrade libgnutls26 from 2.4.2-5 to 2.4.2-6
5. It works!
6. Upgrade openldap server to Lenny.
7. Upgrade another client to lenny. It is using libgnutls26 2.4.2-5.
8. It works!
9. Downgrade libgnutls26 on first client to 2.4.2-5
10. It still works!
Something must have changed, but I don't know what.
Maybe step 6 might be significant? I can't see any evidence to proof
this - it seems unlikely. I might be wrong...
I will let you know if I encounter the problem again.
Just in case I also downgraded libgnutls26 to 2.4.2-4, and it still works.
--
Brian May <br...@microcomaustralia.com.au>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
