Hi, On Fri, Sep 22, 2023 at 12:36 PM Cristian Le <[email protected]> wrote:
> Hi Florence, > > Thanks for the feedback, let me clarify the situation on the certificates: > - External CA is still valid and it is a self-signed certificate that we > use for other services. So we can manually sign any service certificates to > get them back up and running > - IPA CA is expired, let's say Aug/10 > - I have managed to import a renewed IPA CA and ran `ipa-cert-fix` (and > also seemed to have run `ipa-certupdate`) on a current date, let's say > Sep/20. But not all services were recovered and now there is no overlap > between earliest date in service certificates and the original IPA CA > Which are the not-recovered services? Can you provide the output of "getcert list" at the current date? flo > - I have run a backup, but also did some system upgrades to get the > `ipa-cacert-manage prune` command, but when I've tried to recover it, I've > found that the backup was not there. > > > you can still find the original certificates in the LDAP database > (below ou=certificateRepository,ou=ca,o=ipaca) but it requires a bit of > searching. You would need to restore the expired certificates, go back in > time and force the renewal. > > I suspect we cannot do this all within LDAP right? If we get back the > expired certificates, how do we restore them in each service? `httpd` is > straightforward, and I guess `nssdb` should be doable, assuming the same > key is used, but is there another database type where the certificates are > located? Are all the certificates tracked by `getcert list`? Is it safe to > assume that after running something like `ipa-cert-fix`, they are using the > same private key? > > Some symptoms in the current setup: > - When we are forward in time, `pki-tomcatd` is able to run, but then I > can't do any `ipa-cert-fix` or `ipa-cacert-manage renew`. From what I've > read, all of these commands (or at least `ipa-cacert-manage renew`) must be > done backwards in time. > - When we are backwards in time `pki-tomcatd` is unable to run, failing to > access `:8080/ca/admin/ca/getStatus`. This then blocks various other > services to be run. But about `ipactl restart`, only `pki-tomcatd` service > is actually failing (and ipa service itself of course). > > I have navigated to `ou=certificateRepository,ou=ca,o=ipaca` and indeed > there are still a bunch of certificates there in linear order. What are the > services I should look for in there? I am using Apache Directory Studio and > I can download the `userCertificate`. Should I just run `certutil -A` with > those values with corresponding `subjectName`? > > BTW, I want to document this process on the website, should I make a PR on > the github repo or is there somewhere else? > > Kind regards, > Cristian > On 2023/09/22 9:00, Florence Blanc-Renaud wrote: > > Hi, > > On Thu, Sep 21, 2023 at 5:04 PM Cristian Le via FreeIPA-users < > [email protected]> wrote: > >> I have tried my luck around with all the helpers: `pki-server cert-fix`, >> `ipa-cacert-manage`, `ipa-certupdate`, etc. but each one is failing on me >> for multiple reasons. >> - `ipa-cacert-manage` Cannot update the CA with `--external-cert-file` >> because the root ca is not detected to be in the trust list >> > This command is useful if you need to trust a new external CA or renew IPA > CA. Is your IPA CA expired? > > - `ipa-cert-fix` Was run without overlapping validity time, and the >> certificate were re-created, so now it is not recoverable, neither back in >> time, nor in current time >> > It is recommended to do a backup before running ipa-cert-fix. If you > didn't, and want to try the back-in-time method, you can still find the > original certificates in the LDAP database (below > ou=certificateRepository,ou=ca,o=ipaca) but it requires a bit of searching. > You would need to restore the expired certificates, go back in time and > force the renewal. > > - `pki-tomcat` is failing >> >> What is the current situation? Which certs are expired (getcert list)? If > you start the services with "ipactl start --ignore-service-failures", is > pki-tomcat the only service failing? > flo > > It is quite a mess and I would like to ask for some guidance on how one >> could recover manually from such dependency issues: >> - Is it possible to do a `ipa-server-install` and keep the user data? >> > - If I sign all of the service's certificates manually, what are all of >> the manual steps needed to get the services back up so that the helpers can >> be run. >> - I've tried to install the CA certificate in the nssdb database, ldap, >> and /etc/ipa/ca.crt. Are there other locations? >> - I've recreated an httpd certificate signed by the root, but I can't >> figure how to do the same with the ones located in the nssdb database, i.e. >> to recreate a csr with the same data as one of the certificates there >> - What is the order of services that should be updated. My understanding >> is CA -> `certutil`'s CA -> httpd + slapd + pki-tomcat (not sure where the >> last one is or how to edit it) -> `ipa-certupdate` >> _______________________________________________ >> 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 >> >
_______________________________________________ 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
