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 [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
