Hi Rob, Thank you for your answer. Assuming the ipa-migration path to a new CA, will it be possible to keep and subordinate the existent Dogtag Sub-CAs (subordinated to the previous CA) to this new CA, at least for a gradual transition?
Best regards, Nelson On Fri, 4 Apr 2025 at 14:21, Rob Crittenden <[email protected]> wrote: > 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
