Seems like it works now, almost perfectly.

I was able to get ipa-ca-install to run using an old replica package file 
(replica-info-xxx.gpg), by hacking the script to disable a check for existing 
CA, and by deleting things left over from the failed installation:
- Certs in /etc/httpd/alias and another location using:
certutil -d /etc/httpd/alias -D  "REALM_NAME IPA CA"
certutil -d /etc/httpd/alias -D  ipaCert

- The PKI instance: pkidestroy -s CA -i pki-tomcat
- Dogtag tracking requests: from the date of CA installation.

The command failed when trying to replicate to LDAP because the configuration 
files in /etc/ipa/default.conf. Step 26, migrating certificate profiles to LDAP 
stopped. I then edited /etc/ipa/default.conf so that ca_host points to the 
current host (this was pointing to the old CA host). This made the installation 
script significantly faster, and it completed all 30 steps. It did however 
produce an error about "subject public key info mismatch" for the cert named 
"REALM_NAME IPA CA". (REALM_NAME is the name of the domain in all caps).

Then most things worked, even: # ipa-cacert-manage renew

Couldn't join new clients, as it was downloading the old CA cert from LDAP (I 
had just renewed it). I updated the CA cert in LDAP under "REALM, etc, ipa, 
certificates, REALM IPA CA" by deleting it and calling 
certstore.put_ca_cert_nss in a similar way that was done in 
/usr/lb/python2.7/site-packages/ipaserver/install/ (when I tried to 
update the cert, not delete if first, I got Subject public key mismatch error, 
exactly same as after the CA installation!)

I could then successfully enroll the other server as clients, then promoted one 
to a master, then installed the CA on that one too. The CA installation 
completed, but step 15 "Failed to restart the dogtag instance". I don't think 
it looks good that my primary master only has "managed suffixes" = domain, and 
the secondary one has domain and ca, in the Web UI, but I will leave it. 
Everything works well now.

I realise that FreeIPA is a complex piece of software, which has been developed 
intensely over the last years, but I really hope that going forward it could 
become more stable, and that upgrading to the next RHEL version from 7 will be 
less of a nightmare. 


> 3. mai 2017 kl. 17.26 skrev Marius Bjørnstad <>:
> Hi,
> I have migrated some FreeIPA servers from 3.0.0-51 to 4.4.0-14 by adding new 
> replicas. There were a lot of issues, and I'm strugglig a bit with a 
> configuration management system set up by a central IT department, which 
> overrides files like sssd.conf, and I have to make exceptions to the policy. 
> I hope someone could take the time to help me with this anyway.
> I was able to join both new RHEL 7 machines, and remove one of the old RHEL 6 
> machines, but then I couldn't remove the last one, and couldn't install the 
> CA on any of the new masters. I (perhaps stupidly) removed the old server 
> using ldapdelete, based on this thread: 
> I 
> thought that if I could get rid of the old stuff, I may be able to 
> successfully promote one of the new servers to CA master. The command to 
> install the CA almost completed successfully on the first master, but stopped 
> on one of the last steps.
> Now I get:
> # ipa-ca-install
> CA is already installed on this host.
> It is clear that the CA is not installed. I get errors in 
> /var/log/httpd/error_log for hosts requesting certs, and getting NotFound.
> ipa: INFO: [xmlserver] host/xxxxx@DOMAIN: cert_request(u'MIIDnzCCaoc.......
> I then removed and uninstalled the other master, which did not have a CA, 
> thinking it could get going with a reinstall. However, the installation fails
> ipa     : ERROR      Cannot issue certificates: a CA is not installed. Use 
> the --http-cert-file, --dirsrv-cert-file options to provide custom 
> certificates.
> (there may be some typos in the error messages, since I'm copying from an 
> air-gapped network)
> Is there any way I can manually resurrect the CA? I have the files left over 
> on the original (version 3) master, but did do an uninstall. If that's not 
> possible, is there any way to migrate the users to a new domain with exactly 
> the same name (this would be less convenient, if it's actually possible, 
> since I have to re-enroll all the clients).
> Thanks,
> Marius Bjørnstad

Manage your subscription for the Freeipa-users mailing list:
Go to for more info on the project

Reply via email to