Hide Forgot
Created attachment 549988 [details] httpd error log showing client side debug Description of problem: When connecting LDAP account manager (LAM) to openldap, the self-signed CA certificate is rejected with TLS error -8172:Unknown code ___f 20. I can run to this LDAp server with a small PHP test and with an ldapsearch query with no problem Version-Release number of selected component (if applicable):2.4.23-20.el6-i686 How reproducible:Always Steps to Reproduce: 1.Open LAM in a web browser 2.Try to log in 3. Actual results: Connection error -11 Expected results: Normal connection Additional info:
Created attachment 549989 [details] slapd debug log
Created attachment 549990 [details] LAM debug log
Created attachment 549991 [details] slapd config file
Created attachment 549992 [details] ldap client config file
Hi Stuart, TLS: certificate [CN=MOC CA Cert,O=nasa,OU=sdo,L=greenbelt,ST=maryland,C=us] is not valid - error -8172:Unknown code ___f 20 -8172 is SEC_ERROR_UNTRUSTED_ISSUER (Peer's certificate issuer has been marked as not trusted by the user.) Is this certificate in your cert DB and is it correctly marked as a trusted CA? Jan
Created attachment 550401 [details] certutil output The certificate is a valid CA cert in my cert store. I noticed in the client debug log that hash files were being looked for in my cert database. Does this mean openssl is being used rather than Mozilla NSS?
(In reply to comment #7) > The certificate is a valid CA cert in my cert store. I noticed in the client > debug log that hash files were being looked for in my cert database. Does this > mean openssl is being used rather than Mozilla NSS? No, it does not. This is only for compatibility with OpenSSL certdir format. If your certdir is NSS DB, then it is used. I didn't notice that the problem is with LAM which is not shipped by RH. I do not want to close this report without further investigation. It still might be a problem with the OpenLDAP library. I think you attached a wrong file. It is not a certutil output. It seems like a log from the webserver where the connection to the LDAP server is successful. Am I right? What version of LAM are you using?
Created attachment 550682 [details] Correct certutil I am running LAM 3.6. Sorry about the wrong file.
I borrowed the following script to test the ldap-start-tls function: <?php $ldap="renault.nascom.nasa.gov"; $usr="cn=Manager,dc=nascom,dc=nasa,dc=gov"; $pwd="testtest"; ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7); $ds=ldap_connect($ldap); $ldapbind=false; if(ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3)) if(ldap_set_option($ds, LDAP_OPT_REFERRALS, 0)) if(ldap_start_tls($ds)) $ldapbind = @ldap_bind($ds, $usr, $pwd); ldap_close($ds); if(!$ldapbind) echo "ERROR"; else echo "OK"; ?> When I run this under the command line, it runs correctly. When run in a web broswer, it fails as before.
Do you have SELinux in enforcing mode (sestatus)? Can you try with permissive (setenforce 0)?
The setting of selinux to permissive makes no difference
I think I managed to reproduce. However I do not know the cause yet.
Please, can you verify, that apache has access (readonly) to your certdb files? # ls -l /etc/openldap/cacerts
[root@renault log]# ls -lZd /etc/openldap/cacerts drw-r--r--. ldap ldap system_u:object_r:etc_t:s0 /etc/openldap/cacerts [root@renault log]# ls -lZa /etc/openldap/cacerts drw-r--r--. ldap ldap system_u:object_r:etc_t:s0 . drwxr-xr-x. ldap ldap system_u:object_r:etc_t:s0 .. lrwxrwxrwx. root root unconfined_u:object_r:etc_t:s0 4d78b8cb.0 -> cacert.pem -rw-r--r--. root root unconfined_u:object_r:etc_t:s0 cacert.pem -rw-r--r--. ldap ldap system_u:object_r:etc_t:s0 cert8.db -rw-r--r--. ldap ldap system_u:object_r:etc_t:s0 key3.db lrwxrwxrwx. ldap ldap system_u:object_r:etc_t:s0 libnssckbi.so -> /usr/lib/libnssckbi.so -rw-r--r--. ldap ldap system_u:object_r:etc_t:s0 secmod.db
This problem was the result of missing execute permission on /etc/openldap/cacerts. Please close this ticket.
OK.