NOTE: SSL is considered insecure - do not use it - use only TLSv1 and later In most places below where this document refers to the term “SSL”, it usually means “TLSv1”. The term “SSL” is kept around for historical reasons, but SSLv3 should never be used.
See newer documentation here:
In Fedora DS 1.1 and later, the keys and certificates are stored in a server instance specific directory, along with the other server configuration files. By default, this is /etc/dirsrv/slapd-instancename e.g.
/etc/dirsrv/slapd-localhost
/etc/dirsrv/admin-serv
The commands below that use a -d . argument assume you are in this directory. You can also specify the directory explicitly e.g.
certutil -d /etc/dirsrv/slapd-localhost -L
In Fedora DS 1.0.4 and earlier, the directory /opt/fedora-ds/alias is used to store the key/cert databases for all server instances, and each one has a name like slapd-instancename-cert8.db. You are required to specify the database prefix, including the trailing dash (“-“). Also, the certutil command is found in /opt/fedora-ds/shared/bin e.g.
cd /opt/fedora-ds/alias
../shared/bin/certutil -d . -P slapd-localhost- -L
WARNING:
These scripts are only recommended for use in single server applications
in testing environments. They are not suitable for generating multiple
server certs for multi-supplier replicated servers. They are not suitable
for production use.
Please use an actual Certificate Authority (CA) instead.
There are two different scripts to use. The first one is for the Fedora DS 1.0.x and earlier layout. This layout stores all of the key/cert databases for all servers in the directory /opt/fedora-ds/alias and identifies each one by a unique prefix e.g. slapd-localhost- or admin-serv-localhost-.
The second one is for the Fedora DS 1.1 and later layout. This layout stores the key/cert databases in server specific directories e.g. /etc/dirsrv/slapd-
Each shell script will create your initial CA certificate, your DS server cert, your AS server cert, your DS pin.txt file for unattended restarts, your AS password.conf file for unattended restarts, will enable the DS to use SSL, and will export your CA cert for use in other (replicas, openldap, openssl) applications.
If the script completes successfully, you can skip to section Configure LDAP clients
NOTE: The script makes the following assumptions:
MYHOST=my.real.fqdn setupssl2.sh …
This page is a graphically illustrated (screenshots) step-by-step guide to setting up your Fedora DS servers to use TLS/SSL. This guide also includes client configuration for many linux and unix systems, and even Mac.
It is required to have a self signed certificate, certificate database, and keys. Please see the following link which will guide you through setting that up:
NOTE - In order for the CA certificate to be a real, valid CA certificate, you must add the Basic Constraints option (-2) to the certutil -S command used to create the self signed CA. Adding -2 will cause certutil to prompt you for 3 questions:
For example:
#> certutil -S -n "CA certificate" -s "cn=CAcert" -x -t "CT,," -m 1000 -v 120 -d $secdir \
-z $secdir/noise.txt -f $secdir/pwdfile.txt -2
Is this a CA certificate [y/N]? y
Enter the path length constraint, enter to skip [<0 for unlimited path]:
Is this a critical extension [y/N]? y
NOTE - You must use the fully qualified domain name of your server host as the value of the cn attribute in the subject DN. For example, if your directory server hostname is foo.example.com, use
cd /etc/dirsrv/slapd-yourinstancename
certutil -S -n "Server-Cert" -s cn=foo.example.com -c "CA certificate" \
-t "u,u,u" -m 1001 -v 120 -d . -z noise.txt -f pwdfile.txt
If you are using Fedora DS 1.0.4 or earlier, use this instead:
cd /opt/fedora-ds/alias
../shared/bin/certutil -S -n "Server-Cert" -s cn=foo.example.com -c "CA certificate" \
-t "u,u,u" -m 1001 -v 120 -d . -z noise.txt -f pwdfile.txt
to generate your server cert. This is the minimum. You may wish to provide your clients with more details about your server. For more information, see RFC 1485. You could choose to specify the subject DN like this:
certutil ... -s "cn=foo.example.com,ou=engineering,o=example corp,c=us" ...
Note: The -m argument to certutil -S must be a unique number every time - this is the serial number of the certificate. A CA may not issue two certs with the same serial number. If you plan on using this CA to issue more than a few certs, you should save this number somewhere safe and use a different number each time.
Note: Make sure all of the files in /etc/dirsrv/slapd-instancename are owned by the directory server uid.
Note: If you are using Fedora DS 1.0.4 or earlier, make sure the alias/*.db files are owned by the directory server uid e.g. if you have chosen slapd to be run as “nobody” or “ldap”, make sure the alias directory and the *.db files in there are owned by that user. The directory server has to open those files in read-write mode.
After following the above instructions, you should save the CA information. You may need this CA to generate other certs at a later date or revoke them.
pk12util -d . -o cacert.p12 -n "CA certificate"
Or if you are using Fedora DS 1.0.4 or earlier:
../shared/bin/pk12util -d . -P slapd-serverID- -o cacert.p12 -n "CA certificate"
Note slapd-serverID- <-This trailing dash is crucial! Be sure to back up cacert.p12 in a safe place.
Would like to note one thing about the above document. When asked to convert the certificate database to pkcs12 format make sure the following format is used:
pk12util -d . -o servercert.p12 -n Server-Cert
or if you are using Fedora DS 1.0.4 or earlier:
../shared/bin/pk12util -d . -P slapd-serverID- -o servercert.p12 -n Server-Cert
Note slapd-serverID- <-This trailing dash is crucial!
Note the above step is only needed if you want to backup your server key and cert (a good idea), or if you are planning on importing the key and cert into other applications (e.g. use openssl to convert the p12 file into other formats).
Now that you have your server cert, client applications will need to be able to verify that cert when connecting to the server. In order to do that, the TLS/SSL client must have the CA cert to verify that the cert presented by the TLS/SSL server is valid. This includes server to server communication such as replication. The TLS/SSL roles are opposite the supplier/consumer roles. The supplier pushes changes to the slave. So in this instance, the slave is the TLS/SSL server, and the supplier is the TLS/SSL client.
You can use certutil on the supplier to make a cert for the slave, using the commands below on the supplier. Then, use pk12util to export the slave cert/key, then take that pk12 file to the slave and use pk12util to import it (and use certutil to import the CA cert).
Where “consumer.mydomain.com” is the real FQDN of the replication consumer. The value to the -m argument is the cert serial number - be sure that this value is unique.
certutil -S -n "consumer-Cert" -s "cn=consumer.mydomain.com" -c "CA certificate" -t "u,u,u" -m UNIQUEVALUEHERE -v 120 -d . -k rsa
pk12util -d . -o consumer-cert.p12 -n consumer-Cert
Works for Fedora 1.0.5+ and RHDS8
certutil -L -d . -n "CA certificate" -a > cacert.asc
if you are using Fedora DS 1.0.4 or earlier:
../shared/bin/certutil -L -d . -P slapd-serverID- -n "CA certificate" -a > cacert.asc
Use -a for ASCII RFC 1113 format, or -r for binary DER encoding. Without -a or -r, this will just print out the certificate information in human readable form.
pk12util -d . -i consumer-cert.p12
you will also need to import the CA cert
cd /etc/dirsrv/slapd-otherserverID
certutil -A -d . -n "CA certificate" -t "CT,," -a -i cacert.asc
or if you are using Fedora DS 1.0.4 or earlier:
cd /opt/fedora-ds/alias (on another machine e.g. the replication consumer)
../shared/bin/certutil -A -d . -P slapd-otherserverID- -n "CA certificate" -t "CT,," -a -i cacert.asc
Omit the -a if you have a binary DER encoded cert (if you use -r to export the cert). You may be prompted for password you used to secure your database files with. After this, you will have to restart the slapd to have it use the new CA cert.
The Admin Server looks for its key and cert databases in the /etc/dirsrv/admin-serv directory. In order for the Admin Server to use TLS/SSL to talk to the directory server, you must have the certificate of the CA that issued the directory server certificate in the cert db of the admin server.
cd /etc/dirsrv/admin-serv
certutil -A -d . -n "CA certificate" -t "CT,," -a -i cacert.asc
Omit the -a if you have a binary DER encoded cert (if you use -r to export the cert). You may be prompted for password you used to secure your database files with. After this, you will have to restart the admin server to have it use the new CA cert:
service dirsrv-admin restart
or
/usr/sbin/restart-ds-admin
The Admin Server looks for its key and cert databases in the /opt/fedora-ds/alias directory. It uses the prefix admin-serv-hostname- where hostname is your hostname. In order for the Admin Server to use TLS/SSL to talk to the directory server, you must have the certificate of the CA that issued the directory server certificate in the cert db of the admin server.
cd /opt/fedora-ds/alias
../shared/bin/certutil -A -d . -P admin-serv-hostname- -n "CA certificate" -t "CT,," -a -i cacert.asc
Omit the -a if you have a binary DER encoded cert (if you use -r to export the cert). You may be prompted for password you used to secure your database files with. After this, you will have to restart the admin server to have it use the new CA cert - /opt/fedora-ds/restart-admin.
This will create a out file /tmp/crt.p12
openssl pkcs12 -export -inkey PRIVATE-KEY -in CERTIFICATE -out /tmp/crt.p12 -nodes -name ’Server-Cert’
Then import the key/cert:
cd /etc/dirsrv/slapd-INSTANCE
pk12util -i /tmp/crt.p12 -d .
or with Fedora DS 1.0.4 and earlier:
cd /opt/fedora-ds/shared/bin
./pk12util -i /tmp/crt.p12 -d /opt/fedora-ds/alias/ -P slapd-INSTANCE-
You also need to import the CA cert chain. Many times the entire chain is in a single .pem file.
certutil -d /etc/dirsrv/slapd-INSTANCE -A -n "My Local CA" -t CT,, -a -i /path/to/ca.pem
or with Fedora DS 1.0.4 and earlier:
certutil -d /opt/fedora-ds/alias/ -P slapd-INSTANCE- -A -n "My Local CA" -t CT,, -a -i /path/to/ca.pem
Note:
If your cert expires and you need to issue another one, you may have to remove the old one first. This is because some utilities will issue the new cert with the same nickname as the old one, and will not allow you to rename it when you import the new one. You will usually see errors like this if this happens:
pk12util-bin: PKCS12 decode import bags failed: You are attempting to
import a cert with the same issuer/serial as an existing cert, but that
is not the same cert.
If this happens, follow these steps:
In case something goes wrong, you will want to be able to restore your old server cert.
cd /etc/dirsrv/slapd-INSTANCE
pk12util -d . -o olddscert.p12 -n "Server-Cert"
or with Fedora DS 1.0.4 and earlier:
cd /opt/fedora-ds/alias
../shared/bin/pk12util -d . -P slapd-INSTANCE- -o olddscert.p12 -n "Server-Cert"
You will be prompted for the key/cert db password, and the password to use to encrypt the .p12 file. If you don’t know what the name is for your server cert, use
certutil -L -d .
or with Fedora DS 1.0.4
certutil -d . -P slapd-INSTANCE- -L
to list the contents of your cert db.
Did I mention to first back it up?
certutil -D -d . -n "Server-Cert"
or with Fedora DS 1.0.4
../shared/bin/certutil -D -d . -P slapd-INSTANCE- -n "Server-Cert"
This assumes you have the new cert in a .p12 file. Make sure, when you created your p12 file, that you gave the certificate the name “Server-Cert”, or whatever the value you have given nsSSLPersonalitySSL in your directory.
pk12util -d . -i newservercert.p12
or with Fedora DS 1.0.4
../shared/bin/pk12util -d . -P slapd-INSTANCE- -i newservercert.p12
You will be prompted for the password used to encrypt the newservercert.p12 file as well as the key/cert db password.
Create an LDIF file called /tmp/ssl_enable.ldif with the following data in it. Be sure to change
dn: cn=encryption,cn=config
changetype: modify
replace: nsSSL3
nsSSL3: off
-
replace: nsSSLClientAuth
nsSSLClientAuth: allowed
-
add: nsSSL3Ciphers
nsSSL3Ciphers: +all
dn: cn=config
changetype: modify
add: nsslapd-security
nsslapd-security: on
-
replace: nsslapd-ssl-check-hostname
nsslapd-ssl-check-hostname: off
If using Fedora DS 1.0.4 or earlier, add the following:
dn: cn=encryption,cn=config
changetype: modify
add: nsKeyfile
nsKeyfile: alias/slapd-<instance>-key3.db
-
add: nsCertfile
nsCertfile: alias/slapd-<instance>-cert8.db
Then, use ldapmodify to apply this to your directory server:
ldapmodify -x -D "cn=directory manager" -w password -f /tmp/ssl_enable.ldif
Or, if you cd shared/bin ; ./ldapmodify, you may omit the -x.
Then, create a file called /tmp/addRSA.ldif with the following data:
dn: cn=RSA,cn=encryption,cn=config
changetype: add
objectclass: top
objectclass: nsEncryptionModule
cn: RSA
nsSSLPersonalitySSL: Server-Cert
nsSSLToken: internal (software)
nsSSLActivation: on
Then use ldapmodify to add it:
ldapmodify -x -D "cn=directory manager" -w password -a -f /tmp/addRSA.ldif
Or, if you cd shared/bin ; ./ldapmodify, you may omit the -x.
Restart slapd server instance
# service dirsrv restart [<instance>]
If you omit the instance, all instances will be restarted. Or
# $libdir/dirsrv/slapd-<instance>/restart-slapd
Where $libdir is your system lib directory (e.g. /usr/lib or /usr/lib64 or /usr/lib/64 or ???) Or, for Fedora DS 1.0.4 and earlier:
# /opt/fedora-ds/slapd-<instance>/restart-slapd
If you do not have PIN file, it will prompt you for the password you used to create the server cert.
If you are going to use your server with Kerberos + SASL + GSSAPI, then review the Howto:Kerberos, particularly the section on “Keys”.
The following instructions are for Linux clients, almost all of which use the openldap client libraries that are the standard LDAP client libraries on those systems. This includes the ldapsearch used below, which is not the one included with Fedora DS.
Modify the following in /etc/openldap/ldap.conf
URI ldap://example.com
BASE dc=example,dc=com
HOST example.com
TLS_CACERTDIR /etc/openldap/cacerts/
TLS_REQCERT allow
Note: Make sure TLS_CACERTDIR exists. Next, if you haven’t done so, export your CA cert to ASCII (use the -a option above). Then, install it in the cacerts directory like so:
cacertdir_rehash /etc/openldap/cacerts/
The file name is the hash of the contents with a “.0” filename extension.
If you can’t get it to work with TLS_CACERTDIR, you can just tell it to use the cacert file directly:
TLS_CACERT /etc/openldap/cacerts/cacert.asc
If you have more than 1 CA cert, you will have to concatenate them into a single file.
# ldapsearch -x -ZZ '(uid=testuser)'
Check your access logs /opt/fedora-ds/slapd-\ hostname -s\ /logs/access, should have something similar to
[18/Jul/2005:20:33:36 -0400] conn=4 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[18/Jul/2005:20:33:36 -0400] conn=4 op=0 RESULT err=0 tag=120 nentries=0 etime=0
[18/Jul/2005:20:33:36 -0400] conn=4 TLSv1.1 256-bit AES
[18/Jul/2005:20:33:36 -0400] conn=4 op=1 BIND dn="" method=128 version=3
[18/Jul/2005:20:33:36 -0400] conn=4 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn=""
[18/Jul/2005:20:33:36 -0400] conn=4 op=2 SRCH base="dc=example,dc=com" scope=2 filter="(uid=testuser)" attrs=ALL
When used with the -Z option, ldapsearch needs the absolute path to a cert8.db file to know about the certificate chain trust, here are some examples:
If using the openldap-clients package, and if the CA cert is not already imported, either edit /etc/openldap/ldap.conf like above or try this:
# vi ~/.ldaprc
# TLS_CACERT <path-to-ca>.pem
TLS_REQCERT allow
And then, for example:
/usr/bin/ldapsearch -H ldaps://<some-host> -x -D "cn=directory manager" -w <some-password> -s base -b "" objectclass=*|less
If running a shell on a current ldap server, e.g. FDS 1.0.4:
/opt/fedora-ds/shared/bin/ldapsearch -Z -p 636 -P /opt/fedora-ds/alias/slapd-<instance-name>-cert8.db -D "cn=directory manager" -w <some-password> -s base -b "" objectclass=*|less
or with FDS 1.1
/usr/lib/mozldap/ldapsearch Z -p 636 -P /etc/dirsrv/slapd-<instance-name>-cert8.db -D "cn=directory manager" -w <some-password> -s base -b "" objectclass=*|less
Or if using a desktop with Firefox, assuming you can browse to the admin express pages if https had been enabled, to import the server cert, and then, assuming my desktop has the mozldap package, run for example:
/usr/lib/mozldap/ldapsearch -Z -P /home/<some-uid>/.mozilla/firefox/<some-path>.default/cert8.db -p 636 -h <some-host> -D "cn=directory manager" -w <some-password> -s base -b "" objectclass=*|less
See
The modutil command can be used to change the password, or even change it to an empty password so the password/pin is no longer needed.
cd /etc/dirsrv/slapd-foo
modutil -dbdir . -changepw "NSS Certificate DB"
or for Fedora DS 1.0.4 and earlier:
cd /opt/fedora-ds/alias
../shared/bin/modutil -dbdir . -dbprefix slapd-foo- -changepw "NSS Certificate DB"
Enter the old password then press Enter twice for the new password to blank it out.
Using the console, go into the Directory Server that you want to use TLS/SSL with, then go into the Configuration tab, then go to the Encryption tab in the right hand pane. If you have not already done so, you must have already enabled TLS/SSL for this server by using the steps above.
The check box “Use SSL in Fedora Console” tells the console to use TLS/SSL when communicating with this directory server. The directory server must already be configured to use TLS/SSL before you set this option. Note that although the term “SSL” is used in this context, it really means “Use the highest strength TLS encryption available”.
You must first find the entry corresponding to the directory server you want the console to use TLS/SSL with.
ldapsearch -x -D "cn=directory manager" -w password -b o=netscaperoot "nsServerID=slapd-yourinstance"
If you have more than one server named “slapd-yourinstance”, you can add the hostname of the server to narrow it down:
ldapsearch -x -D "cn=directory manager" -w password -b o=netscaperoot \
"(&(nsServerID=slapd-yourinstance)(serverHostName=myhost.domain.tld))"
The attribute in this entry that controls whether or not TLS/SSL is used is nsServerSecurity. Set this to “on” if you want to use TLS/SSL or “off” if not e.g.
ldapmodify -x -D "cn=directory manager" -w password
dn: dn of your server instance entry
changetype: modify
replace: nsServerSecurity
nsServerSecurity: on
The console has a UI that allows you to view, request, and install certificates, for servers and CAs. For some reason, self-signed CA certs show up under Server Certs - this is ok - the cert is still treated as a CA cert, it just shows up in the wrong place in the UI.
The console only generates the cert request. It does not actually create a server cert. You must submit the cert request to a CA and have the CA generate the actual cert, which you can then install using the console.
NSS has a built-in list of root CAs that it trusts. If you want to view this list in the console, you must make a symlink to the libnssckbi.so file in your security directory. For example, on a 32-bit system:
cd /etc/dirsrv/slapd-instancename
ln -s /usr/lib/libnssckbi.so
Then, the console Manage Certificates -> CA Certs will show all of the built-in root CAs in addition to any you have installed. On a 64-bit system, use /usr/lib64 instead. You can do the same thing for the Admin Server console window:
cd /etc/dirsrv/admin-serv
ln -s /usr/lib/libnssckbi.so
With Fedora DS 1.1, the Admin Server uses /etc/dirsrv/admin-serv as the location of the key and certificate databases. Since this directory is unique and private to the Admin Server, the -P prefix arguments should be omitted e.g.
cd /etc/dirsrv/admin-serv
certutil -d . -L
If using Fedora DS 1.0.4 and earlier, the directory /opt/fedora-ds/alias is shared by the directory servers and the admin server, so the key/cert database must have a unique prefix, so the -P prefix argument is required.
The Managing Servers with Red Hat Console manual provides information about setting up and using the console with an TLS/SSL enabled Admin Server.
The script mentioned above will generate the key/cert db for admin server and install it in the correct place.
There are several files and directory entries which control if/how TLS/SSL is used with Admin Server and Console.
Note: if you used the script above, this section is already done for you.
If you want the admin server to start unattended with TLS/SSL, you must put the pin/password in a file for the admin server to use. First, create a file called /etc/dirsrv/admin-serv/password.conf (or with Fedora DS 1.0.4 /opt/fedora-ds/alias/password.conf). The format is
internal:password
Make sure the file is mode 400 and owned by your admin server user (default nobody:nobody)
chown nobody:nobody password.conf
chmod 400 password.conf
Next, tell admin server to use the password file. Edit the file /etc/dirsrv/admin-serv (or admin-serv/config/nss.conf) and change the directive NSSPassPhraseDialog to point to your password.conf file:
NSSPassPhraseDialog file:/etc/dirsrv/admin-serv/password.conf
or with Fedora DS 1.0.4:
NSSPassPhraseDialog file:/opt/fedora-ds/alias/password.conf
Make sure the file is mode 400 and owned by your admin server user (default nobody:nobody)
chown nobody:nobody nss.conf
chmod 400 nss.conf
This file should contain the following directives (Apache conf style directives). The value in [brackets] is the default, and you may not need to change it.
The following setting must be omitted with Fedora DS 1.1 and later, and must be used with Fedora DS 1.0.4 and earlier:
To verify the above settings, try something like this:
cd /etc/dirsrv/admin-serv
certutil -d . -L
or with Fedora DS 1.0.4 and earlier:
cd /opt/fedora-ds/alias
../shared/bin/certutil -d . -P admin-serv-yourhost- -L
you should see server-cert listed as an TLS/SSL server certificate.
The following only applies when using Fedora DS 1.0.4 and earlier. When Admin Server TLS/SSL is enabled, the file should have the following 3 additional attributes:
security: on
certDBFile: /opt/fedora-ds/alias/admin-serv-yourhost-cert8.db
keyDBFile: /opt/fedora-ds/alias/admin-serv-yourhost-key3.db
Some of the admin server configuration is stored in the configuration directory server. To find this entry, first do a search like the following (assuming your configuration directory server is running on the localhost and listening to port 389):
/usr/bin/ldapsearch -x -D "cn=directory manager" -w password -b o=netscaperoot \
'(&(cn=configuration)(objectclass=nsadminconfig))'
There is an attribute in this entry called nsServerSecurity - set to “on” to enable TLS/SSL, “off” otherwise (or absent).
Do the following ldapsearch to find the entry (it should be the child of the cn=configuration entry above):
/usr/bin/ldapsearch -x -D "cn=directory manager" -w password -b o=netscaperoot cn=encryption
You should see something like the following (nsCertfile and nsKeyfile are only applicable with Fedora DS 1.0.4 and earlier):
dn: cn=encryption, cn=configuration, cn=admin-serv-localhost, cn=Fedora Admini
stration Server, cn=Server Group, cn=localhost.localdomain, ou=localdomain, o
=NetscapeRoot
cn: encryption
objectClass: nsEncryptionConfig
objectClass: top
nsCertfile: alias/admin-serv-localhost-cert8.db
nsKeyfile: alias/admin-serv-localhost-key3.db
nsSSL2: off
nsSSL3: off
nsSSLSessionTimeout: 0
nsSSL3SessionTimeout: 0
nsSSLClientAuth: off
nsSSL2Ciphers: +des,+rc2export,+rc4export,+desede3,+rc4,+rc2
nsSSL3Ciphers: +rsa_rc2_40_md5,+rsa_rc4_128_md5,+rsa_3des_sha,+rsa_rc4_40_md5,
+fips_des_sha,+fips_3des_sha,+rsa_des_sha,-rsa_null_md5
Do the following ldapsearch to find the entry (it should be the child of the cn=encryption entry above):
/usr/bin/ldapsearch -x -D "cn=directory manager" -w password -b o=netscaperoot cn=RSA
You should see something like the following:
dn: cn=RSA, cn=encryption, cn=configuration, cn=admin-serv-localhost, cn=Fedor
a Administration Server, cn=Server Group, cn=localhost.localdomain, ou=locald
omain, o=NetscapeRoot
cn: RSA
objectClass: nsEncryptionModule
objectClass: top
nsSSLToken: internal (software)
nsSSLPersonalitySSL: server-cert
nsSSLActivation: on
(Submitted by pkime [at] Shopzilla.com)
I just did this and thought others might like to see the procedure if the non-VIPed setup is already running. The issue is the TLS/SSL certs - they won’t like the names/IPs of the VIPs and will complain (or depending on your setup, fail completely) when starting TLS/SSL. I assume your VIPs exist - here’s how to change the TLS/SSL certs to work with the VIPs
You already have the two servers up and running on TLS/SSL with their certificates working. How do you change the certificates to include the VIP names so things like “ldapsearch -ZZZ” don’t die? You have to add an X.509 v3 “SubjectAltName” certificate extension to the certificate. But you can’t add it, so you have to create a new certificate. This is how I did it and it has minimal impact - just one quick FDS restart (and even that might not be strictly necessary - please correct me).
My situation was having two ldap servers and needing to put them behind two load-balanced VIPs.
ldap1.foo.com
ldap2.foo.com
For each server, I did this:
Generate a certificate request from the server. Either in the GUI and paste to a file or go into
/etc/dirsrv/slapd-instancename
and do
certutil -R -d . -s <SUBJECTNAME> -o cert.req -a
or with Fedora DS 1.0.4 and earlier:
/opt/fedora-ds/alias
and do
/opt/fedora-ds/shared/bin/certutil -R -d /opt/fedora-ds/alias -s <SUBJECTNAME> -o cert.req -a
You may need the “-P” flag if using Fedora DS 1.0.4 and earlier and your cert8.db and key3.db files for the DS are not the default names. I tend to use “-a” for ascii output as I have had problems with binary requests and certs in the past.
Where “
certutil -L -n <CERTNAME> -d /etc/dirsrv/slapd-instancename
or with Fedora DS 1.0.4 and earlier:
/opt/fedora-ds/shared/bin/certutil -L -n <CERTNAME> -d /opt/fedora-ds/alias
Again, you may need the “-P” flag if using Fedora DS 1.0.4 and your cert db files are not the default names. Here “
certutil -L -d /etc/dirsrv/slapd-instancename
or with Fedora DS 1.0.4 and earlier:
/opt/fedora-ds/shared/bin/certutil -L -d /opt/fedora-ds/alias
If you are generating the cert request in the GUI, you can either enter the DN information in the separate fields or choose the DN view and just paste it in. Generate the request, get it into a file called “cert.req” and do this
certutil -C -d /etc/dirsrv/slapd-instancename -c <CACERT> -i cert.req -o cert.crt -a -m <ID> -v 120 -8 <VIPs>
or with Fedora DS 1.0.4 and earlier:
/opt/fedora-ds/shared/bin/certutil -C -d /opt/fedora-ds/alias -c <CACERT> -i cert.req -o cert.crt -a -m <ID> -v 120 -8 <VIPs>
This is where you generate the cert with the extensions.
You’ll be prompted for the internal token to access the certificate database - I tend to use the “-f file” flag to get this from a file where it’s stored.
In our example:
certutil -C -d /etc/dirsrv/slapd-instancename -c <CACERT> -i cert.req -o cert.crt -a -m <ID> -v 120 -8 ldap1.foo.com,ldap2.foo.com
or with Fedora DS 1.0.4 and earlier:
/opt/fedora-ds/shared/bin/certutil -C -d /opt/fedora-ds/alias -c <CACERT> -i cert.req -o cert.crt -a -m <ID> -v 120 -8 ldap1.foo.com,ldap2.foo.com
The resulting certificate is left in the “cert.crt” file.
Then install the certificate in the GUI (copy-paste is easy) - it will tell you that the Subject DN is identical to the certificate already installed and so it will call it by the same name. This is good and by design. So, now you will see two certificates with the same name. Delete the older one without the extensions (easy to do this in the GUI). I restarted the DS at this point in case it had cached the old certificate but this may not be necessary.
That’s it. Your certificate now has the extensions to allow it to work with the VIP names and TLS/SSL won’t complain. ldapsearch -ZZZ should still work fine. You can check the certificates by the “certutil -L” commands above and you should see this in the certificate:
Signed Extensions:
Name: Certificate Subject Alt Name
DNS name: "ldap1.foo.com"
DNS name: "ldap2.foo.com"
The trick with keeping the Subject DN the same (but changing the serial number, which is mandatory), means that you don’t have to go into the DS setup and change the certificate name being used … it just carries on working with minimal impact.
You can store the PIN/password protecting the certificate databases in such a way that the server won’t prompt you for them during startup, but will read from from local files instead.
Edit /etc/dirsrv/admin-serv/nss.conf and change NSSPassPhraseDialog to read:
NSSPassPhraseDialog file://///etc/dirsrv/admin-serv/password.conf
Then create /etc/dirsrv/admin-serv/password.conf:
touch /etc/dirsrv/admin-serv/password.conf
chmod 600 /etc/dirsrv/admin-serv/password.conf
chown ldap /etc/dirsrv/admin-serv/password.conf
Edit /etc/dirsrv/admin-serv/password.conf and place this single line in there:
internal:adminserv_cert_password
Create /etc/dirsrv/slapd-instance_name/pin.txt (substitute slapd-instance_name for actual server instance’s directory name):
touch /etc/dirsrv/slapd-instance_name/pin.txt
chmod 600 /etc/dirsrv/slapd-instance_name/pin.txt
chown ldap /etc/dirsrv/slapd-instance_name/pin.txt
Edit the pin.txt file and place a single line in it (notice the difference in internal token name between this and Admin Server’s):
Internal (Software) Token:dirserv_cert_password
That’s it. Restart the server to test whether it doesn’t ask for the PIN anymore and starts up properly with TLS/SSL.
Java/JNDI uses keystores created with the keytool program.
Requirements:
Steps:
Create a directory to hold the keystore
mkdir ~/javakeystore
Make sure keytool can read the cacert
keytool -printcert -file /path/to/cacert.asc
Use keytool to import the CA cert - NOTE: keytool will prompt for a password
cd ~/javakeystore
keytool -import -alias cacert -file /path/to/cacert.asc -keystore cacerts
Run the Java/JNDI client - specify the javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword properties
java -Djavax.net.ssl.trustStore=~/javakeystore/cacerts -Djavax.net.ssl.trustStorePassword=password MyMainClass
Note that the trustStorePassword is the same password that keystore -import asked for.