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
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.
<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"
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
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
