September 2021 - FreeIPA-users - Fedora mailing-lists

IPA slapd parameter tuning
by Kathy Zhu 17 Sep '21

17 Sep '21

Hi List, One of my ipa server's database had issue and left many log entries like the following in messages and slapd errors log: *Sep 16 08*:34:28 ipa0 ns-slapd: [16/Sep/2021:08:34:28.886632992 -0700] - ERR - libdb - BDB0060 PANIC: fatal region error detected; run recovery *Sep 16 08*:34:29 ipa0 ns-slapd: [16/Sep/2021:08:34:28.987593487 -0700] - ERR - libdb - BDB0060 PANIC: fatal region error detected; run recovery *Sep 16 08*:34:29 ipa0 ns-slapd: [16/Sep/2021:08:34:29.035181321 -0700] - ERR - libdb - BDB0060 PANIC: fatal region error detected; run recovery Restart ipa fixed the issue. I googled for root cause and found the verified solution - https://access.redhat.com/solutions/3098131, which is to increase nsslapd-dncachememsize to a reasonable value (>150MB). This sounds like easy, however, all slapd cache parameters are related. Red Hat Directory Server performance tuning guide explain a bit: https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/h… However, I wonder if there is a better guide. Thanks. Kathy.

3 5

CA errors after update, server.xml desync?
by D Trom 16 Sep '21

16 Sep '21

If the subject isn't vague enough, perhaps I can explain in some better detail. I have IPA setup with a couple of replicas and it's been running fine for a few months; perriodic runs of ipa-healthcheck didn't show any issues. During an update of the system packages, something went wrong and the CA is now unavailable from the webui and ipa tools. When accessing from the webui (Authentication->Certificates) I get th following error: "Certificate operation cannot be completed: Unable to communicate with CMS (403)" From some cli tools (ipa cert-show) I get this error: "ipa: ERROR: Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)" It appears that dogtag is working, as I can use it's toolset to query "pki ca-cert-show 0x1 --pretty" for example returns the certificate as expected so I suspect the issue lies somewhere in the API. I compared the cert which I believe to be used for pki with the following: "grep internal /var/lib/pki/pki-tomcat/conf/password.conf | cut -d= -f2 > /tmp/pwdfile.txt" "certutil -K -d /etc/pki/pki-tomcat/alias -f /tmp/pwdfile.txt -n 'subsystemCert cert-pki-ca'" So from what I've read it seems pki-tomcat should be able to access it's private key and certificate. I also compared the cert with the one in LDAP and the two are the same. "ldapsearch -LLL -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca userCertificate" In digging through some old backups, I found that entries in /etc/pki/pki-tomcat/server.xml had changed, so I reset the "requiredSecret" back to an earlier value, which seemed to allow the webui to work again, at least partially as I can now get a listing from the CA in the webui though I cannot see details of any particular certificate. Assuming I'm on the right path, is there a documented process to regenerate the server.xml file or am I chasing the wrong problem?

4 4

Disabling ssh hostkey generation/caching
by Dominik Vogt 16 Sep '21

16 Sep '21

I have a problem with ssh host keys being automatically generated(?). Our installation process looks like this: 1) Install IdM server and clients. 2) Generate ssh host keys for all machines in a special way because of a requirement about available entropy that is not 3) Distribute the new keys to all machines but do not install them. (Any required known_hosts files are also generated and distributed). and known_hosts files 4) Reboot all machines at the same time. 5) During reboot, a script installs the new keys and deletes the old ones (rsa and ecdsa format). However, host key files in rsa and ecdsa format keep reappearing. I'm not exactly sure when this happens. Does it have something to do with sssd? -- So, we need to disable * automatic generation of ssh keys, * restoring them from backups (in case some component does that). Caching the keys in sssd would be in order if we can make sure that sssd does not cache the old keys at any time. Running "sss_cache -H" does not seem to affect the cached known_hosts file in /var/lib though. I understand that IdM can manage host keys, but we don't want to use that feature because of the underlying system requirements, and we'll never add new machines anyway. Ciao Dominik ^_^ ^_^ -- Dominik Vogt

2 3

ipa-cert-fix failing
by Marc Boorshtein 16 Sep '21

16 Sep '21

I'm trying to fix a freeipa 4.6 cluster running on centos 7 that has expired directory and http certificates. I turned back the clock so that the certs would be valid and am trying to run ipa-cert-fix but its failing with: INFO: Loading password config: /etc/pki/pki-tomcat/password.conf INFO: Fixing the following system certs: ['sslserver'] INFO: Renewing the following additional certs: ['21'] SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 INFO: Stopping the instance to proceed with system cert renewal INFO: Configuring LDAP password authentication INFO: Setting pkidbuser password via ldappasswd SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 INFO: Selftests disabled for subsystems: ca INFO: Resetting password for uid=ipara,ou=people,o=ipaca SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 INFO: Creating a temporary sslserver cert INFO: Getting sslserver cert info for ca INFO: Trying to create a new temp cert for sslserver. INFO: Generate temp SSL certificate INFO: Getting sslserver cert info for ca INFO: Selftests enabled for subsystems: ca INFO: Restoring previous LDAP configuration ERROR: Unable to find CSR for sslserver cert AFter doing some searching I found https://access.redhat.com/solutions/4852721 but the instructions aren't applying to me because there's no CSR in the request: Request ID '20210601131820': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=RHELENT.LAN subject: CN=CA Subsystem,O=RHELENT.LAN expires: 2023-05-01 18:04:11 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes then look for a csr: [root@freeipa ~]# grep -A 19 csr /var/lib/certmonger/requests/20210601131820 [root@freeipa ~]# Is there something i can do to get the ca subsystem cert re-issued? Thanks Marc Boorshtein

3 7

Re: [BUG?] Host Alias DNS
by Florence Renaud 16 Sep '21

16 Sep '21

Hi, re-adding the mailing list On Wed, Sep 15, 2021 at 6:31 PM Buckley Ross <buckleyross42(a)gmail.com> wrote: > Hi Flo, > > I think you misread my question. > Indeed. I interpreted "I found that on DNS records were provisioned..." as "I found that on <the> DNS <server>, records were provisioned" instead of "I found that *no* DNS records were provisioned". Sorry about that... I am not running `ipa host-add`. I am running `ipa host-add-principal`. I > would expect that if I am adding a new principal to a host, that > principal's DNS name would be added with either a CNAME or an A record, > pointing back to the original host. Is there a reason that this does not > happen? I cannot understand the utility of being able to add a new > principal to a host if that principal is not routable via DNS. > In your case you expect myhost and myalias to resolve to the same IP address, but that's not the general use case. Consider for instance a host with 2 different IP addresses, myhost resolving to the 1st one and myalias to the 2nd one. Adding the principal alias is de-coupled from the DNS records. Hope this clarifies, flo > Thanks, > Buckley Ross > > On Tue, Sep 14, 2021 at 7:17 AM Florence Renaud <flo(a)redhat.com> wrote: > >> Hi, >> I was not able to reproduce this issue: >> >> # ipa host-add myhost.ipa.test --ip-address $IP >> # ipa dnsrecord-find ipa.test >> >> shows myhost.ipa.test has been added >> >> # ipa host-add-principal myhost host/myalias.ipa.test >> # ipa dnsrecord-find ipa.test >> >> no new record added >> >> DNS records are added when the command "ipa host-add --ip-address" is >> used, when a host is joined with ipa-client-install, or when "ipa >> dnsrecord-add" is called. You can check in /var/log/httpd/error_log if you >> find trace of such a command. >> >> flo >> >> On Mon, Sep 13, 2021 at 1:46 PM Buckley Ross via FreeIPA-users < >> freeipa-users(a)lists.fedorahosted.org> wrote: >> >>> Hello, >>> >>> I'm trying to provision an HTTP service principal for a containerized >>> service. The host on which the container is running also has a kerberized >>> HTTP service running on it with a separate service principal (both services >>> are highly critical, but for different systems, and thus should probably >>> have separate keytabs). >>> >>> Since both services share an IP address (but are serving HTTP on >>> different ports), this seemed like a perfect application of kerberos host >>> aliases. However, when I provisioned a host alias with `ipa >>> host-add-principal myHost host/myAlias.domain.com`, I found that on DNS >>> records were provisioned for `myAlias.domain.com`, thus making the >>> alias completely useless for resolving to the container. Is this a bug in >>> the host-alias system, or am I missing something? >>> >>> Thank you for your time. >>> >>> Thank you, >>> Buckley Ross >>> _______________________________________________ >>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >>> To unsubscribe send an email to >>> freeipa-users-leave(a)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.fedorahost… >>> Do not reply to spam on the list, report it: >>> https://pagure.io/fedora-infrastructure >>> >>

1 0

ipa_check_consistency alerts and ERR - slapd_poll - Timed out
by Kathy Zhu 15 Sep '21

15 Sep '21

Hi List, I use ipa_check_consistency <https://github.com/peterpakos/checkipaconsistency/tree/v1.3.0> as one of my Nagios monitors. It runs every 5 minutes on each ipa server. For example: [root@ipa0 ~]# /usr/local/sbin/ipa_check_consistency -d example.com -H ipa0 Directory Manager password: FreeIPA servers: ipa0 STATE ================================= Active Users 1422 OK Stage Users 0 OK Preserved Users 10 OK User Groups 75 OK Hosts 848 CRITICAL Host Groups 39 OK HBAC Rules 593 OK SUDO Rules 8 OK DNS Zones 16 OK Certificates 244 OK LDAP Conflicts NO OK Ghost Replicas NO OK Anonymous BIND YES OK Replication Status ipa2 0 OK ipa1 0 ipa3 0 ipa5 0 ================================= [root@ipa0 ~]# All ipa servers report OK for all components but there is one ipa server which alerts CRITICAL everyday multiple times. The inconsistency alers are in different components, for example, "Hosts", "Active Users", and so on, however, it never alerts for "Replication Status" and "LDAP Conflicts". This is also the only ipa server within the domain which I see "Timed out" like the following in its /var/log/dirsrv/slapd-EXAMPLE-COM/errors log: [14/Sep/2021:06:55:40.694662470 -0700] - ERR - slapd_poll - (429) - Timed out [14/Sep/2021:16:08:45.441598637 -0700] - ERR - slapd_poll - (1211) - Timed out [14/Sep/2021:16:08:55.452150573 -0700] - ERR - slapd_poll - (1211) - Timed out [14/Sep/2021:16:09:05.460069764 -0700] - ERR - slapd_poll - (1211) - Timed out However, the timestamps of the above may not match when ipa_check_consistency alerts. This ipa server's OS is Centos 7-8.2003.0 and IPA version is 4.6.8, API: 2.237. [root@ipa0 ~]# rpm -qa 389\* 389-ds-base-snmp-1.3.10.1-14.el7_8.x86_64 389-ds-base-libs-1.3.10.1-14.el7_8.x86_64 389-ds-base-1.3.10.1-14.el7_8.x86_64 [root@ipa0 ~]# rpm -qa slapi\* slapi-nis-0.56.0-13.el7.x86_64 [root@ipa0 ~]# This may not be the same issue or connected. However, I feel that something in its configuration is not correct with this ipa server but do not know what. Since I have other ipa servers which have the same OS, ipa version and so on but do not exhibit this behavior. Does anyone have any ideas for troubleshooting? Thanks! Kathy.

1 0

[BUG?] Host Alias DNS
by Buckley Ross 14 Sep '21

14 Sep '21

Hello, I'm trying to provision an HTTP service principal for a containerized service. The host on which the container is running also has a kerberized HTTP service running on it with a separate service principal (both services are highly critical, but for different systems, and thus should probably have separate keytabs). Since both services share an IP address (but are serving HTTP on different ports), this seemed like a perfect application of kerberos host aliases. However, when I provisioned a host alias with `ipa host-add-principal myHost host/myAlias.domain.com`, I found that on DNS records were provisioned for `myAlias.domain.com`, thus making the alias completely useless for resolving to the container. Is this a bug in the host-alias system, or am I missing something? Thank you for your time. Thank you, Buckley Ross

2 1

Waiting for CA subsystem to start (round 2)
by MERCIER Jonathan 14 Sep '21

14 Sep '21

Dear, with my best effort I am unable tu deploy freeipa on RockyLinux . I would like to know if someone have already try it ? So bellow you will find commands run from a fresh RockyLinux VM (4Gb ram) ------------------- sed -i -e '/identity\.infra\.microbiome\.studio/d' -e '1i 51.15.228.43 identity.infra.microbiome.studio' /etc/hosts hostnamectl set-hostname identity.infra.microbiome.studio dnf install -y net-tools sslscan firewalld epel-release dnf update -y dnf module enable -y idm:DL1 dnf distro-sync -y dnf install -y ipa-server ipa-server-dns firewall-cmd --add-service={freeipa-ldap,freeipa-ldaps,dns,ntp} --permanent systemctl enable firewalld && systemctl start firewalld && firewall-cmd --add-service={freeipa-ldap,freeipa-ldaps,dns,ntp} --permanent firewall-cmd --reload ipa-server-install --verbose --setup-dns --ntp-pool=pool.ntp.org --ds-password=secret1 --admin-password=secret2 --domain=infra.microbiome.studio --realm=INFRA.MICROBIOME.STUDIO --ip-address=51.15.228.43 ------------------- This should be enough to get freeipa, but ipa-server-install command exit with a time out error after 60 sec with following message: ------------------- The ipa-server-install command failed, exception: RuntimeError: CA configuration failed. CA configuration failed. The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information ------------------- The corresponding log file do not give more clear reason than a timeout.... it seems that from a vanilla RockyLinux with SeLinux pki do not works well see output: ------------------- systemctl status pki-tomcatd(a)pki-tomcat.service ● pki-tomcatd(a)pki-tomcat.service - PKI Tomcat Server pki-tomcat Loaded: loaded (/usr/lib/systemd/system/pki-tomcatd@.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2021-09-09 15:01:00 UTC; 4min 29s ago Process: 72379 ExecStartPre=/usr/bin/pkidaemon start pki-tomcat (code=exited, status=0/SUCCESS) Process: 72346 ExecStartPre=/usr/sbin/pki-server migrate pki-tomcat (code=exited, status=0/SUCCESS) Process: 72343 ExecStartPre=/usr/sbin/pki-server upgrade pki-tomcat (code=exited, status=0/SUCCESS) Main PID: 72469 (java) Tasks: 115 (limit: 23443) Memory: 450.0M CGroup: /system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd(a)pki-tomcat.service └─72469 /usr/lib/jvm/java-1.8.0-openjdk/bin/java -Dcom.redhat.fips=false -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/ant.jar:/usr/share/java/a> sept. 09 15:00:58 identity.infra.microbiome.studio java[72364]: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock sept. 09 15:01:00 identity.infra.microbiome.studio systemd[1]: Started PKI Tomcat Server pki-tomcat. sept. 09 15:01:00 identity.infra.microbiome.studio server[72469]: Java virtual machine used: /usr/lib/jvm/java-1.8.0-openjdk/bin/java sept. 09 15:01:00 identity.infra.microbiome.studio server[72469]: classpath used: /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/ant.jar:/usr/share/java/ant-launcher.j> sept. 09 15:01:00 identity.infra.microbiome.studio server[72469]: main class used: org.apache.catalina.startup.Bootstrap sept. 09 15:01:00 identity.infra.microbiome.studio server[72469]: flags used: -Dcom.redhat.fips=false sept. 09 15:01:00 identity.infra.microbiome.studio server[72469]: options used: -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pki/pki-> sept. 09 15:01:00 identity.infra.microbiome.studio server[72469]: arguments used: start sept. 09 15:01:01 identity.infra.microbiome.studio java[72469]: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock sept. 09 15:01:02 identity.infra.microbiome.studio server[72469]: WARNING: Some of the specified [protocols] are not supported by the SSL engine and have been skipped: [[TLSv1, TLSv1.1]] ------------------- LDAP (389) and web (8080) port seems to be used as expected: ------------------- # netstat -tunelp Connexions Internet actives (seulement serveurs) Proto Recv-Q Send-Q Adresse locale Adresse distante Etat Utilisatr Inode PID/Program name tcp 0 0 0.0.0.0:749 0.0.0.0:* LISTEN 0 109422 72100/kadmind tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 0 16896 1/systemd tcp 0 0 0.0.0.0:464 0.0.0.0:* LISTEN 0 109418 72100/kadmind tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 28217 1433/sshd tcp 0 0 0.0.0.0:88 0.0.0.0:* LISTEN 0 111080 72041/krb5kdc tcp6 0 0 127.0.0.1:8005 :::* LISTEN 17 112610 72469/java tcp6 0 0 :::389 :::* LISTEN 0 110760 71946/ns-slapd tcp6 0 0 ::1:8009 :::* LISTEN 17 113337 72469/java tcp6 0 0 127.0.0.1:8009 :::* LISTEN 17 113335 72469/java tcp6 0 0 :::749 :::* LISTEN 0 109423 72100/kadmind tcp6 0 0 :::111 :::* LISTEN 0 16898 1/systemd tcp6 0 0 :::8080 :::* LISTEN 17 113329 72469/java tcp6 0 0 :::464 :::* LISTEN 0 109419 72100/kadmind tcp6 0 0 :::22 :::* LISTEN 0 28219 1433/sshd tcp6 0 0 :::88 :::* LISTEN 0 111081 72041/krb5kdc tcp6 0 0 :::8443 :::* LISTEN 17 113333 72469/java udp 0 0 127.0.0.1:323 0.0.0.0:* 0 105961 71724/chronyd udp 0 0 0.0.0.0:464 0.0.0.0:* 0 109414 72100/kadmind udp 0 0 0.0.0.0:88 0.0.0.0:* 0 111076 72041/krb5kdc udp 0 0 0.0.0.0:111 0.0.0.0:* 0 16897 1/systemd udp6 0 0 ::1:323 :::* 0 105962 71724/chronyd udp6 0 0 :::464 :::* 0 109415 72100/kadmind udp6 0 0 :::88 :::* 0 111077 72041/krb5kdc udp6 0 0 :::111 :::* 0 16899 1/systemd ------------------- 389 Directory seems to be ok: ------------------- dsctl INFRA-MICROBIOME-STUDIO status Instance "INFRA-MICROBIOME-STUDIO" is running ------------------- The file /var/lib/pki/pki-tomcat/logs/ca/debug.2021-09-09.log ands with: ------------------- ... 2021-09-09 15:01:09 [main] INFO: AuthzSubsystem: authz manager instance DirAclAuthz added 2021-09-09 15:01:09 [main] INFO: AuthzSubsystem: authz initialization done. 2021-09-09 15:01:09 [main] INFO: CMSEngine: Configuring servlet certificate nickname 2021-09-09 15:01:09 [main] INFO: CMSEngine: Configuring excluded LDAP attributes 2021-09-09 15:01:09 [main] INFO: CA engine started ------------------- And /var/lib/pki/pki-tomcat/logs/pki/debug.2021-09-09.log is empty It seems that they are any ssl certificate into ls /var/lib/pki/pki-tomcat/conf/* ------------------- /var/lib/pki/pki-tomcat/conf/catalina.policy /var/lib/pki/pki-tomcat/conf/logging.properties /var/lib/pki/pki-tomcat/conf/server.xml /var/lib/pki/pki-tomcat/conf/catalina.properties /var/lib/pki/pki-tomcat/conf/password.conf /var/lib/pki/pki-tomcat/conf/tomcat.conf /var/lib/pki/pki-tomcat/conf/context.xml /var/lib/pki/pki-tomcat/conf/serverCertNick.conf /var/lib/pki/pki-tomcat/conf/web.xml /var/lib/pki/pki-tomcat/conf/alias: ca.crt cert9.db key4.db pkcs11.txt /var/lib/pki/pki-tomcat/conf/ca: adminCert.profile archives caAuditSigningCert.profile caCert.profile caOCSPCert.profile CS.cfg CS.cfg.bak flatfile.txt proxy.conf registry.cfg serverCert.profile subsystemCert.profile /var/lib/pki/pki-tomcat/conf/Catalina: localhost ------------------- So what can I to do in order to get freeipa running on RockyLinux ? Thanks for your help Have a good day Jonathan

2 2

Re: Why is ipa-ods-exporter broken after running ipa-dns-install? (Was - Unable to start directory server after updates)
by Jeremy Tourville 13 Sep '21

13 Sep '21

Last week I ran the command: > [root@utility ~]# ipa-certupdate > > cannot connect to 'https://utility.idm.nac-issa.org/ipa/json': [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897) > The ipa-certupdate command failed. We tested the root CA cert and server cert. Both were found to be good. Is it possible I'd need to chain the two together? Which certificate is the error message complaining about? What directory? Update-ca-trust had no affect. Is this because of the above error message? ________________________________ From: Jeremy Tourville <jeremy_tourville(a)hotmail.com> Sent: Friday, September 10, 2021 3:41 PM To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> Cc: Florence Renaud <flo(a)redhat.com>; Rob Crittenden <rcritten(a)redhat.com> Subject: Re: [Freeipa-users] Re: Why is ipa-ods-exporter broken after running ipa-dns-install? (Was - Unable to start directory server after updates) ACK, the typo was why certutil failed initially. It works now. >>>So update-ca-trust had no affect or was this run beforehand? Update-ca-trust had no affect. it was run after doing the ipa-cacert-mange renew . >>>You didn't happen to touch /etc/httpd/conf.d/ssl.conf did you? No, I left it alone >>>This renews the CA certificate. The CA is good for 20 years, you didn't need to do this. ACK >>>We now have another CA certificate for IPA in the mix because of the renewal. OK, I'll stand by so I don't really mess it up. ________________________________ From: Rob Crittenden <rcritten(a)redhat.com> Sent: Friday, September 10, 2021 3:26 PM To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> Cc: Florence Renaud <flo(a)redhat.com>; Jeremy Tourville <jeremy_tourville(a)hotmail.com> Subject: Re: [Freeipa-users] Re: Why is ipa-ods-exporter broken after running ipa-dns-install? (Was - Unable to start directory server after updates) Jeremy Tourville via FreeIPA-users wrote: > I was doing some reading and troubleshooting > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/ht… > > which basically says: > #1 ipa-cacert-manage renew > #2 ipa-certupdate > #3 certutil -L -d /etc/pki/pki-tomcat/alias (to test the certs) > > See my output. Step #1 and #3 work now but #2 still fails > > > [root@utility certs]# ipa-certupdate > > cannot connect to 'https://utility.idm.nac-issa.org/ipa/json': [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897) > The ipa-certupdate command failed. So update-ca-trust had no affect or was this run beforehand? > [root@utility certs]# certutil -L -d /etc/pki/pik-tomcat/alias > > certutil: function failed: SEC_ERROR_BAD_DATABASE: security library: bad > database. It failed because of a typo, pik -> pki. > [root@utility certs]# ipa-cacert-manage renew > > Renewing CA certificate, please wait > CA certificate successfully renewed > The ipa-cacert-manage command was successful This renews the CA certificate. The CA is good for 20 years, you didn't need to do this. > [root@utility certs]# ipa-certupdate > > cannot connect to 'https://utility.idm.nac-issa.org/ipa/json': [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897) > The ipa-certupdate command failed. We now have another CA certificate for IPA in the mix because of the renewal. > > [root@utility certs]# certutil -L -d /etc/pki/pki-tomcat/alias > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > ocspSigningCert cert-pki-ca u,u,u > subsystemCert cert-pki-ca u,u,u > auditSigningCert cert-pki-ca u,u,Pu > Server-Cert cert-pki-ca u,u,u > caSigningCert cert-pki-ca CTu,Cu,Cu > IDM.NAC-ISSA.ORG IPA CA CTu,Cu,Cu > [root@utility certs]# reboot It isn't a problem with the CA. The system doesn't trust the CA for some reason, though the openssl command verified that it is ok. > [root@utility certs]# reboot > > [root@utility ~]# ipa-certupdate > > cannot connect to 'https://utility.idm.nac-issa.org/ipa/json': [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897) > The ipa-certupdate command failed. You didn't happen to touch /etc/httpd/conf.d/ssl.conf did you? rob > > [root@utility ~]# ipactl status > > Directory Service: RUNNING > krb5kdc Service: RUNNING > kadmin Service: RUNNING > named Service: RUNNING > httpd Service: RUNNING > ipa-custodia Service: RUNNING > pki-tomcatd Service: RUNNING > smb Service: RUNNING > winbind Service: RUNNING > ipa-otpd Service: RUNNING > ipa-ods-exporter Service: STOPPED > ods-enforcerd Service: RUNNING > ipa-dnskeysyncd Service: RUNNING > ipa: INFO: The ipactl command was successful > > ------------------------------------------------------------------------ > *From:* Rob Crittenden <rcritten(a)redhat.com> > *Sent:* Friday, September 10, 2021 9:49 AM > *To:* Jeremy Tourville <jeremy_tourville(a)hotmail.com>; FreeIPA users > list <freeipa-users(a)lists.fedorahosted.org> > *Cc:* Florence Renaud <flo(a)redhat.com> > *Subject:* Re: [Freeipa-users] Re: Why is ipa-ods-exporter broken after > running ipa-dns-install? (Was - Unable to start directory server after > updates) > > Jeremy Tourville wrote: >> [root@utility certs]# curl https://utility.idm.nac-issa.org/ >> curl: (60) SSL certificate problem: self signed certificate in >> certificate chain >> More details here: https://curl.haxx.se/docs/sslcerts.html >> >> curl failed to verify the legitimacy of the server and therefore could not >> establish a secure connection to it. To learn more about this situation and >> how to fix it, please visit the web page mentioned above. >> >> [root@utility certs]# update-ca-trust >> >> [root@utility certs]# ausearch -m AVC -ts recent >> <no matches> >> >> [root@utility certs]# ipa-healthcheck >> -bash: ipa-healthcheck: command not found > > I should have mentioned, try the curl after running update-ca-trust. > > ipa-healthcheck is not installed by default, you'd need to install the > {free}ipa-healthcheck package. > > rob > >> >> >> >> ------------------------------------------------------------------------ >> *From:* Rob Crittenden <rcritten(a)redhat.com> >> *Sent:* Friday, September 10, 2021 9:33 AM >> *To:* Jeremy Tourville <jeremy_tourville(a)hotmail.com>; FreeIPA users >> list <freeipa-users(a)lists.fedorahosted.org> >> *Cc:* Florence Renaud <flo(a)redhat.com> >> *Subject:* Re: [Freeipa-users] Re: Why is ipa-ods-exporter broken after >> running ipa-dns-install? (Was - Unable to start directory server after >> updates) >> >> Jeremy Tourville wrote: >>> [root@utility certs]# ipa-certupdate >>> cannot connect to 'https://utility.idm.nac-issa.org/ipa/json': [SSL: >>> CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897) >>> The ipa-certupdate command failed. >>> >>> Sort of a bad catch 22 I guess? >> >> Yeah, I was afraid of that. >> >> Let's walk through it. Try a simple command for another data point. I'm >> not sure what we'd do with this but it will exercise the system-wide >> trust as well: >> >> $ curl https://`hostname`/ >> >> Rebuilding the CA trust db may help >> >> # update-ca-trust >> >> I suppose also look for AVCs in case something is way out-of-whack: >> >> # ausearch -m AVC -ts recent >> >> ipa-healthcheck may be something to try as well but you're likely to get >> a crapton of false positives since it can't talk to the web interface. >> >> rob >> >>> >>> ------------------------------------------------------------------------ >>> *From:* Rob Crittenden <rcritten(a)redhat.com> >>> *Sent:* Friday, September 10, 2021 9:09 AM >>> *To:* Jeremy Tourville <jeremy_tourville(a)hotmail.com>; FreeIPA users >>> list <freeipa-users(a)lists.fedorahosted.org> >>> *Cc:* Florence Renaud <flo(a)redhat.com> >>> *Subject:* Re: [Freeipa-users] Re: Why is ipa-ods-exporter broken after >>> running ipa-dns-install? (Was - Unable to start directory server after >>> updates) >>> >>> Jeremy Tourville wrote: >>>> Now I understand how to test the cert(s) after re-reading your comments >>>> Rob and Flo 🙂 >>>> >>>> [root@utility certs]# openssl verify -verbose -show_chain -CAfile >>>> /etc/ipa/ca.crt /var/lib/ipa/certs/httpd.crt >>>> /var/lib/ipa/certs/httpd.crt: OK >>>> Chain: >>>> depth=0: O = IDM.NAC-ISSA.ORG, CN = utility.idm.nac-issa.org (untrusted) >>>> depth=1: O = IDM.NAC-ISSA.ORG, CN = Certificate Authority >>> >>> I'd try running ipa-certupdate. I have the feeling some of the >>> system-wide certificates are out-of-sync. >>> >>> rob >>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Jeremy Tourville <jeremy_tourville(a)hotmail.com> >>>> *Sent:* Thursday, September 9, 2021 5:45 PM >>>> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> >>>> *Cc:* Florence Renaud <flo(a)redhat.com>; Rob Crittenden <rcritten(a)redhat.com> >>>> *Subject:* Re: [Freeipa-users] Re: Why is ipa-ods-exporter broken after >>>> running ipa-dns-install? (Was - Unable to start directory server after >>>> updates) >>>> >>>> Oh wait!!! Which set of certs do I need to test against for my >>>> certificate chain? >>>> I realized I didn't include the proper path when testing. It should be >>>> something like- >>>> >>>> # openssl verify -verbose -show_chain -CAfile <path to root or >>>> intermediate cert> /etc/ipa/ca.crt >>>> # openssl verify -verbose -show_chain -CAfile <path to root or >>>> intermediate cert> /var/lib/ipa/certs/httpd.crt >>>> >>>> This would give you output (presuming you are using the correct set of >>>> certs) >>>> /etc/ipa/ca.crt: OK >>>> /var/lib/ipa/certs/httpd.crt: OK >>>> >>>> Which path contains the intermediate or root CA certs I need to test >>>> against? >>>> >>>> [root@utility ~]# ls -la | find / -name *.crt >>>> /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt >>>> /etc/pki/ca-trust/source/ca-bundle.legacy.crt >>>> /etc/pki/tls/certs/ca-bundle.crt >>>> /etc/pki/tls/certs/ca-bundle.trust.crt >>>> /etc/pki/tls/certs/localhost.crt >>>> /etc/pki/pki-tomcat/alias/ca.crt >>>> /etc/ipa/ca.crt >>>> /etc/dirsrv/ssca/ca.crt >>>> /etc/dirsrv/slapd-IDM-NAC-ISSA-ORG/Server-Cert.crt >>>> /etc/dirsrv/slapd-IDM-NAC-ISSA-ORG/ca.crt >>>> /var/lib/ipa/certs/httpd.crt >>>> /var/kerberos/krb5kdc/kdc.crt >>>> /usr/share/pki/ca-trust-legacy/ca-bundle.legacy.default.crt >>>> /usr/share/pki/ca-trust-legacy/ca-bundle.legacy.disable.crt >>>> /usr/share/ipa/html/ca.crt >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Jeremy Tourville <jeremy_tourville(a)hotmail.com> >>>> *Sent:* Thursday, September 9, 2021 3:13 PM >>>> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> >>>> *Cc:* Florence Renaud <flo(a)redhat.com>; Rob Crittenden <rcritten(a)redhat.com> >>>> *Subject:* Re: [Freeipa-users] Re: Why is ipa-ods-exporter broken after >>>> running ipa-dns-install? (Was - Unable to start directory server after >>>> updates) >>>> >>>>>>>It isn't complaining that the certificate isn't valid, it's complaining >>>> that it isn't trusted. >>>> Thanksfor pointing out my mistake. I'm wearing some egg on my face. I >>>> was thinking about it wrong at the time of my reply. >>>> >>>> I attempted to verify trust- >>>> [root@utility ipa]# openssl verify -verbose -show_chain -CAfile >>>> /etc/ipa/ca.crt >>>> ^C >>>> [root@utility ipa]# openssl verify -verbose -show_chain -CAfile >>>> /var/lib/ipa/certs/httpd.crt >>>> ^C >>>> >>>> As you can see, no output, so yeah, they are not trusted. >>>> >>>>>>Where did httpd.crt come from/what issuer? >>>> I recall not using a 3rd party CA. The certs were just self-signed when >>>> the ipa server was initially built. I never did replace the certs as it >>>> wasn't required for our situation. >>>> >>>> Next steps I guess would be to generate some new certs? Thoughts? >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Rob Crittenden <rcritten(a)redhat.com> >>>> *Sent:* Thursday, September 9, 2021 12:53 PM >>>> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> >>>> *Cc:* Florence Renaud <flo(a)redhat.com>; Jeremy Tourville >>>> <jeremy_tourville(a)hotmail.com> >>>> *Subject:* Re: [Freeipa-users] Re: Why is ipa-ods-exporter broken after >>>> running ipa-dns-install? (Was - Unable to start directory server after >>>> updates) >>>> >>>> Jeremy Tourville via FreeIPA-users wrote: >>>>> /var/lib/ipa/certs/httpd.crt >>>>> looks valid and has a 3 year validity date starting from Nov 23, 2020 >>>>> >>>>> /etc/ipa/ca.crt >>>>> looks valid and has a 20 year validity date starting from Nov 23, 2020 >>>> >>>> It isn't complaining that the certificate isn't valid, it's complaining >>>> that it isn't trusted. You also need to look at the signer and ensure >>>> that the system trusts it globally. Where did httpd.crt come from/what >>>> issuer? >>>> >>>> You might try running: >>>> >>>> openssl verify -verbose -show_chain -CAfile /etc/ipa/ca.crt >>>> /var/lib/ipa/certs/httpd.crt >>>> >>>> See the default.conf(5) man page for a description of default.conf, >>>> server.conf, etc. In this case server is a context so the configuration >>>> only applies there. >>>> >>>> rob >>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* Florence Renaud <flo(a)redhat.com> >>>>> *Sent:* Tuesday, September 7, 2021 11:38 AM >>>>> *To:* Jeremy Tourville <jeremy_tourville(a)hotmail.com> >>>>> *Cc:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> >>>>> *Subject:* Re: [Freeipa-users] Re: Why is ipa-ods-exporter broken after >>>>> running ipa-dns-install? (Was - Unable to start directory server after >>>>> updates) >>>>> >>>>> Hi Jeremy, >>>>> >>>>> to enable debugging you can simply create /etc/ipa/server.conf if the >>>>> file does not exist: >>>>> # cat /etc/ipa/server.conf >>>>> [global] >>>>> debug=True >>>>> # systemctl restart httpd >>>>> >>>>> The HTTPd certificate is stored in /var/lib/ipa/certs/httpd.crt, you can >>>>> examine its content with >>>>> # openssl x509 -noout -text -in /var/lib/ipa/certs/httpd.crt >>>>> If the IPA deployment includes an embedded CA, the CA that issued the >>>>> httpd cert is stored in /etc/ipa/ca.crt and can also be checked with >>>>> openssl command. >>>>> >>>>> flo >>>>> >>>>> On Tue, Sep 7, 2021 at 6:09 PM Jeremy Tourville >>>>> <jeremy_tourville(a)hotmail.com <mailto:jeremy_tourville@hotmail.com>> wrote: >>>>> >>>>> I think I see the issue but I am unsure what to do to fix it. See >>>>> below. >>>>> >>>>> To answer your question, yes I did accept the security exception. >>>>> >>>>> Also, I don't see a server.conf file at /etc/ipa so that I may >>>>> enable debugging. What can you suggest for this issue? >>>>> >>>>> >>>>> [root@utility ~]# ipactl status >>>>> Directory Service: RUNNING >>>>> krb5kdc Service: RUNNING >>>>> kadmin Service: RUNNING >>>>> named Service: RUNNING >>>>> httpd Service: RUNNING >>>>> ipa-custodia Service: RUNNING >>>>> pki-tomcatd Service: RUNNING >>>>> smb Service: RUNNING >>>>> winbind Service: RUNNING >>>>> ipa-otpd Service: RUNNING >>>>> ipa-ods-exporter Service: STOPPED >>>>> ods-enforcerd Service: RUNNING >>>>> ipa-dnskeysyncd Service: RUNNING >>>>> ipa: INFO: The ipactl command was successful >>>>> >>>>> [root@utility ~]# kinit admin >>>>> Password for admin(a)IDM.NAC-ISSA.ORG <mailto:admin@IDM.NAC-ISSA.ORG>: >>>>> >>>>> [root@utility ~]# klist >>>>> Ticket cache: KCM:0:43616 >>>>> Default principal: admin(a)IDM.NAC-ISSA.ORG >>>>> <mailto:admin@IDM.NAC-ISSA.ORG> >>>>> >>>>> Valid starting Expires Service principal >>>>> 09/07/2021 10:59:23 09/08/2021 10:09:04 >>>>> krbtgt/IDM.NAC-ISSA.ORG(a)IDM.NAC-ISSA.ORG >>>>> <mailto:IDM.NAC-ISSA.ORG@IDM.NAC-ISSA.ORG> >>>>> >>>>> [root@utility ~]# ipa config-show >>>>> ipa: ERROR: cannot connect to >>>>> 'https://utility.idm.nac-issa.org/ipa/json': [SSL: >>>>> CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897) >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* Florence Renaud <flo(a)redhat.com <mailto:flo@redhat.com>> >>>>> *Sent:* Tuesday, September 7, 2021 10:47 AM >>>>> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org >>>>> <mailto:freeipa-users@lists.fedorahosted.org>> >>>>> *Cc:* Jeremy Tourville <jeremy_tourville(a)hotmail.com >>>>> <mailto:jeremy_tourville@hotmail.com>> >>>>> *Subject:* Re: [Freeipa-users] Re: Why is ipa-ods-exporter broken >>>>> after running ipa-dns-install? (Was - Unable to start directory >>>>> server after updates) >>>>> >>>>> Hi Jeremy, >>>>> Did you accept the security exception displayed by the browser (I'm >>>>> trying to eliminate obvious issues)? >>>>> If nothing is displayed, can you check if ipa command-line is >>>>> working as expected (for instance do "kinit admin; ipa config-show")? >>>>> You may want to enable debug logs (add debug=True to the [global] >>>>> section of /etc/ipa/server.conf and restart httpd service), retry >>>>> WebUI authentication and check the generated logs in >>>>> /var/log/http/error_log >>>>> >>>>> flo >>>>> >>>>> On Tue, Sep 7, 2021 at 2:01 PM Jeremy Tourville via FreeIPA-users >>>>> <freeipa-users(a)lists.fedorahosted.org >>>>> <mailto:freeipa-users@lists.fedorahosted.org>> wrote: >>>>> >>>>> OK, >>>>> Why don't I see anything on the initial login page? >>>>> All I see is the URL and the fact that the certificate is not >>>>> trusted. The certificate is not expired yet. Not until Nov 2021. >>>>> The login in page is mostly solid white with no login or >>>>> password field. >>>>> _______________________________________________ >>>>> FreeIPA-users mailing list -- >>>>> freeipa-users(a)lists.fedorahosted.org >>>>> <mailto:freeipa-users@lists.fedorahosted.org> >>>>> To unsubscribe send an email to >>>>> freeipa-users-leave(a)lists.fedorahosted.org >>>>> <mailto:freeipa-users-leave@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.fedorahost… >>>>> Do not reply to spam on the list, report it: >>>>> https://pagure.io/fedora-infrastructure >>>>> >>>>> >>>>> _______________________________________________ >>>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >>>>> To unsubscribe send an email to freeipa-users-leave(a)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.fedorahost… >>>>> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure >>>>> >>>> >>> >> > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)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.fedorahost… > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure >

1 0

ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck - Request ID expires in....
by Russell Jones 13 Sep '21

13 Sep '21

Hi all, I am not sure what to do with these below errors. Are they related to my failed replica that I rebuilt and resynced, and as a result can be ignored? All the current certificates seem to be healthy. Thanks for the insight! WARNING: ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck.20191010160502: Request id 20191010160502 expires in 27 days WARNING: ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck.20191010160533: Request id 20191010160533 expires in 27 days WARNING: ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck.20191010160542: Request id 20191010160542 expires in 27 days WARNING: ipahealthcheck.ipa.certs.IPACertfileExpirationCheck.20191010160502: Request id 20191010160502 expires in 27 days WARNING: ipahealthcheck.ipa.certs.IPACertfileExpirationCheck.20191010160533: Request id 20191010160533 expires in 27 days WARNING: ipahealthcheck.ipa.certs.IPACertfileExpirationCheck.20191010160542: Request id 20191010160542 expires in 27 days [root@freeipa ~]# getcert list | grep -i status status: MONITORING status: MONITORING status: MONITORING status: MONITORING status: MONITORING status: MONITORING status: MONITORING status: MONITORING status: MONITORING

2 2

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users September 2021