LDAPS certificates multimaster with haproxy
by Francesco Marchesi
Hi.
We are in the process of renewing the certificates of our two 389DS
servers which sync through multimaster replication.
We are currently using a self-signed certificate shared between the two
servers.
Our topology is like this:
HAProxy : ldap.example.com for load balancing
LDAP1 : ldap1.example.com
LDAP2 : ldap2.example.com
Connections are made from clients to ldaps://ldap.example.com which
sends requests to either ldap1 or ldap2
Following the 'SSL howto' [1] we would like to have separate 'real'
certificates for the two servers.
If I'm not wrong, the certificate signing requests should be created in
each of the two 'real' servers for their real name and adding
ldap.example.com as subjectaltname.
Is that correct?
If yes, then I have another question: having the two certificates it is
not important which one clients use, is it?
Thanks,
Francesco
[1] http://directory.fedoraproject.org/docs/389ds/howto/howto-ssl.html
6 years, 2 months
password administrator
by Alberto Viana
Hi Guys,
Can I set multiple groups in passwordAdminDN?
I know that I can set per policy (subtree or user), but there is any other
way to specify more than one group globally?
Thanks
6 years, 2 months
TLS Error -8179
by Eric Wheeler
Greetings,
I'm a new 389 Directory Server user on an Amazon Linux 1 EC2 platform. I got the server launched without much issue, but then hit a wall when I imported certificates and turned on SSL. Essentially I'm getting the error message.
TLS error -8179: Peer's Certificate issuer is not recognized.
I'm fairly convinced it's an issue with certificate importation and/or configuration because the certificate I'm using is a valid and current one. The following commands both resolve successfully.
ldapsearch -H ldap://<FQDN>:389 -D 'cn=Directory Manager' -W -Z -b 'cn=encryption,cn=config' -x -d1
openssl s_client -connect <FQDN>:636
The ldapsearch command shows a valid certificate and openssl resolves to "Verify return code: 0 (ok)."
These are authenticating against the pem file at /etc/pki/tls/certs/ca-bundle.crt
In order to get 389 DS over LDAPS working, I followed a combination of instructions I found on pages http://directory.fedoraproject.org/docs/389ds/howto/howto-ssl.html and http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html.
Here are my steps.
1. Stop dirsrv
service dirsrv stop
2. Reset the database:
certutil -N -d /etc/dirsrv/slapd-<myinstance>
3. Import my CA file
certutil -A -d /etc/dirsrv/slapd-<myinstance> -n "ca_cert" -t "CT,," -i /etc/pki/tls/certs/ca-bundle.crt -a
4. Transfer my pem cert and key files to pkcs12 format for importation
openssl pkcs12 -export -inkey /etc/pki/tls/private/mykey.key -in /etc/pki/tls/certs/mycert.crt -out /home/diradmin/mykeycert.p12 -name "Server-Cert"
5. Use pk12util to import
pk12util -d /etc/dirsrv/slapd-<myinstance> -n "Server-Cert" -i /home/diradmin/mykeycert.p12
6. Edit dse.ldif
Add the following line to the object dn: cn=config.
nsslapd-security: on
The object dn: cn=encryption,cn=config should contain the following lines. Remove any of the parameters sslVersionMin, sslVersionMax, and nsSSL3Ciphers.
dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: off
nsSSL3: off
nsSSL2: off
If it doesn’t exist, add the object dn: cn=RSA,cn=encryption,cn=config and give it the following lines. The value of nsSSLPersonalitySSL must equal the nickname of the certificate file you imported above.
dn: cn=RSA,cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionModule
nsSSLPersonalitySSL: Server-Cert
nsSSLActivation: on
nsSSLToken: Internal (Software)
cn: RSA
7. Create a new file in the main Directory Server directory.
cd /etc/dirsrv/slapd-<instance name>
touch pin.txt
vi pin.txt
Add the following line to it. The phrase "Internal (Software)" in the line below must match the value of the attribute nsSSLToken above.
Internal (Software) Token:<password of Directory Server database>
8. Change the owner and group of pin.txt to the main Directory Server user (in my case diradmin) and set permissions to 400
chown diradmin:diradmin pin.txt
chmod 400 pin.txt
9. Restart the Directory Server
service dirsrv start
Based on my admittedly limited understanding of 389 DS, this should result in successful LDAPS connections, but it doesn't. Restarting dirsrv results in "TLS error -8179: Peer's Certificate issuer is not recognized."
So, either I'm importing the wrong certificates or something about my importation process is flawed.
Oh and by the way, I tried a different approach and started with a certificate signing request using certutil with the intention of requesting a new certificate. However certutil will not show me the public key for the csr, only the request. So, it seems I'm stuck. Anyone have any ideas?
6 years, 2 months
389ds on lxc debian
by Angel Bosch Mora
hi,
I'm trying to install 1.1.43-1+b1 package on lxc with debian 9 and I get th=
is error:
invoke-rc.d: initscript dirsrv-admin, action "start" failed.
=E2=97=8F dirsrv-admin.service - 389 Administration Server.
Loaded: loaded (/lib/systemd/system/dirsrv-admin.service; disabled; vend=
or preset: enabled)
Active: failed (Result: exit-code) since Tue 2018-01-30 12:32:36 CET; 6m=
s ago
Process: 15226 ExecStart=3D/usr/sbin/apache2 -k start -f /etc/dirsrv/admi=
n-serv/httpd.conf (code=3Dexited, status=3D1/FAILURE)
gen 30 12:32:35 Jafar systemd[1]: dirsrv-admin.service: Failed to reset dev=
ices.list: Operation not permitted
gen 30 12:32:35 Jafar systemd[1]: Starting 389 Administration Server....
gen 30 12:32:36 Jafar systemd[1]: dirsrv-admin.service: Control process exi=
ted, code=3Dexited status=3D1
gen 30 12:32:36 Jafar systemd[1]: Failed to start 389 Administration Server=
..
gen 30 12:32:36 Jafar systemd[1]: dirsrv-admin.service: Unit entered failed=
state.
gen 30 12:32:36 Jafar systemd[1]: dirsrv-admin.service: Failed with result =
'exit-code'.
it seems a problema about lxc privileges.
is there anyone running 389 with lxc?
regards,
abosch
-- Institut Mallorquí d'Afers Socials. Aquest missatge, i si escau, qualsevol fitxer annex, es dirigeix exclusivament a la persona que n'és destinatària i pot contenir informació confidencial. En cap cas no heu de copiar aquest missatge ni lliurar-lo a terceres persones sense permís exprés de l'IMAS. Si no sou la persona destinatària que s'hi indica (o la responsable de lliurar-l'hi) us demanam que ho notifiqueu immediatament a l'adreça electrònica de la persona remitent.
-- Abans d'imprimir aquest missatge, pensau si és realment necessari.
6 years, 2 months