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
