Bug#514578: LDAP STARTTLS is broken
Witold Baryluk bary...@smp.if.uj.edu.pl writes: On 02-13 16:01, Simon Josefsson wrote: Can provide any logs if needed. Please do (gnutls-cli --print-cert -d 4711 against your server). A trusted root CA certificate signed with RSA-MD5 should not cause any problems. Only intermediate non-trusted certificates signed with RSA-MD5 should be rejected. Strange because in my configuration, certificate of LDAP server is directly signed by my root CA certificate. http://smp.if.uj.edu.pl/~baryluk/ldaptlsdebug.txt Your end-entity certificate is signed using RSA-MD5, so the reject is as expected. A better description of the rejects might be RSA-MD5 signatures in untrusted certificates. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514578: LDAP STARTTLS is broken
On 02-12 21:24, Simon Josefsson wrote: Witold Baryluk bary...@smp.if.uj.edu.pl writes: I had the same problem today with 2.4.2-5, on my Lenny boxes. 2.4.2-6 also doesn't work. Reverted not to 2.4.2-4. I will regenerate all certificates but this bug is quite invasive. Mayby there should be some flags in configuration, or more verbose information about problem on upgrade. Can you elaborate on what you mean the same problem? This bug report discuss several distinct problems, and it helps to understand whether your problem is with RSA-MD5 signatures or with V1 CAs, or something else. Thanks, /Simon The same as orginal bugreport. My private CA certificate is signed with MD5. I know that it is not secure, but I suppose it can break lots of machnies if administrators of them will not be informed properly (or some environment flag for temporarly allowing this). Can provide any logs if needed. Thanks, Witek -- Witold Baryluk signature.asc Description: Digital signature
Bug#514578: LDAP STARTTLS is broken
Witold Baryluk bary...@smp.if.uj.edu.pl writes: On 02-12 21:24, Simon Josefsson wrote: Witold Baryluk bary...@smp.if.uj.edu.pl writes: I had the same problem today with 2.4.2-5, on my Lenny boxes. 2.4.2-6 also doesn't work. Reverted not to 2.4.2-4. I will regenerate all certificates but this bug is quite invasive. Mayby there should be some flags in configuration, or more verbose information about problem on upgrade. Can you elaborate on what you mean the same problem? This bug report discuss several distinct problems, and it helps to understand whether your problem is with RSA-MD5 signatures or with V1 CAs, or something else. Thanks, /Simon The same as orginal bugreport. My private CA certificate is signed with MD5. I know that it is not secure, but I suppose it can break lots of machnies if administrators of them will not be informed properly (or some environment flag for temporarly allowing this). Can provide any logs if needed. Please do (gnutls-cli --print-cert -d 4711 against your server). A trusted root CA certificate signed with RSA-MD5 should not cause any problems. Only intermediate non-trusted certificates signed with RSA-MD5 should be rejected. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514578: LDAP STARTTLS is broken
On 02-13 16:01, Simon Josefsson wrote: Can provide any logs if needed. Please do (gnutls-cli --print-cert -d 4711 against your server). A trusted root CA certificate signed with RSA-MD5 should not cause any problems. Only intermediate non-trusted certificates signed with RSA-MD5 should be rejected. Strange because in my configuration, certificate of LDAP server is directly signed by my root CA certificate. http://smp.if.uj.edu.pl/~baryluk/ldaptlsdebug.txt Regards, Witek -- Witold Baryluk signature.asc Description: Digital signature
Bug#514578: LDAP STARTTLS is broken
Brian May br...@microcomaustralia.com.au writes: 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. Do you recall which version you upgraded to in step 1? Maybe it was an older version, which didn't have the fixes. Maybe step 6 might be significant? I can't see any evidence to proof this - it seems unlikely. I might be wrong... Not impossible, maybe you could try downgrade openldap and see if you can reproduce it? 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. Ok. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514578: LDAP STARTTLS is broken
Simon Josefsson wrote: Do you recall which version you upgraded to in step 1? Maybe it was an older version, which didn't have the fixes. The latest version in Etch to the latest version in Lenny. I didn't go past Lenny. Not impossible, maybe you could try downgrade openldap and see if you can reproduce it? Unfortunately not, I believe I upgrading slapd resulted in the database format being upgraded at the same time. -- 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
Bug#514578: LDAP STARTTLS is broken
Brian May br...@microcomaustralia.com.au writes: Not impossible, maybe you could try downgrade openldap and see if you can reproduce it? Unfortunately not, I believe I upgrading slapd resulted in the database format being upgraded at the same time. Ouch. Ok, thanks for your feedback, I think we'll just have to wait and see if anyone else reports similar problems. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514578: LDAP STARTTLS is broken
Package: libgnutls26 Followup-For: Bug #514578 I had the same problem today with 2.4.2-5, on my Lenny boxes. 2.4.2-6 also doesn't work. Reverted not to 2.4.2-4. I will regenerate all certificates but this bug is quite invasive. Mayby there should be some flags in configuration, or more verbose information about problem on upgrade. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514578: LDAP STARTTLS is broken
Witold Baryluk bary...@smp.if.uj.edu.pl writes: I had the same problem today with 2.4.2-5, on my Lenny boxes. 2.4.2-6 also doesn't work. Reverted not to 2.4.2-4. I will regenerate all certificates but this bug is quite invasive. Mayby there should be some flags in configuration, or more verbose information about problem on upgrade. Can you elaborate on what you mean the same problem? This bug report discuss several distinct problems, and it helps to understand whether your problem is with RSA-MD5 signatures or with V1 CAs, or something else. Thanks, /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514578: LDAP STARTTLS is broken
Brian May br...@microcomaustralia.com.au writes: Brian May wrote: I consider this fix as very important (I will need it on most of my Lenny installations), and I rather not be using a old unsupported version from unstable if/when security fixes came out for Lenny... I downgraded to version 2.4.2-5 and it still works. Weird. Furthermore, on another box that I just upgraded to Lenny, has never has seen 2.4.2-6, it also works I'm confused. 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. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514578: LDAP STARTTLS is broken
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
Bug#514578: LDAP STARTTLS is broken
Brian May br...@microcomaustralia.com.au writes: Hello, This appears to break LDAP that uses cacert's class 3 certificate[1]. More information at http://blog.cacert.org/2009/01/356.html#comments From a previous report you need to trust an intermediary certificate - I already do just that, but it doesn't work. As such, I don't believe this is a security risk, because I have a known good copy of the intermediary CA certificate. The server certificate itself is not based on md5. renew my certificates is not an option until cacert generates a new CA certificate. Unfortunately the result of this may be that I may have to downgrade security (e.g. disable TLS) in order to finish the upgrade to Lenny :-( Any work arounds would be appreciated ;-). Are you using gnutls 2.4.2-6 from unstable? It should be fixed in that version. It is not fixed in 2.4.2-5 (in testing), I believe. [1] actually I am not positive of this, as the output of gnutls-cli -p ldaps server -d 4711 --print-cert --x509cafile /etc/ssl/certs/class3.pem doesn't mention md5 anywhere You'll need to pipe the output from gnutls-cli --print-cert to certtool -i to get the signature algorithm. This will be changed in the v2.7.x branch, so that all details are printed by gnutls-cli. however I know the intermediate CA certificate is based on md5 so I am assuming it is the same issue as here. I suspect it is the same problem. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514578: LDAP STARTTLS is broken
Simon Josefsson wrote: Are you using gnutls 2.4.2-6 from unstable? It should be fixed in that version. It is not fixed in 2.4.2-5 (in testing), I believe. That looks a lot better... Any chance of getting this into Lenny? I consider this fix as very important (I will need it on most of my Lenny installations), and I rather not be using a old unsupported version from unstable if/when security fixes came out for Lenny... Thanks. -- 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
Bug#514578: LDAP STARTTLS is broken
Brian May wrote: I consider this fix as very important (I will need it on most of my Lenny installations), and I rather not be using a old unsupported version from unstable if/when security fixes came out for Lenny... I downgraded to version 2.4.2-5 and it still works. Weird. Furthermore, on another box that I just upgraded to Lenny, has never has seen 2.4.2-6, it also works I'm confused. -- 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
Bug#514578: LDAP STARTTLS is broken
Hello, This appears to break LDAP that uses cacert's class 3 certificate[1]. More information at http://blog.cacert.org/2009/01/356.html#comments From a previous report you need to trust an intermediary certificate - I already do just that, but it doesn't work. As such, I don't believe this is a security risk, because I have a known good copy of the intermediary CA certificate. The server certificate itself is not based on md5. renew my certificates is not an option until cacert generates a new CA certificate. Unfortunately the result of this may be that I may have to downgrade security (e.g. disable TLS) in order to finish the upgrade to Lenny :-( Any work arounds would be appreciated ;-). Notes: [1] actually I am not positive of this, as the output of gnutls-cli -p ldaps server -d 4711 --print-cert --x509cafile /etc/ssl/certs/class3.pem doesn't mention md5 anywhere, however I know the intermediate CA certificate is based on md5 so I am assuming it is the same issue as here. If you want I can open a separate bug report on this. -- 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