Hi Rob, Thanks for your help. There are three servers, we use a third-party CA, and the CA certificate is installed on the IPA servers, but as far as I know our IPA install is not configured to act as a CA itself. Setting the time back did not change the system behavior.
The issue ended up being an incorrect private key. I installed the correct private key for the new certificate and was able to start and log in normally. I thought that the private key for the prior cert was unchanged (as was the case for other servers in my system), but this one appears to have used a different, encrypted private key previously. Thanks again, Toma On Mon, Jul 1, 2024 at 4:48 PM Rob Crittenden <rcrit...@redhat.com> wrote: > Toma Morris via FreeIPA-users wrote: > > ## Problem and version info > > > > I recently took over as the sysadmin for a system that was previously > set up, and has not had a sysadmin for 6+ months, plus appears to have been > fairly neglected even before then. It has three FreeIPA nodes that have not > seen a system update in several years, and CentOS can no longer be updated > so I cannot update them. I'm planning to replace them but have not created > the replacements yet and need the current system to continue functioning, > both in general and also in order to enroll new nodes and replicate to them > before bringing down the old ones. > > > > ``` > > $ ipa --version > > VERSION: 4.9.6, API_VERSION: 2.245 > > $ lsb_release -a > > LSB Version: :core-4.1-amd64:core-4.1-noarch > > Distributor ID: Fedora > > Description: Fedora release 34 (Thirty Four) > > Release: 34 > > Codename: ThirtyFour > > ``` > > > > I have been working my way through system updates and improvements, but > had not checked the expiration dates on the server certificates yet, and > the certificates expired on June 21. I saw this and got a new (wildcard, as > before) certificate and began replacing them. I'm new to FreeIPA and had > only used it to add a handful of users and set a few DNS entries. I > bypassed the certificate error in the browser to go to the FreeIPA web UI ( > https://freeipa1.mydomain.com/ipa/ui/#), and tried to log in and got the > error message "Login failed due to an unknown reason". I am certain of my > password. > > > > I saw that it runs httpd, so I copied the new cert onto the server and > changed the httpd config to point to it and the appropriate key. Now, when > I navigate to the web UI I no longer get a certificate error, but I > continue to get the same error message when I try to log in. > > > > FreeIPA appears to be working partially, because it governs `sudo` > access and login within this system and I am still able to login and > `sudo`. When I try to use any `ipa` commands, however, I get the following > or something similar: > > > > ``` > > $ sudo ipa-certupdate > > Connection to https://freeipa1.mydomain.com/ipa/json failed with [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local > issuer certificate (_ssl.c:1129) > > Connection to https://freeipa2.mydomain.com/ipa/json failed with [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local > issuer certificate (_ssl.c:1129) > > Connection to https://freeipa3.mydomain.com/ipa/json failed with [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local > issuer certificate (_ssl.c:1129) > > cannot connect to 'any of the configured servers': > https://freeipa1.mydomain.com/ipa/json, > https://freeipa2.mydomain.com/ipa/json, > https://freeipa3.mydomain.com/ipa/json > > The ipa-certupdate command failed. > > ``` > > You replaced the certificate(s) with one from an issuer untrusted by the > system. > > > and > > > > ``` > > $ ipa user-find > > ipa: ERROR: cannot connect to 'any of the configured servers': > https://freeipa1.mydomain.com/ipa/json, > https://freeipa2.mydomain.com/ipa/json, > https://freeipa3.mydomain.com/ipa/json > > ``` > > > > I am able to get correct responses from `id [username]` and `getent > passwd [username]`, and am able to `kinit`, `ssh`, and `sudo` using > credentials that are governed by these servers. > > > > ## What I have tried > > > > - I replaced the old certificate in the httpd config with a new one that > is essentially the same except it has an updated valid date window, and is > signed with RSA384 instead of RSA356 (I don't think this matters, but > including for completeness), and then restarted httpd > > Do you have a CA configured in this topology? How many servers? > > > - I did `ipactl restart` and `systemctl restart sssd` > > - I put the old certificate back in place, disabled NTP on the server > and set the time back to a date when the prior certificate was valid > > And then what? Did things work? > > > - I have looked through sssd_* and /var/log/secure for relevant logs. I > found one at /var/log/sssd/sssd_mydomain.com.log, with error logs that > appear relevant, but I'm not able to tell what is not working. I have not > found other relevant-looking entries in other sssd logs > > - `dig -t SRV _ldap._tcp.freeipa1.mydomain.com @127.0.0.1` from the > freeipa1 terminal gave a reasonable response > > > > I also tried an ldapsearch that had worked previously: > > > > ``` > > $ ldapsearch -x -b "dc=mydomain,dc=com" -H ldap://freeipa1.mydomain.com > -D "cn=admin,dc=mydomain,dc=com" -W > > Enter LDAP Password: > > ldap_bind: Invalid credentials (49) > > ``` > > You used the wrong DN. It is > uid=admin,cn=users,cn=accounts,dc=mydomain,dc=com > > And this won't exercise TLS which is the root of the problem. But being > able to use LDAP will give you more information on the installation if > necessary. > > > > > ## Logs > > > > Here is a snippet from a very large log file from freeipa3.mydomain.com: > /var/log/sssd/sssd_mydomain.com.log. I elided portions that seem to be > generic, and kept lines that mention mydomain.com and what appears to be > related context. It's possible I elided something important, and can > provide unelided logs or specific portions if needed. There are 3 > backtraces here, the first is long and elided and the last two are short > and included in full. I notice the conspicuous "Network is unreachable" > messages, and checked to confirm that I am able to ping all three servers > from everywhere in the network (including from these servers themselves), > so I don't believe it is actually a network outage. > > > This is a server-side problem. The client is in this case is unrelated. > > rob > >
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
