[389-users] 389-ds + CentOS 6.2 + TLS (self-signed, setupssl2.sh-script) + 389-console : complete FAIL. Would appreciate help.

[Alberto Suárez]

Hi Ray,

I am trying to achieve exactly then same as you and I ended in a dead 
street too. For some reason the configuration of ssl with the script 
does not work as expected on Centos 6.2. I am trying again, this time 
avoiding that script. Unfortunately, there is no much documentation on 
setting up 389 on Centos 6.2. (or at least I have not found it!) and it 
is the small details that mess everything up. If you want, get in touch 
with me so we could exchange experiences and suggestions.

Cheers,

Alberto

Ray wrote:
> Hi there,
>
> thanks for the suggestions for a cleaner removal of previous
> installations. I tried this at once, but unfortunately, it did not help.
>
> After running the setupssl2.sh script, the server behaves exactly the
> same… :(
>
> Is there anything else I should try?
>
> Cheers,
> Raimund
>
>
>
> Am 07.07.2012 17:52, schrieb Rich Megginson:
>> On 07/07/2012 04:15 AM, Ray wrote:
>>> Hi there,
>>>
>>> here's what I would like to do:
>>>
>>> Run the 389 directory server on CentOS 6.2 (x86_64). As you guys
>>> know, TLS is a must in RHEL 6+ and I do not want to turn it off,
>>> switching in sysconfig to RHEL 5 "legacy mode". Instead I would like
>>> to use the setupssl2.sh script from the 389-site to set up TLS. This
>>> fails completely:
>>>
>>>
>>> I start out switching off & deleteing everything:
>>>
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>> root at ldap:~# service dirsrv stop
>>> Shutting down dirsrv:
>>> bb_auth... [ OK ]
>>> root at ldap:~# service dirsrv-admin stop
>>> Shutting down dirsrv-admin:
>>> [ OK ]
>> remove-ds-admin.pl -y
>>
>>> root at ldap:~# yum remove 389-ds*
>>
>> yum remove 389*
>>
>> yum remove 389-ds* won't remove 389-console, 389-admin, etc.
>>
>>>
>>> root at ldap:~# rm -rf /etc/sysconfig/dirsrv* /etc/dirsrv
>>> /var/lib/dirsrv /root/.389-console
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>>
>>> Now everything 389-related should be wiped from the box. Please
>>> correct me if I'm wrong.
>>>
>>> Next, I switch off iptables and disable selinux:
>>>
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>> root at ldap:~# service iptables stop
>>> root at ldap:~# setenforce 0
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>>
>>> Now I start from scratch:
>>>
>>> /etc/hosts:
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>> root at ldap:~# cat /etc/hosts
>>> 127.0.0.1 ldap.baar.intra.bbcomputing.org localhost
>>> localhost.localdomain localhost4 localhost4.localdomain4
>>> ::1 ldap.baar.intra.bbcomputing.org localhost localhost.localdomain
>>> localhost6 localhost6.localdomain6
>>>
>>> 192.168.10.37 ldap.baar.intra.bbcomputing.org
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>>
>>> Installation:
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>> root at ldap:~# yum install 389-ds
>>> ...
>>> Running Transaction
>>> Installing : 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 1/9
>>> Installing : 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 2/9
>>> Installing : 389-admin-1.1.29-1.el6.x86_64 3/9
>>> Installing : 389-admin-console-1.1.8-1.el6.noarch 4/9
>>> Installing : 389-ds-console-1.2.6-1.el6.noarch 5/9
>>> Installing : 389-ds-console-doc-1.2.6-1.el6.noarch 6/9
>>> Installing : 389-admin-console-doc-1.1.8-1.el6.noarch 7/9
>>> Installing : 389-dsgw-1.1.9-1.el6.x86_64 8/9
>>> Installing : 389-ds-1.2.2-1.el6.noarch 9/9
>>>
>>> Installed:
>>> 389-ds.noarch 0:1.2.2-1.el6
>>> ...
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>>
>>> Looks ok to me. (Again: Please correct m if I'm wrong)
>>>
>>>
>>> Setup:
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>> root at ldap:~# setup-ds-admin.pl
>>>
>>> My answers here:
>>> Would you like to continue with set up? [yes]: y
>>> Would you like to continue? [yes]: y
>>> Choose a setup type [2]: 2
>>> Computer name [ldap.baar.intra.bbcomputing.org]:
>>> ldap.baar.intra.bbcomputing.org
>>> System User [nobody]: nobody
>>> System Group [nobody]: nobody
>>> Do you want to register this software with an existing
>>> configuration directory server? [no]: n
>>> administrator ID [admin]: admin
>>> Password: <pw1>
>>> Password (confirm): <pw1>
>>> Administration Domain [baar.intra.bbcomputing.org]:
>>> intra.bbcomputing.org
>>> Directory server network port [389]: 389
>>> Directory server identifier [ldap]: bb_auth
>>> Suffix [dc=baar, dc=intra, dc=bbcomputing, dc=org]:
>>> dc=bbcomputing,dc=org
>>> Directory Manager DN [cn=Directory Manager]: cn=Directory Manager
>>> Password: <pw2>
>>> Password (confirm): <pw2>
>>> Administration port [9830]: 9830
>>> Are you ready to set up your servers? [yes]: y
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>>
>>> Here's the following output:
>>>
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>> Creating directory server . . .
>>> Your new DS instance 'bb_auth' was successfully created.
>>> Creating the configuration directory server . . .
>>> Beginning Admin Server creation . . .
>>> Creating Admin Server files and directories . . .
>>> Updating adm.conf . . .
>>> Updating admpw . . .
>>> Registering admin server with the configuration directory server . . .
>>> Updating adm.conf with information from configuration directory
>>> server . . .
>>> Updating the configuration for the httpd engine . . .
>>> Starting admin server . . .
>>> output: Starting dirsrv-admin:
>>> output: [ OK ]
>>> The admin server was successfully started.
>>> Admin server was successfully created, configured, and started.
>>> Exiting . . .
>>> Log file is '/tmp/setup1dRGLl.log'
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>>
>>> Again, looks all ok to me.
>>>
>>> Especially the processes looks good:
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>> root at ldap:~# ps -ef |grep dirsrv
>>> nobody 7541 1 0 11:30 ? 00:00:00 ./ns-slapd -D
>>> /etc/dirsrv/slapd-bb_auth -i /var/run/dirsrv/slapd-bb_auth.pid -w
>>> /var/run/dirsrv/slapd-bb_auth.startpid
>>> root 7652 1 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f
>>> /etc/dirsrv/admin-serv/httpd.conf
>>> root 7655 7652 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start -f
>>> /etc/dirsrv/admin-serv/httpd.conf
>>> nobody 7656 7652 0 11:30 ? 00:00:00 /usr/sbin/httpd.worker -k start
>>> -f /etc/dirsrv/admin-serv/httpd.conf
>>> root 7839 7816 0 11:36 pts/2 00:00:00 grep dirsrv
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>>
>>> And netstat also looks just sweet:
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>> root at ldap:~# netstat -lntp
>>> Active Internet connections (only servers)
>>> Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
>>> ...
>>> tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 7652/httpd.worker
>>> ...
>>> tcp 0 0 :::389 :::* LISTEN 7541/./ns-slapd
>>> ...
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>>
>>> In fact, I can run 389-console at this point and successfully log
>>> into the management console:
>>>
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>> root at ldap:~# 389-console
>>>
>>> Using:
>>> User ID: cn=Directory Manager
>>> Password: <pw2>
>>> Administration URL: http://localhost:9830
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>>
>>> So far so good without TLS.
>>>
>>>
>>>
>>>
>>> Now the pain pain starts:
>>>
>>> To set up TLS I foung this script in the 389 Howto:SSL docs:
>>> http://github.com/richm/scripts/tree/master%2Fsetupssl2.sh?raw=true
>>>
>>> So I naively ran this thing:
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>> root at ldap:~# ./setupssl2.sh /etc/dirsrv/slapd-bb_auth/
>>> Using /etc/dirsrv/slapd-bb_auth/ as sec directory
>>> No CA certificate found - will create new one
>>> No Server Cert found - will create new one
>>> No Admin Server Cert found - will create new one
>>> Creating password file for security token
>>> Creating noise file
>>> Creating new key and cert db
>>> Creating encryption key for CA
>>>
>>>
>>> Generating key. This may take a few moments...
>>>
>>> Creating self-signed CA certificate
>>>
>>>
>>> Generating key. This may take a few moments...
>>>
>>> Is this a CA certificate [y/N]?
>>> Enter the path length constraint, enter to skip [<0 for unlimited
>>> path]: > Is this a critical extension [y/N]?
>>> Exporting the CA certificate to cacert.asc
>>> Generating server certificate for 389 Directory Server on host
>>> ldap.baar.intra.bbcomputing.org
>>> Using fully qualified hostname ldap.baar.intra.bbcomputing.org for
>>> the server name in the server cert subject DN
>>> Note: If you do not want to use this hostname, edit this script to
>>> change myhost to the
>>> real hostname you want to use
>>>
>>>
>>> Generating key. This may take a few moments...
>>>
>>> Creating the admin server certificate
>>>
>>>
>>> Generating key. This may take a few moments...
>>>
>>> Exporting the admin server certificate pk12 file
>>> pk12util: PKCS12 EXPORT SUCCESSFUL
>>> Creating pin file for directory server
>>> Importing the admin server key and cert (created above)
>>> pk12util: PKCS12 IMPORT SUCCESSFUL
>>> Importing the CA certificate from cacert.asc
>>> Creating the admin server password file
>>> Enabling the use of a password file in admin server
>>> Turning on NSSEngine
>>> Use ldaps for config ds connections
>>> Enabling SSL in the directory server
>>> when prompted, provide the directory manager password
>>> Password:modifying entry "cn=encryption,cn=config"
>>>
>>> modifying entry "cn=config"
>>>
>>> adding new entry "cn=RSA,cn=encryption,cn=config"
>>>
>>> Enabling SSL in the admin server
>>> modifying entry "cn=slapd-bb_auth,cn=389 Directory Server,cn=Server
>>> Group,cn=ldap.baar.intra.bbcomputing.org,ou=intra.bbcomputing.org,o=NetscapeRoot"
>>>
>>>
>>> modifying entry "cn=configuration,cn=admin-serv-ldap,cn=389
>>> Administration Server,cn=Server
>>> Group,cn=ldap.baar.intra.bbcomputing.org,ou=intra.bbcomputing.org,o=NetscapeRoot"
>>>
>>>
>>> Done. You must restart the directory server and the admin server for
>>> the changes to take effect.
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>>
>>> Again everything appears good to me, I can even restart the services
>>> without any hickups:
>>>
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>> root at ldap:~# service dirsrv restart
>>> Shutting down dirsrv:
>>> bb_auth... [ OK ]
>>> Starting dirsrv:
>>> bb_auth... [ OK ]
>>> root at ldap:~# service dirsrv-admin restart
>>> Shutting down dirsrv-admin:
>>> [ OK ]
>>> Starting dirsrv-admin:
>>> [ OK ]
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>>
>>> Now I try again to run 389-console with the same credentials and
>>> everything as above, and it fails:
>>>
>>> In the login window it simply hangs saying 'Authenticating User ID
>>> "cn=Directory Manager"...' and after some seconds an error messages
>>> appears that reads: "Cannot login because of an incorrect User ID,
>>> incorrect password or Directory problem.
>>> java.io.InterruptedIOException: HTTP response timeout.".
>>>
>>> netstat now looks like this:
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>> root at ldap:~# netstat -lntp
>>> Active Internet connections (only servers)
>>> Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
>>> ...
>>> tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 8331/httpd.worker
>>> ...
>>> tcp 0 0 :::636 :::* LISTEN 8228/ns-slapd
>>> tcp 0 0 :::389 :::* LISTEN 8228/ns-slapd
>>> ...
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>>
>>> Honestly, I don't even want an SSL listener on port 636, I really
>>> only want a listener on port 389 that requires clients to use
>>> start_tls. But I don't care for the moment.
>>>
>>> Here's more pain:
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>> root at ldap:~# cat /etc/openldap/ldap.conf
>>> URI ldap://ldap.baar.intra.bbcomputing.org/
>>> BASE dc=bbcomputing,dc=org
>>> TLS_CACERTDIR /etc/openldap/cacerts
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>>
>>> To my understanding, this should tell CentOS to query the LDAP box
>>> mentioned in the URI part, using TLS, for users, but:
>>>
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>> root at ldap:~# id raimund
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>>
>>> produces nothing but these entries in /var/log/messages
>>>
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>> Jul 7 12:04:49 ldap nslcd[1422]: [81823a] ldap_start_tls_s() failed:
>>> Connect error (uri="ldap://ldap.baar.intra.bbcomputing.org/")
>>> Jul 7 12:04:49 ldap nslcd[1422]: [81823a] failed to bind to LDAP
>>> server ldap://ldap.baar.intra.bbcomputing.org/: Connect error
>>> Jul 7 12:04:49 ldap nslcd[1422]: [81823a] no available LDAP server found
>>>
>>> --------------------------------------------------------------------------
>>>
>>>
>>>
>>> This looks bad. Actually the LDAP server sould respond that this user
>>> does not exist (empty directory at this moment), but instaead, these
>>> lines indicate that the entire communication with the server ist broken.
>>>
>>>
>>>
>>> Now, this is pretty useless, isn't it? I now have two running LDAP
>>> services (dirsrv and diesrv-admin). The first can't be contacted at
>>> all and the door to the admin server is also slammed shut, because
>>> 389-console can't talk to it any more.
>>>
>>>
>>> I went on a bit more and switched off SSL/TLS for the admin server
>>> again, then 389-console logins worked at least again, but once in the
>>> console, it's not possible to open any of the directories.
>>>
>>>
>>> Please help! I already wasted 1.5 days with this, reinstalling about
>>> 15 times! Sure there must be a way to get this running with TLS *and*
>>> the 389-console?
>>>
>>> Cheers,
>>> Raimund
>>>
>>> -- 389 users mailing list
>>> 389-users at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users