[Freeipa-users] Replacing CA Certificate

[Rob Crittenden]

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 at 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 at KOKOTINA
> mv /root/kokot /etc/dirsrv/ds.keytab
>
> regen host keytab:
> ktadd -k /root/picka host/velka.kokotina at KOKOTINA
> mv picka /etc/krb5.keytab
>
> regen named keytab:
> ktadd -k /root/oink DNS/velka.kokotina at 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