Description of problem: pam & nss_ldap and sudo all fail to properly perform a TLS_CHECKPEER against a server providing a Cipher with AES256-SHA. The OpenSSL client tests also seem to inaccurately verify the cert as valid even though the other programs using the OpenSSL libraries fail. openssl s_client -connect servername.com:636 -showcerts -CAFILE $PATH/ca.crt The issue is also reported/documented in this thread: (http://web.archiveorange.com/archive/v/Gs2Fr1jGgypmPzWv26Hn#hhbTEmv0a6lgBxD) Version-Release number of selected component (if applicable): Verification fails on OpenSSL 0.9.8e - 0.9.8h but is reported to work in: OpenSSL 0.9.8k Steps to Reproduce: 1. Configure a service backed by an OpenSSL cert using a AES256-SHA Cipher 2. openssl s_client -connect servername.com:636 -showcerts -CAFILE $PATH/ca.crt 3. Configure /etc/ldap.conf (or /etc/nss_ldap.conf) with ssl start_tls, tls_cacertfile $PATH/ca.crt, and tls_checkpeer yes. Optionally use ldapsearch to test: LDAPTLS_CACERT=$PATH/ca.crt ldapsearch -LLL -d 3 -ZZ -H ldap://authserver.com -s base -b "" objectclass=* Actual results: ldap_start_tls: Connect error (-11) additional info: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm Expected results: Expected cert verification successful. Additional info:
The algorithms have to be added into the SSL_library_init() call. A workaround is to run OpenSSL_add_all_algorithms() before SSL_library_init() in the caller. > The OpenSSL client tests also seem to inaccurately verify the cert as valid > even though the other programs using the OpenSSL libraries fail. This is exactly because the openssl commands always call OpenSSL_add_all_algorithms in addition to the SSL_library_init() call.
Created attachment 482750 [details] Patch adding the SHA-2 algorithms to SSL_library_init
*** Bug 596058 has been marked as a duplicate of this bug. ***
Created attachment 495771 [details] Cert
My machines use centos 5.5 with openssl-0.9.8e-12.el5_4.6 and integrated with a LDAP server whit same configuration. The problem is the same reported here, specially when I try "getent group" "id" and "sudo -l". The LDAP reports the message "SSL peer reports incorrect Message Authentication Code". I have build the patch added in this bug and applied it in server and client but still have the same problem. I can't connect neither with mozldap ldapsearch. I use a self-signed certificate. I have attached the result for openss s_client... No idea which is the problem, ideas?
You have to rebuild the nss_ldap with the patched openssl on a system.
There is a problem rebuilding the nss_ldap because in that case I have to install it in the client machine. Is there a way to solve this problem working only in the server??? I can't control all the client machines integrated with the LDAP.
Use a different certificate with SHA1 hash then.
I have tried to set in /etc/openldap/ldap.conf the configuration parameter TLS_CIPHER_SUITE MEDIUM where the ciphers are # openssl ciphers -v 'MEDIUM' KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=MD5 KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1 ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 In this case I should'n get a ssl error, but when I try a "getent group" I get this: [02/May/2011:11:26:49 +0200] conn=9 fd=64 slot=64 SSL connection from 192.168.55.101 to 192.168.55.105 [02/May/2011:11:26:49 +0200] conn=9 SSL 128-bit RC4 [02/May/2011:11:26:49 +0200] conn=9 op=-1 fd=64 closed - SSL peer reports incorrect Message Authentication Code. [02/May/2011:11:26:49 +0200] conn=10 fd=65 slot=65 SSL connection from 192.168.55.101 to 192.168.55.105 [02/May/2011:11:26:49 +0200] conn=10 SSL 128-bit RC4 I think my cert use SHA1 hash "Signature Algorithm: sha1WithRSAEncryption" and throught that i have this 3 ciphers with 256: # openssl ciphers -v DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 I'm a little lost about this, Can anyone throw some light on the issue?
If your cert uses Signature Algorithm: sha1WithRSAEncryption, your problem is completely unrelated to this bug report. I'm sorry but this is not a place for support questions. Can you please open a regular support ticket at: http://www.redhat.com/support/
*** Bug 655069 has been marked as a duplicate of this bug. ***
*** Bug 683368 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1010.html