Lukáš Bezdička wrote:
We were playing with rotating CA for FreeIPA as an DR procedure. I
wouldn't use this how to unless completely necessary as it will mean
many manual tasks on your infrastructure. But to know how it could be done:


This approach can work. It should be considered a last resort though. Ideally we can renew the CA certificate in-place using its existing private key and things will go a whole lot more smoothly. By re-installing you end up with a new CA but a whole bunch of corner cases.


1) ipa backup:
/var/lib/dirsrv/scripts-KOKOTINA/db2bak.pl  <http://db2bak.pl>  -v -D "cn=directory 
manager" -w -
Bind Password:
Back up directory: 
/var/lib/dirsrv/slapd-KOKOTINA/bak/KOKOTINA-2013_2_21_20_17_46
ldap_initialize( ldap://velka.kokotina:389 )
add objectclass:
        top
        extensibleObject
add cn:
        backup_2013_2_21_20_17_46
add nsArchiveDir:
        /var/lib/dirsrv/slapd-KOKOTINA/bak/KOKOTINA-2013_2_21_20_17_46
add nsDatabaseType:
        ldbm database
adding new entry "cn=backup_2013_2_21_20_17_46, cn=backup, cn=tasks, cn=config"
modify complete


2) copy backup elsewhere, reinstall FreeIPA with new CA


3) BACKUP:
cn=CAcert,cn=ipa,cn=etc,dc=kokotina from new CA

4) restore:
  /var/lib/dirsrv/scripts-KOKOTINA/bak2db.pl  <http://bak2db.pl>  -v -D 
"cn=directory manager" -a 
/var/lib/dirsrv/slapd-KOKOTINA/bak/KOKOTINA-2013_2_21_20_17_46/ -w -
Bind Password:
ldap_initialize( ldap://velka.kokotina:389 )
add objectclass:
        top
        extensibleObject
add cn:
        restore_2013_2_21_20_41_53
add nsArchiveDir:
        /var/lib/dirsrv/slapd-KOKOTINA/bak/KOKOTINA-2013_2_21_20_17_46/
add nsDatabaseType:
        ldbm database
adding new entry "cn=restore_2013_2_21_20_41_53, cn=restore, cn=tasks, 
cn=config"
modify complete

5) RESTORE:
cn=CAcert,cn=ipa,cn=etc,dc=kokotina from BACKUP of NEW CA

check logs:
less /var/log/dirsrv/slapd-KOKOTINA/errors






restart dirsrv:
service dirsrv restart

restart kdc:
/etc/init.d/krb5kdc restart

regen httpd keytab:
kadmin.local
ktadd -k /root/kokotina HTTP/velka.kokotina@KOKOTINA
mv kokotina /etc/httpd/conf/ipa.keytab

For all of these keytab refreshment you can use ipa-getkeytab here and bind using the DM password. It is a lot simpler than kadmin.

regen ldap keytab:
ktadd -k /root/kokot ldap/velka.kokotina@KOKOTINA
mv /root/kokot /etc/dirsrv/ds.keytab

regen host keytab:
ktadd -k /root/picka host/velka.kokotina@KOKOTINA
mv picka /etc/krb5.keytab

regen named keytab:
ktadd -k /root/oink DNS/velka.kokotina@KOKOTINA
mv oink /etc/named.keytab

resore rights:
chown dirsrv:dirsrv /etc/dirsrv/ds.keytab
chown apache:apache /etc/httpd/conf/ipa.keytab
chown httpd:httpd /etc/httpd/conf/ipa.keytab
chmod 600 /etc/dirsrv/ds.keytab
chmod 600 /etc/httpd/conf/ipa.keytab
chmod 400 /etc/named.keytab
restorecon -Rv /etc/


I have note about this procedure that we had issue with httpd and it was
solved with:
service httpd stop; rm /etc/httpd/conf/ipa.keytab ; ipa-getkeytab ...
/etc/httpd/conf/ipa.keytab ; chmod .. ; sudo -u apache /bin/bash ;
kdestroy ; exit ; service httpd restart

This works ok for a single IPA installation but once you start adding in replication it gets tricky. I've done these basic steps myself to replace a CA

The other part that's missing is any hosts or certificates issued by the old CA. Right now in order to delete or replace a certificate we MUST revoke the old one. That will fail because the new CA won't know anything about the old certs, so you'll need to find any and delete them.

Any non-IPA services (and IPA clients) with a cert will need to manually delete and request a new one. Anyone who has visited the old site with a browser will be unhappy too as there is now a new cert with the same subject and serial and different key.

I wrote similar, though less detailed, steps in the Development notes section in http://www.freeipa.org/page/V3/Backup_and_Restore

regards

rob

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to