[Freeipa-users] Free-IPA to RHEL IPA: ipa-crlgen-manage not present, manual options
Greetings! Can the actions within the two commands below can be done manually (outside the RPM)? ipa-crlgen-manage status ipa-crlgen-manage disable Context: I inherited an old Centos IPA cluster, centered on VMs. Suboptimal, given that the VM datastore itself is NFS-shared. Bare metal hardware is in place, running RHEL IPA. The "ipa-crlgen-manage" is actually not present on the running ipa-server-4.X) but is on a later version. Yes, I could run "yum update" and restart; but this VM can't go down until 1) offloading the last crucial functions to the bare metal 2) removing it from topology. There is limited opportunity to confirm things don't break after that update. Thanks for any leads. ___ 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
[Freeipa-users] Re: ipa migrate-ds - From EL7 to EL8/9
Hi, if you want to install a RHEL8 or RHEL9 server with the same domain name, the recommended procedure would be to install a RHEL8 replica from your RHEL7 server, then a RHEL9 replica from your RHEL8 server. You can check this documentation: - Migrating your IdM environment from RHEL 7 servers to RHEL 8 servers [1] - Migrating your IdM environment from RHEL 8 servers to RHEL 9 servers [2] ipa migrate-ds is used when the new domain name is different from the old one and does not migrate all the data (only users and groups are migrated, not HBAC rules, sudo rules etc...). On the contrary, installation of a replica does not lose any data. And you don't need to worry about the SIDs. HTH, flo [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/migrating_to_identity_management_on_rhel_8/migrate-7-to-8_migrating [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/migrating_to_identity_management_on_rhel_9/assembly_migrating-your-idm-environment-from-rhel-8-servers-to-rhel-9-servers_migrating-to-idm-on-rhel-9 On Tue, May 9, 2023 at 2:35 PM Finn Fysj via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote: > Planning to migrate users and groups from an old dusty IPA server running > Red Hat Enterprise Linux 7 to RHEL9. > I'm aware of SID issues from following thread: > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/MO63NXS63KSI6QJMZRN6JK32VUGKEICH/ > > Should I ignore the attribute `ipaNTSecurityIdentifier` when migrating > from old to new instance? > ___ > 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 > ___ 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
[Freeipa-users] Re: Yum-based upgrade causes group lookup failures.
Hi, if you are comfortable with 389-ds access log, you can check which search rundeck is performing and try to reproduce manually. I would start with the working one: in /var/log/dirsrv/slapd-MY-DOMAIN-DOM/access, look for a line showing the operations done with the working user uid=$userID,cn=users,cn=accounts,dc=my,dc=domain,dc=com (look for a line containing *BIND dn="uid=$userID"*, for instance: # grep 'BIND dn="uid=testuser' /var/log/dirsrv/slapd-IPA-TEST/access [09/May/2023:14:02:19.721498412 +] *conn=58634* op=0 BIND dn="uid=test user,cn=users,cn=accounts,dc=ipa,dc=test" method=128 version=3 Note the *conn* number and try to find all the operations performed with this connection: # grep conn=58634 /var/log/dirsrv/slapd-IPA-TEST/access [09/May/2023:14:02:19.702570402 +] conn=58634 fd=162 slot=162 SSL connection from 10.0.144.249 to 10.0.144.249 [09/May/2023:14:02:19.709587570 +] conn=58634 TLS1.3 128-bit AES-GCM [09/May/2023:14:02:19.721498412 +] conn=58634 op=0 BIND dn="uid=testuser,cn=users,cn=accounts,dc=ipa,dc=test" method=128 version=3 [09/May/2023:14:02:19.742183857 +] conn=58634 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.015180938 optime=0.020691034 etime=0.035869230 dn="uid=testuser,cn=users,cn=accounts,dc=ipa,dc=test" *[09/May/2023:14:02:19.742532170 +] conn=58634 op=1 SRCH base="cn=groups,cn=compat,dc=ipa,dc=test" scope=2 filter="(objectClass=posixgroup)" attrs="memberUid"* [09/May/2023:14:02:19.757048401 +] conn=58634 op=1 RESULT err=0 tag=101 *nentries=26* wtime=0.000154146 optime=0.014517504 etime=0.014669869 [09/May/2023:14:02:19.757131659 +] conn=58634 op=2 UNBIND [09/May/2023:14:02:19.763351173 +] conn=58634 op=2 fd=162 closed error - U1 In my example I can see that there was a SEARCH with base *cn=groups,cn=compat,dc=ipa,dc=test*, scope=2 (meaning sub) and filter (objectClass=posixgroup), that asked for the attribute memberuid and found 26 entries. Once you identify the exact operations it should be easier to understand which ACIs apply and prevent from finding the groups. HTH, flo On Tue, May 9, 2023 at 4:21 PM Jeff Goddard wrote: > Not that I can see: > > Permission name: System: Read Group Compat Tree > Granted rights: read, compare, search > Effective attributes: cn, createtimestamp, entryusn, gidnumber, > memberuid, modifytimestamp, objectclass > Default attributes: objectclass, memberuid, gidnumber, cn > Bind rule type: anonymous > Subtree: dc=my,dc=domain,dc=com > Target DN: cn=groups,cn=compat,dc=my,dc=domain,dc=com > Permission flags: V2, MANAGED, SYSTEM > > Jeff > > On Tue, May 9, 2023 at 10:14 AM Florence Blanc-Renaud > wrote: > >> Hi, >> >> on a standard installation, the compat tree groups should be readable by >> anyone thanks to the permissions "System: Read Group Compat Tree". >> # ipa permission-show "System: Read Group Compat Tree" >> Permission name: System: Read Group Compat Tree >> Granted rights: read, search, compare >> Effective attributes: cn, createtimestamp, entryusn, gidnumber, >> memberuid, modifytimestamp, objectclass >> Default attributes: memberuid, gidnumber, objectclass, cn >> Bind rule type: anonymous >> Subtree: dc=ipa,dc=test >> Target DN: cn=groups,cn=compat,dc=ipa,dc=test >> Permission flags: SYSTEM, V2, MANAGED >> >> Was this permission modified on your system? >> >> flo >> >> On Tue, May 9, 2023 at 2:57 PM Jeff Goddard >> wrote: >> >>> >>> Flo, >>> >>> Thank you for giving me a pointer. It helped me better design a test >>> scenario where I now can get success but I'm still looking to improve >>> things. Our lookup configuration uses a system account. If I make the >>> changes you suggest, I still see errors/no populated user groups. However >>> if I switch the lookup user DN in the config to a "regular" user DN and >>> have the groups lookups configured to use the compat tree, I now populate >>> groups as expected. Does this mean I have an access permissions issue with >>> my service account? Do you have any suggestions on how I can get the >>> service account to work again? >>> >>> Non-working lookup DN config snippets: >>> >>> bindDn="uid=$system_account,cn=sysaccounts,cn=etc,dc=my,dc=domain,dc=com" >>> bindPassword="$password" >>> >>> Working lookup DN config snippets: >>> bindDn="uid=$userID,cn=users,cn=accounts,dc=my,dc=domain,dc=com" >>> bindPassword="$password" >>> >>> In both cases above this is used as the group DN: >>> roleBaseDn="cn=groups,cn=compat,dc=my,dc=domain,dc=com >>> >>> Your assistance is greatly appreciated, >>> >>> Jeff >>> >>> >>> >>> >>> >>> On Tue, May 9, 2023 at 3:32 AM Florence Blanc-Renaud >>> wrote: >>> Hi, I am not familiar with rundeck but from the provided configuration, the application is using the *memberUid* attribute. IPA stores its groups with the member attribute, not memberUid, unless you are using the compat tree. The compat tree is stored below cn=compat,$BASEDN and provides a virtual
[Freeipa-users] Re: Yum-based upgrade causes group lookup failures.
Not that I can see: Permission name: System: Read Group Compat Tree Granted rights: read, compare, search Effective attributes: cn, createtimestamp, entryusn, gidnumber, memberuid, modifytimestamp, objectclass Default attributes: objectclass, memberuid, gidnumber, cn Bind rule type: anonymous Subtree: dc=my,dc=domain,dc=com Target DN: cn=groups,cn=compat,dc=my,dc=domain,dc=com Permission flags: V2, MANAGED, SYSTEM Jeff On Tue, May 9, 2023 at 10:14 AM Florence Blanc-Renaud wrote: > Hi, > > on a standard installation, the compat tree groups should be readable by > anyone thanks to the permissions "System: Read Group Compat Tree". > # ipa permission-show "System: Read Group Compat Tree" > Permission name: System: Read Group Compat Tree > Granted rights: read, search, compare > Effective attributes: cn, createtimestamp, entryusn, gidnumber, > memberuid, modifytimestamp, objectclass > Default attributes: memberuid, gidnumber, objectclass, cn > Bind rule type: anonymous > Subtree: dc=ipa,dc=test > Target DN: cn=groups,cn=compat,dc=ipa,dc=test > Permission flags: SYSTEM, V2, MANAGED > > Was this permission modified on your system? > > flo > > On Tue, May 9, 2023 at 2:57 PM Jeff Goddard wrote: > >> >> Flo, >> >> Thank you for giving me a pointer. It helped me better design a test >> scenario where I now can get success but I'm still looking to improve >> things. Our lookup configuration uses a system account. If I make the >> changes you suggest, I still see errors/no populated user groups. However >> if I switch the lookup user DN in the config to a "regular" user DN and >> have the groups lookups configured to use the compat tree, I now populate >> groups as expected. Does this mean I have an access permissions issue with >> my service account? Do you have any suggestions on how I can get the >> service account to work again? >> >> Non-working lookup DN config snippets: >> bindDn="uid=$system_account,cn=sysaccounts,cn=etc,dc=my,dc=domain,dc=com" >> bindPassword="$password" >> >> Working lookup DN config snippets: >> bindDn="uid=$userID,cn=users,cn=accounts,dc=my,dc=domain,dc=com" >> bindPassword="$password" >> >> In both cases above this is used as the group DN: >> roleBaseDn="cn=groups,cn=compat,dc=my,dc=domain,dc=com >> >> Your assistance is greatly appreciated, >> >> Jeff >> >> >> >> >> >> On Tue, May 9, 2023 at 3:32 AM Florence Blanc-Renaud >> wrote: >> >>> Hi, >>> I am not familiar with rundeck but from the provided configuration, the >>> application is using the *memberUid* attribute. IPA stores its groups >>> with the member attribute, not memberUid, unless you are using the compat >>> tree. The compat tree is stored below cn=compat,$BASEDN and provides a >>> virtual view following RFC 2307 instead of RFC 2307bis. For instance: >>> *IPA group entry* >>> $ ldapsearch -LLL -o ldif-wrap=no -D cn=directory\ manager -w $PASSWORD >>> -b cn=mygroup,cn=groups,*cn=accounts*,dc=ipa,dc=test >>> dn: cn=mygroup,cn=groups,cn=accounts,dc=ipa,dc=test >>> cn: mygroup >>> objectClass: top >>> objectClass: nestedgroup >>> objectClass: ipausergroup >>> objectClass: ipaobject >>> objectClass: groupofnames >>> objectClass: posixgroup >>> objectClass: ipantgroupattrs >>> ipaUniqueID: ff523b2a-ee38-11ed-8374-fa163eaf69aa >>> gidNumber: 205400095 >>> ipaNTSecurityIdentifier: S-1-5-21-1166032515-3431855665-2561613534-1095 >>> *member: uid=idmuser,cn=users,cn=accounts,dc=ipa,dc=test* >>> >>> *IPA Group entry in the compat tree* >>> $ ldapsearch -LLL -o ldif-wrap=no -D cn=directory\ manager -w $PASSWORD >>> -b cn=mygroup,cn=groups,*cn=compat*,dc=ipa,dc=test >>> dn: cn=mygroup,cn=groups,cn=compat,dc=ipa,dc=test >>> objectClass: posixGroup >>> objectClass: ipaOverrideTarget >>> objectClass: ipaexternalgroup >>> objectClass: top >>> gidNumber: 205400095 >>> *memberUid: idmuser* >>> ipaAnchorUUID:: >>> OklQQTppcGEudGVzdDpmZjUyM2IyYS1lZTM4LTExZWQtODM3NC1mYTE2M2VhZjY5YWE= >>> cn: mygroup >>> >>> There were some changes in the compat tree with slapi-nis-0.60.0-1 that >>> may explain the different behavior. You can try to use the compat tree for >>> the groups (replace >>> *roleBaseDn="cn=groups,cn=accounts,dc=my,dc=domain,dc=com"* with >>> *roleBaseDn="cn=groups,cn=compat,dc=my,dc=domain,dc=com"*) to make sure >>> the right schema is used. >>> >>> flo >>> >>> On Mon, May 8, 2023 at 3:06 PM Jeff Goddard via FreeIPA-users < >>> freeipa-users@lists.fedorahosted.org> wrote: >>> Hello and thank you for providing such a useful product. We recently used yum to update our freeipa infrastructure and everything went off without a hitch with the exception of one of our integrated apps which now cannot determine group membership. We know the lookup is successful as the user can login but we use group-based ACLs from freeipa and when the groups are not populated, the users cannot access the rundeck jobs. Nothing on rundeck was changed, the only actions taken
[Freeipa-users] Re: SSL errors ... again
Hi, On Tue, May 9, 2023 at 1:24 PM Justin Sanderson via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote: > > Hey Flo - thanks so much for your willingness to help. > > > My setup is just a single VM server. I will give it a try tonight once > everyone has gone home for the day. > > Also, does it make sense to have certmonger monitor this cert? I found > a command on the RH access portal that shows how to add it to certmonger > but I had doubts about whether it would update LDAP when the cert got > renewed... > > By default the cert should already be tracked by certmonger. If you run > *getcert list*,you should see it in the list of tracked certs. For instance on my system: # getcert list -f /var/lib/ipa/ra-agent.pem Number of certificates and requests being tracked: 12. Request ID '20230324140132': status: MONITORING stuck: no key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key' certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=IPA.TEST subject: CN=IPA RA,O=IPA.TEST issued: 2022-05-31 12:32:55 UTC expires: 2024-05-20 12:32:55 UTC key usage: digitalSignature,keyEncipherment,dataEncipherment eku: id-kp-clientAuth profile: caSubsystemCert pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes With a single server (that is the renewal master), certmonger renewal should put the new cert directly in the file /var/lib/ipa/ra-agent.pem (and then later in LDAP but that's not relevant in this case). flo > > Thanks again for the help and i'll report back the result tonight. > ___ > 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 > ___ 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
[Freeipa-users] ipa migrate-ds - From EL7 to EL8/9
Planning to migrate users and groups from an old dusty IPA server running Red Hat Enterprise Linux 7 to RHEL9. I'm aware of SID issues from following thread: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/MO63NXS63KSI6QJMZRN6JK32VUGKEICH/ Should I ignore the attribute `ipaNTSecurityIdentifier` when migrating from old to new instance? ___ 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
[Freeipa-users] Re: SSL errors ... again
Hey Flo - thanks so much for your willingness to help. My setup is just a single VM server. I will give it a try tonight once everyone has gone home for the day. Also, does it make sense to have certmonger monitor this cert? I found a command on the RH access portal that shows how to add it to certmonger but I had doubts about whether it would update LDAP when the cert got renewed... Thanks again for the help and i'll report back the result tonight. ___ 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
[Freeipa-users] Re: Help with Ghost Replica removal please.
Just an update on this.
Came back from the long weekend and 50% of our servers (3) were not responding,
the dirsrv was crashing everytime it had an update from the CA master (we could
not figure out why). If we closed the firewall between replica and CA master
the servers stayed up.
After a few days of trying various things to resurrect the down servers we
rebuilt the whole cluster based off the master CA server. None of the original
servers are now present.
After another long weekend we seem (so far) to have a stable cluster. Ignoring
the usual replication conflicts we get with heavy server creation/deletion due
to AWS spot instances.
The only out standing item now is the records that make "cipa" think we have
"ghost replicas"
nsruvReplicaLastModified: {replica 25}
nsruvReplicaLastModified: {replica 23}
nsruvReplicaLastModified: {replica 40}
nsruvReplicaLastModified: {replica 21}
There are no RUVs to match these replicas (21,23, 25, 40).
So it looks like these key/value pairs are the only things left.
Any ideas on how to remove them?
Many thanks.
___
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
[Freeipa-users] Re: IPA installation and SSHD configuration - What is being configured?
> J N via FreeIPA-users wrote: > > By default the client and server installers enable the ssh service in SSSD. > > On the client if ssh is enabled it sets PubkeyAuthentication to yes, > enables the SSSD known hosts proxy and sets VerifyHostKeyDNS to yes (if > --no-dns-sshfp is not set). > > When sshd configuration is enabled (default) it sets: > > PubkeyAuthentication yes > KerberosAuthentication no > GSSAPIAuthentication yes > UsePAM yes > ChallengeResponseAuthentication yes > > Depending on release of sshd it will also set AuthorizedKeysCommand or > PubKeyAgent. > > rob Thanks. I'm not going to use FreeIPA as DNS, would you recommend me to set --no-dns-sshfp to true? BTW, is this mentioned in some documentation? ___ 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
[Freeipa-users] Re: SSL errors ... again
Hi Justin, The ra-agent.pem is the same certificate on all servers/replicas. When everything works properly, it gets renewed on the renewal master, then it is uploaded in LDAP and the other replicas can download it from LDAP. Do you have multiple servers? If yes and if the ra-agent.pem has been renewed on another server, you can simply copy the ra-agent.pem file from the other server to the failing one. If you have multiple servers but the ra-agent.pem is expired on all of them, you will have to fix the renewal master first. To find which server is the renewal master: # *kinit admin* Password for ad...@ipa.test: # *ipa config-show | grep renewal* IPA CA renewal master: server.ipa.test # Then to fix the renewal master, you can use *ipa-cert-fix* command. HTH, flo On Tue, May 9, 2023 at 2:33 AM Justin Sanderson via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote: > > Found the culprit /var/lib/ipa/ra-agent.pem > > > # openssl -in /var/lib/ipa/ra-agent.pem -noout -text |grep "Not After" > > The cert expired 4 days ago. ... whats proper "IPA" way to recreate > cert. I could do it with openssl but idd if there's "hooks" to other > components that i need to update. > > > On 5/7/2023 10:08 AM, Rob Crittenden wrote: > > Justin Sanderson via FreeIPA-users wrote: > >> Ok. So once again my IPA server is having cert issues. Everything seems > >> to be working except when I am in the web interface and goto > >> "Authentication" --> "Certificates" --> Click any of the certs in the > list. > >> > >> > >> I get this error from the browser.-- > >> > >> IPA ERROR 907: NetworkError > >> > >> cannot connect to > >> https://[myservernamehere.fqdn]:443/ca/agent/ca/displayBySerial' : > >> SSL_HANDSHAKE_FAILURE > >> > >> > >> # getcert list |grep expires --> everything checks out ok. no expiry on > >> any of the certs > >> > >> > >> --- checked all the certs on there "Not Before" and "Not After" dates > >> for the following NSS db's > >> > >> certutil -L -d /etc/pki/pki-tomcat/alias > >> > >> certutil -L -d /etc/httpd/alias > >> > >> > >> > >> In /var/log/httpd/error_log, I do see some errors: > >> > >> Bad Remote Server Certificate -8181 > >> > >> SSL Library Error: -8181 Certificate has expired > >> > >> > >> I know it's an expired cert obviously from httpd errorlog but where is > >> the darn thing. I thought i checked all the places and looked ok but I'm > >> definitely missing something > >> > >> > >> could use some advice. > > I'd simplify by trying on the command line: ipa cert-show 1 > > > > This will exercise the basic connectivity and will be less noisy than > > using the UI. I'd run the same command on all servers you have in case > > only one is affected. > > > > As for the TLS error in the httpd.log its hard to say without broader > > context. Is there an access log entry at the same time which may > correlate? > > > > 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 > ___ 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
