SSL certs in RedHat Directory Server and multi-master replication

[support_5]

Hi all,

I am setting up RedHat (aka Netscape) Directory Server for use with LDAP-UX for client authentication. I have used the certutil program supplied to create the SSL certificates on a server. Then copied the db files to a test HP-UX client and configured LDAP-UX to use SSL, and it does so as expected.

I am now trying to set up "Mulit-Master Replication" for the RH Directory Server with another RH Directory Server. However, I also need to do this over SSL. But I have no idea how to manage the certificates/keys on the two servers, nor how to configure the various HP-UX clients? Eg how do I import certificates/keys onto the various HP-UX servers, and how do I import the keys/certs for the two RH directory servers?

NB that I have used the certutil tool to create what I think is called a "self-signed certificate", whatever that means. So I'm assuming I will need to use the certutil tool to do what I am hoping to achieve above.


So can anyone shed some light on SSL certificates and if possible, specificly mention how to manage them for the LDAP-UX clients and especially the RH Directory Servers so I can set up Multi-Master Replication over an SSL connection (using simple bind authentication).

Thank you very much.

- Andrew G

PS I have read the documentation and that is how I managed to get the LDAP-UX client working with SSL using certutil to create the certs. However, the documentation is vague and sketchy when it comes to addressing this particular topic, and my knowledge of how SSL works is sketchy to begin with. Ta

[Ivan Ferreira]

Have you downloaded the Administratorâ s Guide - Red Hat Directory Server from the Red Hat documentation page? The document has the following sections:

Managing replication - Replication over SSL

Managing SSL and SASL

BTW, a self signed certificate is a certificate that was signed by the server that issues the certificate. Normally certificates are signed by a third party entity like VeriSign and ensures that the certificate is from the entity that claims to issue the certificate, increasing security because the clients that accepts the certificate, knows that it was signed by another organization that ensures the authenticity of the certificate.

[support_5]

Hi,

Yes, I have read those chapters, that's how I got SSL working with LDAP-UX, however, like I said above, those chapters dont really give specifics on how to set up replication over SSL. All it says is:

To use replication over SSL, you must first do the following:
â ¢ Configure both your supplier and consumer servers to use SSL.
â ¢ Configure your consumer server to recognize your supplier serverâ s
certificate as the supplier DN. You do this only if you want to use SSL client
authentication rather than simple authentication.

However, the specifics on actually HOW to do this with certutil is not covered. That's why I'm asking if anyone here knows.

I know that typically you get a certificate from an authority so that you can verify the authenticity of the server, but you see I dont care about that. It's in a closed network, and all I care about is encrypted traffic. Plus, I don't want to pay for certificates, nor do I want to wait for them to arrive once ordered.

So if anyone knows about certutil, and how to import and export keys or anything like that, well, any help would be much appreciated.

Thanks.

- Andrew G

[support_5]

IE, how do I get the two master servers to recognise each others certificate, and how do I get the LDAP-UX clients to recognise the two certificates for each server?

Do I run certutil on both servers, or do I run it twice on one server to generate the certs, then how do I transfer them etc?

These are the sorts of things I would be interested to see if anyone knows the answer to.

Thanks again all.

- Andrew G

[Weltman, Ulf · Accepted solution]

Hello Andrew. For the RHDS master to recognize the server certificate of the RHDS consumer, it needs to trust its issuer. With certutil the easiest way is to first generate a self-signed CA ("Issuer") certificate and then generate the server certificates from it. But first, generate a new empty cert/key db pair:
certutil -N -P "CA-" -d /tmp -f keypassword.txt

That will leave you with /tmp/CA-cert8.db and /tmp/CA-key3.db. keypassword.txt should be a simple text file created before hand containing the password that you want to lock your private key database with.

Next create the self-signed CA cert in the same db pair:

certutil -S -P "CA-" -d /tmp -n "CA Cert" -s "CN=CA Cert,O=Example Corp" -x -v 120 -t "CT,," -z noisefile.txt -f keypassword.txt

noisefile.txt should be created beforehand, it might contain random stuff from just typing randomly on the keyboard and is used to prime the random generator.

Now prepare to create the server certificates. Let's say you're creating for slapd-master and slapd-consumer.

cp /tmp/CA-cert8.db /tmp/slapd-master-cert8.db
cp /tmp/CA-cert8.db /tmp/slapd-consumer-cert8.db
cp /tmp/CA-key3.db /tmp/slapd-master-key3.db
cp /tmp/CA-key3.db /tmp/slapd-consumer-key3.db

Now create the server certificates, issued from the CA cert:

certutil -S -P "slapd-master-" -d /tmp -n "Server-Cert" -s "CN=host1.example.com,O=Example Corp" -c "CA Cert" -v 120 -t "u,u,u" -z noisefile.txt -f keypassword.txt

certutil -S -P "slapd-consumer-" -d /tmp -n "Server-Cert" -s "CN=host2.example.com,O=Example Corp" -c "CA Cert" -v 120 -t "u,u,u" -z noisefile.txt -f keypassword.txt

Then copy the server cert/key dbs to the right places:
cp /tmp/slapd-master-*.db /var/opt/netscape/servers/slapd-master/../alias/
cp /tmp/slapd-consumer-*.db /var/opt/netscape/servers/slapd-consumer/../alias/

The "-s" argument in the above certutil commands is important when creating server certificates, the CN component should match the exact hostname the clients will use. In this example the consumer hostname in the master's replication agreement would be "host2.example.com". If it doesn't match then the SSL client (replication master) will complain and refuse to complete the connection to the SSL server (replication consumer). You can disable that behavior with the nsslapd-ssl-check-hostname parameter in the DSE, but if you have full control over your environment you might as well use the right names.

Now for LDAP-UX, it doesn't need a server certificate because it doesn't listen on LDAPS. In SSL terms it acts as a client so it only needs to trust the issuer of the RHDS server certificate. You can use the CA-cert8.db and CA-key3.db:
cp /tmp/CA-cert8.db /tmp/cert8.db
cp /tmp/CA-key3.db /tmp/key3.db

A final note... This procedure leaves you with the CA private signing key in your server certificate databases. Everything is also using the same key database password. In a highly secure environment you would want to put your signing database somewhere for safe keeping somewhere, and your server key databases would only hold the server's private key, and the LDAP-UX pair should hold only the public CA certificate.

[support_5]

Wow, thank you so much for that excellent detailed response! I must confess I don't understand everything you mentioned, but enough to get the gist of it.

I have followed what you said and played around with it and have managed to get the replication working over SSL.

Thank you so much for your help! I think this will do it.

- Andrew G