Bug#514578: libgnutls26: LDAP STARTTLS is broken
Package: libgnutls26 Version: 2.4.2-5 Severity: important Hi, After upgrading to libgnutls26 2.4.2-5, LDAP authentication fails (including ldap-utils, libnss-ldap and apache's mod_authnz_ldap). The error message from ldapsearch ends with: TLS: peer cert untrusted or revoked (0x102) ldap_err2string ldap_start_tls: Connect error (-11) 2.4.2-6 in sid is also affected. Re-installing 2.4.2-4 fixes the problem. Gabor -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing'), (101, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgnutls26 depends on: ii libc6 2.7-18GNU C Library: Shared libraries ii libgcrypt111.4.1-1 LGPL Crypto library - runtime libr ii libgpg-error0 1.4-2 library for common error values an ii libtasn1-3 1.4-1 Manage ASN.1 structures (runtime) ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime libgnutls26 recommends no packages. Versions of packages libgnutls26 suggests: pn gnutls-binnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514578: libgnutls26: LDAP STARTTLS is broken
Gábor Gombás gomb...@sztaki.hu writes: Package: libgnutls26 Version: 2.4.2-5 Severity: important Hi, After upgrading to libgnutls26 2.4.2-5, LDAP authentication fails (including ldap-utils, libnss-ldap and apache's mod_authnz_ldap). The error message from ldapsearch ends with: TLS: peer cert untrusted or revoked (0x102) ldap_err2string ldap_start_tls: Connect error (-11) 2.4.2-6 in sid is also affected. Re-installing 2.4.2-4 fixes the problem. Please provide output from: gnutls-cli -p 663 your.ldap.server -d 4711 --print-cert Replacing your.ldap.server as appropriate. I suspect your chain contains a certificate signed with RSA-MD5, if so you need to trust an intermediary certificate directly to work around the problem. You'll need 2.4.2-6 for this to work. /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: libgnutls26: LDAP STARTTLS is broken
On Mon, Feb 09, 2009 at 01:40:59PM +0100, Simon Josefsson wrote: Please provide output from: gnutls-cli -p 663 your.ldap.server -d 4711 --print-cert Here it is: |3| HSK[8a6c0b8]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1 |3| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1 |3| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1 |3| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1 |3| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1 |3| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1 |3| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: RSA_ARCFOUR_MD5 |3| HSK[8a6c0b8]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1 |3| HSK[8a6c0b8]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1 |3| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1 |3| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1 |3| HSK[8a6c0b8]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1 |2| EXT[8a6c0b8]: Sending extension CERT_TYPE |2| EXT[8a6c0b8]: Sending extension SERVER_NAME |3| HSK[8a6c0b8]: CLIENT HELLO was send [132 bytes] |6| BUF[HSK]: Peeked 0 bytes of Data |6| BUF[HSK]: Emptied buffer |4| REC[8a6c0b8]: Sending Packet[0] Handshake(22) with length: 132 |2| ASSERT: gnutls_cipher.c:204 |7| WRITE: Will write 137 bytes to 4. |7| WRITE: wrote 137 bytes to 4. Left 0 bytes. Total 137 bytes. |7| - 16 03 02 00 84 01 00 00 80 03 02 49 90 4e 7f 0b |7| 0001 - bc b1 4e bf e1 12 b4 1f 73 3d 1a ab ba e9 2e 8f |7| 0002 - a9 36 54 d0 4e 13 41 5f a4 25 a7 00 00 34 00 33 |7| 0003 - 00 45 00 39 00 88 00 16 00 32 00 44 00 38 00 87 |7| 0004 - 00 13 00 66 00 90 00 91 00 8f 00 8e 00 2f 00 41 |7| 0005 - 00 35 00 84 00 0a 00 05 00 04 00 8c 00 8d 00 8b |7| 0006 - 00 8a 01 00 00 23 00 09 00 03 02 00 01 00 00 00 |7| 0007 - 18 00 16 00 00 13 64 69 72 65 63 74 6f 72 79 2e |7| 0008 - 73 7a 74 61 6b 69 2e 68 75 |4| REC[8a6c0b8]: Sent Packet[1] Handshake(22) with length: 137 |7| READ: Got 5 bytes from 4 |7| READ: read 5 bytes from 4 |7| - 16 03 01 07 aa |7| RB: Have 0 bytes into buffer. Adding 5 bytes. |7| RB: Requested 5 bytes |4| REC[8a6c0b8]: Expected Packet[0] Handshake(22) with length: 1 |4| REC[8a6c0b8]: Received Packet[0] Handshake(22) with length: 1962 |7| READ: Got 1962 bytes from 4 |7| READ: read 1962 bytes from 4 |7| - 02 00 00 46 03 01 00 17 79 81 1c fd e7 bb ef a4 |7| 0001 - ca d7 82 58 6d 37 6a 05 f2 cd 4a c3 d8 95 c8 fe |7| 0002 - d5 9b 69 32 28 97 20 7c 46 79 c2 d3 6f 14 95 a5 |7| 0003 - 84 72 2c 57 51 06 5a 4c 51 46 e7 00 bc 0a 13 b2 |7| 0004 - a4 ab 33 67 e1 7b b5 00 04 00 0b 00 07 58 00 07 |7| 0005 - 55 00 03 a1 30 82 03 9d 30 82 03 06 a0 03 02 01 |7| 0006 - 02 02 01 3e 30 0d 06 09 2a 86 48 86 f7 0d 01 01 |7| 0007 - 04 05 00 30 81 9b 31 0b 30 09 06 03 55 04 06 13 |7| 0008 - 02 48 55 31 11 30 0f 06 03 55 04 08 13 08 42 75 |7| 0009 - 64 61 70 65 73 74 31 11 30 0f 06 03 55 04 07 13 |7| 000a - 08 42 75 64 61 70 65 73 74 31 13 30 11 06 03 55 |7| 000b - 04 0a 13 0a 4d 54 41 20 53 5a 54 41 4b 49 31 0d |7| 000c - 30 0b 06 03 55 04 0b 13 04 49 54 41 4b 31 1e 30 |7| 000d - 1c 06 03 55 04 03 13 15 43 65 72 74 69 66 69 63 |7| 000e - 61 74 65 20 41 75 74 68 6f 72 69 74 79 31 22 30 |7| 000f - 20 06 09 2a 86 48 86 f7 0d 01 09 01 16 13 73 79 |7| 0010 - 73 2d 61 64 6d 69 6e 40 73 7a 74 61 6b 69 2e 68 |7| 0011 - 75 30 1e 17 0d 30 37 30 37 31 36 31 31 30 37 34 |7| 0012 - 36 5a 17 0d 31 37 30 37 31 33 31 31 30 37 34 36 |7| 0013 - 5a 30 62 31 0b 30 09 06 03 55 04 06 13 02
Bug#514578: libgnutls26: LDAP STARTTLS is broken
On Mon, 2009-02-09 at 16:48 +0100, Gabor Gombas wrote: On Mon, Feb 09, 2009 at 01:40:59PM +0100, Simon Josefsson wrote: Please provide output from: gnutls-cli -p 663 your.ldap.server -d 4711 --print-cert Here it is: Thanks. The server certificate is signed using RSA-MD5 so the failure is correct. Replacing your.ldap.server as appropriate. I suspect your chain contains a certificate signed with RSA-MD5, if so you need to trust an intermediary certificate directly to work around the problem. You'll need 2.4.2-6 for this to work. There is no intermediary certificate. The server's cert is signed by the top-level CA directly, and TLS_CACERT in ldap.conf points to the CA certificate. I can't point TLS_CACERT to the server's certificate since then I couldn't use different LDAP servers. Could you try adding the server certificate to the TLS_CACERT file? I believe the file should be able to hold more than just one certificate. Given the number of similar problems reported recently, I believe openldap should be able to provide an option to pass the GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5 flag to gnutls. It would make it easier for users to deal with the transition. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
