LDAP TLS connection stopped working

[[e-mail]]

My LDAP authentication stopped working with the error: "The signature algorithm is not supported"

This is GNUTLS Error code: -106 GNUTLS_E_UNSUPPORTED_SIGNATURE_ALGORITHM

LDAP search reproduces it:

$ ldapsearch -H ldaps://xxx.xxx.gov/ -b "OU=xxx" -x -d1
ldap_url_parse_ext(ldaps://xxx.xxx.gov/)
ldap_create
ldap_url_parse_ext(ldaps://xxx.xxx.gov:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP xxx.xxx.gov:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 128.219.164.41:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: can't connect: The signature algorithm is not supported..
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

It looks like the SHA1 support was removed from gnutls26...

Other packages:
ldap-utils:
Version: 2.4.31-1+nmu2ubuntu8.2

libsasl2-2:
Version: 2.1.25.dfsg1-17build1

libldap-2.4-2:
Version: 2.4.31-1+nmu2ubuntu8.2

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: libgnutls26 2.12.23-12ubuntu2.4
ProcVersionSignature: Ubuntu 3.13.0-75.119-generic 3.13.11-ckt32
Uname: Linux 3.13.0-75-generic x86_64
NonfreeKernelModules: fglrx
ApportVersion: 2.14.1-0ubuntu3.19
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Jan 14 11:38:36 2016
InstallationDate: Installed on 2014-10-08 (462 days ago)
InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2)
SourcePackage: gnutls26
UpgradeStatus: No upgrade log present (probably fresh install)

[Marc Deslauriers (mdeslaur)]

The gnutls26 security update disabled md5 support. Are you sure one of your server certs isn't using md5?
Could you perhaps attach them here?

[[e-mail] (ricleal)]

I have no access to the server...
Any chance I can get that information with a client application?
Let me know
Thanks

[Marc Deslauriers (mdeslaur)]

Perhaps try:

gnutls-cli -p 636 xx.xx.xx.xx

[[e-mail] (ricleal)]

Hope this helps:

$ gnutls-cli -d 5 -p 636 xx.xx.xx.xx
Resolving 'xx.xx.xx.xx'...
Connecting to 'xx.xx.xx.xx:636'...
|<4>| REC[0x18dd150]: Allocating epoch #0
|<2>| ASSERT: gnutls_constate.c:695
|<4>| REC[0x18dd150]: Allocating epoch #1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256
|<3>| HSK[0x18dd150]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256
|<3>| HSK[0x18dd150]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA256
|<3>| HSK[0x18dd150]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA256
|<3>| HSK[0x18dd150]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256
|<3>| HSK[0x18dd150]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256
|<3>| HSK[0x18dd150]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[0x18dd150]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<2>| EXT[0x18dd150]: Sending extension SERVER NAME (17 bytes)
|<2>| EXT[0x18dd150]: Sending extension SAFE RENEGOTIATION (1 bytes)
|<2>| EXT[0x18dd150]: Sending extension SESSION TICKET (0 bytes)
|<2>| EXT[SIGA]: sent signature algo (4.2) DSA-SHA256
|<2>| EXT[SIGA]: sent signature algo (4.1) RSA-SHA256
|<2>| EXT[SIGA]: sent signature algo (2.1) RSA-SHA1
|<2>| EXT[SIGA]: sent signature algo (2.2) DSA-SHA1
|<2>| EXT[0x18dd150]: Sending extension SIGNATURE ALGORITHMS (10 bytes)
|<3>| HSK[0x18dd150]: CLIENT HELLO was sent [137 bytes]
|<4>| REC[0x18dd150]: Sending Packet[0] Handshake(22) with length: 137
|<4>| REC[0x18dd150]: Sent Packet[1] Handshake(22) with length: 142
|<4>| REC[0x18dd150]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[0x18dd150]: Received Packet[0] Handshake(22) with length: 1828
|<4>| REC[0x18dd150]: Decrypted Packet[0] Handshake(22) with length: 1828
|<3>| HSK[0x18dd150]: SERVER HELLO was received [81 bytes]
|<3>| HSK[0x18dd150]: Server's version: 3.3
|<3>| HSK[0x18dd150]: SessionID length: 32
|<3>| HSK[0x18dd150]: SessionID: 2b0122b46beded9d4f13d425eec48fa6e98846a1196077633b78ba8d40e62caa
|<3>| HSK[0x18dd150]: Selected cipher suite: RSA_CAMELLIA_256_CBC_SHA1
|<2>| EXT[0x18dd150]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes)
|<3>| HSK[0x18dd150]: Safe renegotiation succeeded...

[Marc Deslauriers (mdeslaur)]

Oh, unfortunately not. I was hoping gnutls-cli would print out the certs, but it appears it stops before it gets a chance to.

Perhaps:

openssl s_client -connect xx.xx.xx.xx:636

[[e-mail] (ricleal)]

Here you have. See below.

It doesn't look it's using MD5...

 $ openssl s_client -connect data.xxx.xxx:636
CONNECTED(00000003)
depth=1 CN = XXX XXXX, ST = Tennessee, C = US, emailAddress = <email address hidden>, O = XXX XXXX root Certification Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/<email address hidden>/O=X X X/OU=XXX LDAP
   i:/CN=XXX <email address hidden>/O=XXX XXXX root Certification Authority
 1 s:/CN=XXX <email address hidden>/O=XXX XXXX root Certification Authority
   i:/CN=XXX <email address hidden>/O=XXX XXXX root Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
(.................)
-----END CERTIFICATE-----
<email address hidden>/O=Oak Ridge National Laboratory/OU=XXX XXXX
issuer=/CN=XXX <email address hidden>/O=XXX XXXX root Certification Authority
---
No client certificate CA names sent
---
SSL handshake has read 2119 bytes and written 445 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol : TLSv1.2
    Cipher : ECDHE-RSA-AES256-SHA
    Session-ID: XXX
    Session-ID-ctx:
    Master-Key: XXX
    Key-Arg : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1452801113
    Timeout : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---

[Marc Deslauriers (mdeslaur)]

ok, since you haven't pasted the actual certs, you need to run both of them though "openssl x509 -noout -text" and see what it lists as the "Signature Algorithm".

[[e-mail] (ricleal)]

Sorry. My fault.

Here the result:
openssl s_client -showcerts -connect xxx.xxx.xx:636 < /dev/null | openssl x509 -noout -text > cert.txt

$ cat cert.txt | grep -i signature
    Signature Algorithm: md5WithRSAEncryption
    Signature Algorithm: md5WithRSAEncryption

It looks signed with MD5... :(

[Marc Deslauriers (mdeslaur)]

Yep, unfortunately those are signed with md5, so it's normal that gnutls will no longer connect.

You need to request those certs be changed, and use the older version of gnutls26 in the meantime.

Since this is expected behaviour, I am closing this bug. Thanks!

[Francois Tamone (francois-tamone)]

Hello,

I have a similar problem and the certificate do no use MD5 as signature algorithm.

Since the MD5 deactivation, my client LDAP authentication is also not working anymore. I have access to the server and I have checked the signature algorithm of both the server and CA self-signed certificates: they are both using

   sha1WithRSAEncryption

and not MD5. Nevertheless the connection si blocked with ssl handshake failure. I must suspect that MD5 is used somewhere else than into the certificate, during the setup of the TLS connection, but I am a little puzzled for the moment.

My clients use Ubuntu 14.03 and the server is OpenLDAP 2.4.40 running on FreeBSD 10.1.

Cheers.

[David (dmlary)]

As an additional data point, I've run into the same issue for certificates signed using RSA-SHA256.

When using "gnutls-cli -p 636 ldap --priority 'SECURE256'", I get an error back stating that "The signature algorithm is not supported". If I change the priority string to 'SECURE256:+SIGN-ALL', I am able to establish a connection. Even stranger, the priority string 'SECURE256:+SIGN-RSA-SHA256' gives me an error stating "The signature algorithm is not supported".

It's almost as if the default signature algorithms changed behind the scenes, breaking everything during an unattended-upgrade. Additionally, setting the signature algorithm directly doesn't work.

This is occurring for the following versions of gnutls-cli:
* 2.12.14-5ubuntu3.11
* 2.12.23-12ubuntu2.4

[Seth Arnold (seth-arnold)]

Francois, check the openssl s_client -connect output to see what ciphersuite is negotiated. You may need to modify the TLSCipherSuite setting in your server.

Thanks

[Francois Tamone (francois-tamone)]

Hello Seth,
openssl s_client -connect... gets an error before a ciphersuite is indicated:

#openssl s_client -connect ldapserver:389 -tls1_2
CONNECTED(00000003)
140032666195616:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol : TLSv1.2
    Cipher : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1453829896
    Timeout : 7200 (sec)
    Verify return code: 0 (ok)
---

Meanwhile on the slapd -d -1 debugging side the error is "Result too large" for function ber_get_next():

56a7af08 daemon: waked
56a7af08 daemon: select: listen=6 active_threads=0 tvp=NULL
56a7af08 daemon: select: listen=7 active_threads=0 tvp=NULL
56a7af08 daemon: activity on 1 descriptor
56a7af08 daemon: activity on:56a7af08 11r56a7af08
56a7af08 daemon: read activity on 11
56a7af08 daemon: select: listen=6 active_threads=0 tvp=NULL
56a7af08 connection_get(11)
56a7af08 daemon: select: listen=7 active_threads=0 tvp=NULL
56a7af08 connection_get(11): got connid=1000
56a7af08 connection_read(11): checking for input on id=1000
ber_get_next
ldap_read: want=8, got=8
  0000: 16 03 01 01 22 01 00 01 ...."...
56a7af08 ber_get_next on fd 11 failed errno=34 (Result too large)
56a7af08 connection_read(11): input error=-2 id=1000, closing.
56a7af08 connection_closing: readying conn=1000 sd=11 for close
56a7af08 daemon: activity on 1 descriptor
56a7af08 connection_close: conn=1000 sd=11
56a7af08 daemon: waked
56a7af08 daemon: select: listen=6 active_threads=0 tvp=NULL
56a7af08 daemon: select: listen=7 active_threads=0 tvp=NULL
56a7af08 daemon: removing 11
56a7af08 conn=1000 fd=11 closed (connection lost)

I tried several values for TLSCipherSuite in slapd.conf, but to no success yet. I will try some more.

Thanks for your help.

François