[389-users] Help with understanding 389-ds, multiple server setup and TLS/SSL

Tom Fallon tom.r.fallon at gmail.com
Tue Oct 20 17:02:57 UTC 2015


Hi folks

I've inherited a 389-ds server (let's call that Server1) running version
389-Management-Console/1.1.7 B2011.172.2016 on which I've been tasked with
getting replication working on a second server (Server2). I am not new to
Linux but am new to System Administration having made the jump from
Helpdesk recently so please bear with me if these seem like stupid
questions....

I've struck one hurdle already whereby I can no longer log in on the
Console to Server1 and am getting error:

Error:
Cannot logon because of an incorrect User ID
Incorrect password or Directory problem.
java.io interruptedIOException: HTTP response timeout

I think this has occurred while I tried to get SSL certs copied/exported to
a Server2 as log files show the following.

[06/Oct/2015:23:46:46 +0100] attrcrypt - attrcrypt_cipher_init: symmetric
key failed to unwrap with the private key; Cert might have been renewed
since the key is wrapped.  To recover the encrypted contents, keep the
wrapped symmetric key value.
[06/Oct/2015:23:46:46 +0100] attrcrypt - All prepared ciphers are not
available. Please disable attribute encryption.
[06/Oct/2015:23:46:46 +0100] attrcrypt - attrcrypt_unwrap_key: failed to
unwrap key for cipher AES
[06/Oct/2015:23:46:46 +0100] attrcrypt - attrcrypt_cipher_init: symmetric
key failed to unwrap with the private key; Cert might have been renewed
since the key is wrapped.  To recover the encrypted contents, keep the
wrapped symmetric key value.
[06/Oct/2015:23:46:46 +0100] attrcrypt - attrcrypt_unwrap_key: failed to
unwrap key for cipher 3DES
[06/Oct/2015:23:46:46 +0100] attrcrypt - attrcrypt_cipher_init: symmetric
key failed to unwrap with the private key; Cert might have been renewed
since the key is wrapped.  To recover the encrypted contents, keep the
wrapped symmetric key value.
[06/Oct/2015:23:46:46 +0100] attrcrypt - All prepared ciphers are not
available. Please disable attribute encryption.
[06/Oct/2015:23:46:47 +0100] - Skipping CoS Definition
cn=nsAccountInactivation_cos,dc=example,dc=com--no CoS Templates found,
which should be added before the CoS Definition.
[06/Oct/2015:23:46:47 +0100] - slapd started.  Listening on All Interfaces
port 389 for LDAP requests
[06/Oct/2015:23:46:47 +0100] - Listening on All Interfaces port 636 for
LDAPS requests

So in theory I recreate the SSL certs on Server1 export to Server2 and
continue on.

I'd appreciate if someone could help in my understanding of how this is
supposed to work in a multi server environment as despite reading the
documentation here:
https://access.redhat.com/documentation/en/red-hat-directory-server/ I'm
struggling to get my head around things.

My understanding is there are these main components (I'm ignoring SNMP bit
for now):

- Directory Server located at /etc/dirsrv/slapd-instance and containing all
the LDAP server pieces and command line tools
- Admin Server located at /etc/dirsrv/admin-serv - docs refer to the
controlling portals which access LDAP server and refers to "Using the Admin
server" guide - I'm presuming this is the Administration Guide now
- Directory Server console - various docs I've read refer to this as the
Directory Server Console or the Admin Console which then bamboozles me as
to whether its incorporated in Directory Server or Admin Server.

I've been trying to follow this guide to multi-master SSL setup -
http://directory.fedoraproject.org/docs/389ds/howto/howto-walkthroughmultimasterssl.html
and
tweaking for my version of OS (Centos 6.7) and 389-ds but not getting very
far.

Can anyone point me to a more up to date guide or provide some form of
idiot-proof guide to get this working? I've been banging my head on this
for a couple weeks now and despite reading the docs and a load of googling
I'm not getting very far.

I have the install part down ok including disktuning, file descriptors,
keepalive, port ranges etc and 389-ds itself of course. And on Server2 I
can log in to the console using http and a basic LDAP test works fine using:

ldapsearch -x -b "dc=example,dc=com"

I think whoever setup the existing Directory Server used a self-signed cert
as there are pwdfile and noise.txt files in the slapd-instance directory so
looks like something like this was used to generate the CA Cert and Server
Cert

certutil -S -n "CA certificate" -s "cn=CAcert" -x -t "CT,," -m 1000 -v 120 -d
*.* -z noise.txt -f pwdfile.txt
certutil -S -n "Server-Cert" -s "cn=server.example.com
,cn=Directory Server" -c "CA certificate" -t "u,u,u" -m 1001 -v 120 -d *.*
 -z noise.txt -f pwdfile.txt

What I don't have a note of is the unique numbers entered with the -m
switch. Is there a way to tell what these are after the fact as I believe
they need to be unique across servers, correct?

Also can someone explain how I export the CA Cert from server 1 to server 2
- the docs don't cover that part as far as I can tell other than this
command which as far as I can see exports the CA Cert on the server you run
that command on to ascii format.

certutil -L -d . -n "CA certificate" -a > cacert.asc

Is it just a matter of copying the cacert.asc file to 2nd server in the
slapd-instance directory and running another certutil command of some sort
to import there?

Secondly do I need to setup SSL on the Admin Server as well or for simple
replication can we just get by with SSL on the Directory Server? If we need
to do the Admin Server as well (I'm unsure of what functionality the Admin
Server actually provides) is it a matter of same steps as for the Directory
Server, same commands etc?

Lastly is there a recommended way to redo the certificates on the existing
(live) server other than just removing the files and starting again?
Server1 is in production so I'm hesitant to play around with it too much
until i know what I'm doing.

Many thanks to anyone who takes the time to read this and provide any
pointers.

Cheers. Kiweegie.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20151020/2befff5f/attachment.html>


More information about the 389-users mailing list