IPA slapd parameter tuning
by Kathy Zhu
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...
However, I wonder if there is a better guide.
Thanks.
Kathy.
2 years, 6 months
CA errors after update, server.xml desync?
by D Trom
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?
2 years, 6 months
Disabling ssh hostkey generation/caching
by Dominik Vogt
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 years, 6 months
ipa-cert-fix failing
by Marc Boorshtein
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
2 years, 6 months
Re: [BUG?] Host Alias DNS
by Florence Renaud
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.fedoraho...
>>> Do not reply to spam on the list, report it:
>>> https://pagure.io/fedora-infrastructure
>>>
>>
2 years, 6 months
ipa_check_consistency alerts and ERR - slapd_poll - Timed out
by Kathy Zhu
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.
2 years, 6 months
[BUG?] Host Alias DNS
by Buckley Ross
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 years, 6 months
Waiting for CA subsystem to start (round 2)
by MERCIER Jonathan
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 years, 6 months
Re: Why is ipa-ods-exporter broken after running ipa-dns-install? (Was - Unable to start directory server after updates)
by Jeremy Tourville
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/...
>
> 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.fedoraho...
>>>>> 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.fedoraho...
>>>>> 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.fedoraho...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>
2 years, 6 months
ipahealthcheck.ipa.certs.IPACertmongerExpirationCheck - Request ID expires in....
by Russell Jones
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 years, 6 months