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 SSL certs - they won't like the names/IPs of the VIPs and will complain (or depending on your setup, fail completely) when starting SSL/TLS. I assume your VIPs exist - here's how to change the SSL certs to work with the VIPs
 
 
You already have the two servers up and running on 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
 
/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 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 "<SUBJECTNAME>" is the DN for the Certificate. This is the nice part - make sure that this is *exactly* the same as your already-in-use SSL cert's Subject DN. To find this out what this is, do
 
/opt/fedora-ds/shared/bin/certutil -L -n <CERTNAME> -d /opt/fedora-ds/alias
 
Again, you may need the "-P" flag if your cert db files are not the default names. Here "<CERTNAME>" is the name of your server SSL cert. You can list all the cert names with:
 
/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 seperate fields or choose the DN view and just past it in. Generate the request, get it into a file called "cert.req" and do this
 
/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.
 
<CACERT> is the name of your CA cert that is issuing the certificate - make sure it's the same CAcert that issued your current SSL cert (that way your clients which have the existing public CAcert wont' break). You can find out the name of it in the same way as described above for the server cert name.
<ID> is a unique, arbitrary serial number for the cert. The only restriction is that it should definitely not be the same serial number as your existing cert(and not the same as any other certs you use either, really).
<VIPs> - this is a comma-separated list of DNS names (can be IP addresses) of your VIPs. Basically, this option says "these names are valid matches for the hostname of the server too".
"-v" sets the expiration on the certificate in months. Set it to whatever you want.
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:
 
/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.
 
--
Philip Kime
NOPS Systems Architect
310 401 0407