roy liang via FreeIPA-users wrote: >> Hi, >> >> maybe you can explain first what you're trying to achieve. Do you want to >> install IPA without a CA? If it's a fresh installation, you can use >> ipa-server-install and provide the HTTP/LDAP/PKINIT certificates using the >> options --dirsrv-cert-file / --http-cert-file / --pkinit-cert-file / >> --dirsrv-pin / --http-pin / --pkinit-pin and provide the CA with >> --ca-cert-file. This way, you don't need to go through the painful steps of >> removing the CA functionality from IPA. >> For more information please refer to Determining What CA Configuration to >> Use [1], and Installing Without a CA [2]. >> I'm pointing to RHEL7 documentation as you mentioned you're using ipa 4.3 >> (which is a bit outdated...) >> >> The blog you're referring to clearly mentions that there is *no supported >> way to remove the CA from a CA-ful deployment*. The instructions are >> provided for you to try but are not officially supported. >> >> On Tue, Jul 5, 2022 at 1:31 PM roy liang via FreeIPA-users < >> freeipa-users(a)lists.fedorahosted.org> wrote: > > My goal is:Currently, all the HTTP LDAP certificates and PKI certificates > have expired in the freeipa cluster online, so they cannot work properly. I > have tested many schemes, but they cannot be fixed. I have also modified the > system time, but they cannot be fixed.My Linux Ubuntu16.04 FreeiPA 4.3 > version is very old. This is due to historical reasons. Now there is no > better choice.After all, there are a lot of Hadoop jobs running on this, any > good suggestions?Thank you very much
Take below with a grain of salt. There be dragons. I did not try this myself. What I'd suggest is you pick a different IPA server to start with. I think this Ubuntu host is a lost cause. IIRC you have several Fedora/CentOS/RHEL replicas as well. You want one without the CA on it. What I'm proposing is to start with an existing IPA server as a starting point and re-building the entire installation around it using 3rd party certificates, similar in principal to what you've tried but by using a different server you avoid the CA entirely. It will just disappear. With this there is no CA to remove, you just need to replace the certs and remove the few old IPA CA remnants that likely exist, and then try to get the clients to talk to it. I'd clone one and ensure it is disconnected from the network. This is extremely important as it is otherwise a completely valid IPA server so changes you make will get replicated around if you don't. Delete all replication agreements on it. Delete the other IPA server hosts. If IPA won't let you then you'll need to do it in LDAP. I'd start with the service entries, then remove the host entries. Personally I'd dump the database to LDIF and grep my way through it. Obtain server certs from a non-toy CA, otherwise your jumping from the frying pan into the fire. Let's Encrypt is an example of a non-toy. AD as well. You'll have to manually renew the certs periodically this way. ipa-cacert-manage to install the new CA chain. This may require rolling back time so your existing services can come up. ipa-certupdate to push the certs out. ipa-server-certinstall to replace the IPA-issued certificates. Return to current time and do some sanity testing locally. Run some ipa commands to see that they connect and return reasonable data. Check the output of getcert list. You'll want to stop-tracking on all the IPA-issued certs. At this point you should have a server running with working certs, your old data and no expired certificates. You'll still have remnants of the old CA to cleanup. You'll want to search LDAP for any userCertificates and remove any issued by the broken CA. Also remove the old IPA CA from cn=certificates,cn=ipa,cn=etc,$SUFFIX and run ipa-certupdate again to try to rid the system of it. Assuming I haven't missed anything, you have a working standalone IPA server with all your data in it. You are barely started at recovery at this point. Your existing clients won't trust this server, or heck, may not even know to try to contact it. If you don't want to uninstall and reinstall all of them, which could impact sudo and hbac rules among others, you'll need to manually install the new CA chain on them. How depends on the distribution. Google will tell you. Depending on how your clients discover the IPA server to contact you'll need to tweak that to point to this single solitary server. And check /etc/ipa/default.conf on all of them to ensure they point to it. I'd pick one client to start with and make sure it works. The further you get in the process the more committed you become and the more difficult it becomes to roll back. If a client works you can start adding additional IPA replicas. You'll need to provide all the certs at install time. There are a half dozen or so cli options needed. If everything seems to be working, you can decommission the other servers and point all the clients at the "new" set of IPA servers. The keytabs, user passwords, etc should all continue working fine as you're just dropping the CA. If you are using an IPA-issued certificates for other services you'll need to similarly replace those from your "new" external CA. It is probable that I've missed something. Troubleshooting something we've never done before will be difficult to do remotely. If you do need help then providing as much detail as possible is key: *exact* cli used, copy/paste output, etc will be required. Without details there is nothing to say and having to tease out what you're doing and seeing is not something I, or anyone else, is likely to do. rob _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
