N. V. via FreeIPA-users wrote: > Hi Fraser, Florence, > > Thank you for the link (and the blog). We tried following those > instructions, but unfortunately, using that approach results in the loss > of all configurations linked to the CA, which is not exactly what we need. > To provide more context, we are currently analysing the following > scenarios to meet our customer’s requirements: > > * Rekeying the Root CA – This is mandatory, even if it requires an > unsupported manual process. > * Transferring PKI Ownership to Third Parties – This involves > introducing an external CA to sign FreeIPA’s root CA (whether > externally or internally self-signed) and eventually rekeying > FreeIPA's CA. > * Deployment at Scale – The eventual solution will be rolled out > across several hundred OT sites, with licensed support being considered. > > We are currently exploring the possibility of manually replacing the CA > and all internal certificates, but we are encountering challenges. Is > this a viable approach? One of our attempts involved using Certmonger’s > rekey feature to rekey the root CA. This generated a new CA certificate, > which was then used for issuing new certificates and even for the CRL. > However, this process did not update internal certificates > automatically, and attempting to manually resubmit them led to failures. > > Another approach we tested was manually replacing the CA certificate in > the NSS DB and LDAP, followed by manually triggering Certmonger’s renew > feature to propagate the new CA. However, this process also eventually > failed. We are now attempting a full manual replacement of all > certificates but we are loosing faith ... > > If we cannot successfully address these challenges, we may need to > explore alternative solutions in the market. Given your expertise, do > you see a viable path forward for this manual replacement, or is this > approach fundamentally flawed? > > Looking forward to your insights.
I've never played with re-keying a CA but it is fundamentally a bootstrapping issue. Re-keying is creating an identically named CA with a new private key. So you'll have two valid CA's with the same name. This is why when you re-key the CA some certs don't work: because the chain is broken. If you are running IPA 4.12+ you may have the ipa-migrate tool. This will allow you to stand up a brand new IPA server (with its own CA) and migrate all of your IPA data from the existing one to this new one. That would allow you to set whatever new parameters you need. I assume you want/need a larger key size? This is also obviously disruptive as you will need to re-enroll all of your clients, stand up new IPA replica servers, re-issue any manual certificates, etc. But much of that you'd have to do anyway with a re-key. It's basically an inventory problem to find all the enrolled systems and those with certificates so you know which ones to change. Note that user passwords will be maintained but Kerberos principal keys will not. And by definition no certificates will be migrated. So your users will need to authenticate via the migration web page (/ipa/ui/migrate IIRC) and/or SSSD will do this for you. This is in the migration documentation. rob > > On Fri, 7 Feb 2025 at 18:59, Fraser Tweedale <[email protected] > <mailto:[email protected]>> wrote: > > On Fri, Feb 07, 2025 at 08:44:52AM +0000, N. V. via FreeIPA-users wrote: > > Hi again, > > > > So, if re-keying is not supported, what is the process that is > recommended > > for the cases where for instance the root keys are compromised? Is > this > > limitation also valid in the case when the root CA is external? > > > > Thanks, > > Nelson V. > > > Hi Nelson, > > Very unsupported and the instructions may be a little stale now > (post is from 2019, Fedora 30), but this article walks through how > to completely remove the CA from a FreeIPA deployment. From there, > you can create a new CA via `ipa-ca-install`. > > > https://frasertweedale.github.io/blog-redhat/posts/2019-10-24-removing-ipa-ca.html > > Hope it helps, > Fraser > > > On Thu, 6 Feb 2025 at 12:41, Florence Blanc-Renaud <[email protected] > <mailto:[email protected]>> wrote: > > > > > Hi, > > > > > > On Thu, Feb 6, 2025 at 12:18 PM N. V. via FreeIPA-users < > > > [email protected] > <mailto:[email protected]>> wrote: > > > > > >> Hi, > > >> > > >> In our FreeIPA deployment we need to find a way to rekey the > self-signed > > >> root CA and afterwards update the chain and the certificates > all the way > > >> down. I have been unable to find detailed instructions in the > official > > >> documentation or through my own research, so I am reaching out > for guidance. > > >> > > >> Could someone please provide instructions or point me to any > relevant > > >> resources on how to properly rekey the self-signed root CA in > FreeIPA? Any > > >> advice, tips, or potential pitfalls to avoid during this > process would be > > >> greatly appreciated. > > >> > > > > > > Unfortunately we don't have any solution yet for this type of > request. > > > Please read more in *Bug 1873696* > > > <https://bugzilla.redhat.com/show_bug.cgi?id=1873696> - [RFE] > Need an > > > option to replace the root CA key with another key with 3072 bits > > > > > > It would require to cross-sign the old CA with the new one but > we never > > > managed to find time to investigate this possibility. > > > flo > > > > > >> Thank you in advance for your assistance! > > >> > > >> Nelson V. > > >> -- > > >> _______________________________________________ > > >> FreeIPA-users mailing list -- > [email protected] > <mailto:[email protected]> > > >> To unsubscribe send an email to > > >> [email protected] > <mailto:[email protected]> > > >> Fedora Code of Conduct: > > >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > >> List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > >> List Archives: > > >> > > https://lists.fedorahosted.org/archives/list/[email protected] > > >> Do not reply to spam, report it: > > >> https://pagure.io/fedora-infrastructure/new_issue > > >> > > > > > > -- > > _______________________________________________ > > FreeIPA-users mailing list -- [email protected] > <mailto:[email protected]> > > To unsubscribe send an email to > [email protected] > <mailto:[email protected]> > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedorahosted.org/archives/list/[email protected] > > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > > -- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
