7:35 p.m.
Hello,
How or what does it use to compare with?
I see a cert in the nssdb with the correct nickname.
certutil -L -d /etc/pki/nssdb
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
host/idm2.x.y u,u,u
I also see the other side of the same coin....
getcert list -c IPA | grep -A15 20191122115414
Request ID '20191122115414':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/nssdb',nickname='host/idm2.x.y',token='NSS
Certificate DB'
certificate:
type=NSSDB,location='/etc/pki/nssdb',nickname='host/idm2.x.y',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=X.Y
subject: CN=idm2.x.y,O=X.Y
expires: 2021-11-22 11:54:15 UTC
principal name: host/idm2.x.y(a)X.Y
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Not sure that I want to delete either.
Thanks!
David Patterson
-----Original Message-----
From: Rob Crittenden <rcritten(a)redhat.com>
Sent: Monday, January 11, 2021 11:07 AM
To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
Cc: Patterson, David <dpatte(a)sandia.gov>
Subject: [EXTERNAL] Re: [Freeipa-users] ipa healthcheck issue
Patterson, David via FreeIPA-users wrote:
Hello,
Â
Running RHEL 7.9, ipa 4.6.8-5 and freeipa-healthcheck 0.3-2 backported
for RHEL 7.
Â
Ipa healthcheck output
[
 {
   "source": "ipahealthcheck.ipa.certs",
   "kw": {
     "msg": "Unable to retrieve cert 'host/idm2.X.Y' from
'/etc/pki/nssdb': Failed to get host/idm2.X.Y",
     "nickname": "host/idm2.X.Y",
     "dbdir": "/etc/pki/nssdb",
     "key": "20191122115414",
     "error": "Failed to get host/idm2.X.Y"
   },
   "uuid": "64d9b118-e588-4dbb-99e1-6ef11e495ed5",
   "duration": "0.382404",
   "when": "20210107005140Z",
   "check": "IPACertfileExpirationCheck",
   "result": "ERROR"
 },
 {
   "source": "ipahealthcheck.ipa.certs",
   "kw": {
     "msg": "Unknown certmonger id 20191122115414",
     "key": "20191122115414"
   },
   "uuid": "1b4bba70-08e0-43dc-8984-657cc47fd339",
   "duration": "1.109733",
   "when": "20210107005142Z",
   "check": "IPACertTracking",
   "result": "WARNING"
 }
]
Â
How do I correct these issues?
They are two sides of the same coin. You have an unknown certificate request being tracked
by certmonger.
In this case the nickname host/idm2.X.Y in /etc/pki/nssdb.
Looks like there isn't a nickname with this value in that NSS database which explains
the first error.
I suspect that someone did some manual tracking changes and got this one wrong. It
isn't something that IPA would have configured.
Is it safe to delete this tracking request? Probably. But I'd double and triple check
before doing so. Its unclear what the original purpose of creating it was.
rob
9:01 a.m.
New subject: ipa healthcheck issue
Patterson, David via FreeIPA-users wrote:
Hello,
How or what does it use to compare with?
I see a cert in the nssdb with the correct nickname.
certutil -L -d /etc/pki/nssdb
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
host/idm2.x.y u,u,u
I also see the other side of the same coin....
getcert list -c IPA | grep -A15 20191122115414
Request ID '20191122115414':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/nssdb',nickname='host/idm2.x.y',token='NSS
Certificate DB'
certificate:
type=NSSDB,location='/etc/pki/nssdb',nickname='host/idm2.x.y',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=X.Y
subject: CN=idm2.x.y,O=X.Y
expires: 2021-11-22 11:54:15 UTC
principal name: host/idm2.x.y(a)X.Y
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Not sure that I want to delete either.
Ok, I figured it out. In early versions of IPA a host certificate was
always generated by ipa-client-install and stored in /etc/ipa/nssdb,
later moved to /etc/pki/nssdb. We never had a real use case for it but
thought that it could be useful as an identity cert at some point. That
point never happened. IIRC some time in the early 4.x series this
automatic generation was replaced with an option, --request-cert.
So you can safely stop tracking this cert if you aren't using it, or
leave the tracking if you are.
healthcheck doesn't currently handle this case so it's a false positive.
You can ignore it. I'll get this fixed upstream.
No promises on a backport.
rob
Thanks!
David Patterson
-----Original Message-----
From: Rob Crittenden <rcritten(a)redhat.com>
Sent: Monday, January 11, 2021 11:07 AM
To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
Cc: Patterson, David <dpatte(a)sandia.gov>
Subject: [EXTERNAL] Re: [Freeipa-users] ipa healthcheck issue
Patterson, David via FreeIPA-users wrote:
> Hello,
>
> Â
>
> Running RHEL 7.9, ipa 4.6.8-5 and freeipa-healthcheck 0.3-2 backported
> for RHEL 7.
>
> Â
>
> Ipa healthcheck output
>
> [
>
> Â {
>
> Â Â Â "source": "ipahealthcheck.ipa.certs",
>
> Â Â Â "kw": {
>
> Â Â Â Â Â "msg": "Unable to retrieve cert 'host/idm2.X.Y'
from
> '/etc/pki/nssdb': Failed to get host/idm2.X.Y",
>
> Â Â Â Â Â "nickname": "host/idm2.X.Y",
>
> Â Â Â Â Â "dbdir": "/etc/pki/nssdb",
>
> Â Â Â Â Â "key": "20191122115414",
>
> Â Â Â Â Â "error": "Failed to get host/idm2.X.Y"
>
> Â Â Â },
>
> Â Â Â "uuid": "64d9b118-e588-4dbb-99e1-6ef11e495ed5",
>
> Â Â Â "duration": "0.382404",
>
> Â Â Â "when": "20210107005140Z",
>
> Â Â Â "check": "IPACertfileExpirationCheck",
>
> Â Â Â "result": "ERROR"
>
> Â },
>
> Â {
>
> Â Â Â "source": "ipahealthcheck.ipa.certs",
>
> Â Â Â "kw": {
>
> Â Â Â Â Â "msg": "Unknown certmonger id 20191122115414",
>
> Â Â Â Â Â "key": "20191122115414"
>
> Â Â Â },
>
> Â Â Â "uuid": "1b4bba70-08e0-43dc-8984-657cc47fd339",
>
> Â Â Â "duration": "1.109733",
>
> Â Â Â "when": "20210107005142Z",
>
> Â Â Â "check": "IPACertTracking",
>
> Â Â Â "result": "WARNING"
>
> Â }
>
> ]
>
> Â
>
> How do I correct these issues?
They are two sides of the same coin. You have an unknown certificate request being
tracked by certmonger.
In this case the nickname host/idm2.X.Y in /etc/pki/nssdb.
Looks like there isn't a nickname with this value in that NSS database which explains
the first error.
I suspect that someone did some manual tracking changes and got this one wrong. It
isn't something that IPA would have configured.
Is it safe to delete this tracking request? Probably. But I'd double and triple check
before doing so. Its unclear what the original purpose of creating it was.
rob
_______________________________________________
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...
11:17 a.m.
New subject: ipa healthcheck issue
Patterson, David via FreeIPA-users wrote:
Hello,
How or what does it use to compare with?
I see a cert in the nssdb with the correct nickname.
certutil -L -d /etc/pki/nssdb
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
host/idm2.x.y u,u,u
I also see the other side of the same coin....
getcert list -c IPA | grep -A15 20191122115414
Request ID '20191122115414':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/nssdb',nickname='host/idm2.x.y',token='NSS
Certificate DB'
certificate:
type=NSSDB,location='/etc/pki/nssdb',nickname='host/idm2.x.y',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=X.Y
subject: CN=idm2.x.y,O=X.Y
expires: 2021-11-22 11:54:15 UTC
principal name: host/idm2.x.y(a)X.Y
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Not sure that I want to delete either.
Ok, I looked into this further and I was wrong again (a bit).
healthcheck does miss checking machine certificates but this isn't one
of them.
A machine cert gets installed into /etc/ipa/nssdb. My memory had things
backwards. We moved from /etc/pki/nssdb -> /etc/ipa/nssdb not the other way.
The nickname is inconsistent too. We currently use 'Local IPA host' and
in the distant past (3.0.0) it was 'IPA Machine Certificate - <fqdn>'.
So I can only assume that someone in the manually generated this request
for some reason.
rob
Thanks!
David Patterson
-----Original Message-----
From: Rob Crittenden <rcritten(a)redhat.com>
Sent: Monday, January 11, 2021 11:07 AM
To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
Cc: Patterson, David <dpatte(a)sandia.gov>
Subject: [EXTERNAL] Re: [Freeipa-users] ipa healthcheck issue
Patterson, David via FreeIPA-users wrote:
> Hello,
>
> Â
>
> Running RHEL 7.9, ipa 4.6.8-5 and freeipa-healthcheck 0.3-2 backported
> for RHEL 7.
>
> Â
>
> Ipa healthcheck output
>
> [
>
> Â {
>
> Â Â Â "source": "ipahealthcheck.ipa.certs",
>
> Â Â Â "kw": {
>
> Â Â Â Â Â "msg": "Unable to retrieve cert 'host/idm2.X.Y'
from
> '/etc/pki/nssdb': Failed to get host/idm2.X.Y",
>
> Â Â Â Â Â "nickname": "host/idm2.X.Y",
>
> Â Â Â Â Â "dbdir": "/etc/pki/nssdb",
>
> Â Â Â Â Â "key": "20191122115414",
>
> Â Â Â Â Â "error": "Failed to get host/idm2.X.Y"
>
> Â Â Â },
>
> Â Â Â "uuid": "64d9b118-e588-4dbb-99e1-6ef11e495ed5",
>
> Â Â Â "duration": "0.382404",
>
> Â Â Â "when": "20210107005140Z",
>
> Â Â Â "check": "IPACertfileExpirationCheck",
>
> Â Â Â "result": "ERROR"
>
> Â },
>
> Â {
>
> Â Â Â "source": "ipahealthcheck.ipa.certs",
>
> Â Â Â "kw": {
>
> Â Â Â Â Â "msg": "Unknown certmonger id 20191122115414",
>
> Â Â Â Â Â "key": "20191122115414"
>
> Â Â Â },
>
> Â Â Â "uuid": "1b4bba70-08e0-43dc-8984-657cc47fd339",
>
> Â Â Â "duration": "1.109733",
>
> Â Â Â "when": "20210107005142Z",
>
> Â Â Â "check": "IPACertTracking",
>
> Â Â Â "result": "WARNING"
>
> Â }
>
> ]
>
> Â
>
> How do I correct these issues?
They are two sides of the same coin. You have an unknown certificate request being
tracked by certmonger.
In this case the nickname host/idm2.X.Y in /etc/pki/nssdb.
Looks like there isn't a nickname with this value in that NSS database which explains
the first error.
I suspect that someone did some manual tracking changes and got this one wrong. It
isn't something that IPA would have configured.
Is it safe to delete this tracking request? Probably. But I'd double and triple check
before doing so. Its unclear what the original purpose of creating it was.
rob
_______________________________________________
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...
1196
days inactive
1196
days old
freeipa-users@lists.fedorahosted.org
2 comments
2 participants
participants (2)
-
Patterson, David -
Rob Crittenden