Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support verifying LWCA (SubCA) certmonger requests #307

Closed
rcritten opened this issue Oct 27, 2023 · 2 comments · Fixed by #308
Closed

Support verifying LWCA (SubCA) certmonger requests #307

rcritten opened this issue Oct 27, 2023 · 2 comments · Fixed by #308
Assignees

Comments

@rcritten
Copy link
Collaborator

healthcheck doesn't currently expect to see tracked LWCA certificates. These typically have the form of:

Request ID '20231027130916':
        status: MONITORING
        stuck: no
        key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickna
me='caSigningCert cert-pki-ca 9a93fc7f-4246-4986-af45-7d7f85dd136b',token='NSS C
ertificate DB',pin set
        certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='c
aSigningCert cert-pki-ca 9a93fc7f-4246-4986-af45-7d7f85dd136b',token='NSS Certif
icate DB'
        CA: dogtag-ipa-ca-renew-agent
        issuer: CN=Certificate Authority,O=EXAMPLE.TEST
        subject: CN=test
        issued: 2023-10-27 09:07:04 EDT
        expires: 2043-10-27 08:59:05 EDT
        key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
        profile: caCACert
        pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
        post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "caSigningC
ert cert-pki-ca 9a93fc7f-4246-4986-af45-7d7f85dd136b"
        track: yes
        auto-renew: yes

They are currently reported as a warning about an unknown tracked certificate.

We can fetch the CA UUID's from LDAP and build a template request for them so they no longer warn.

@rcritten rcritten self-assigned this Oct 27, 2023
@rcritten
Copy link
Collaborator Author

The failure looks like:

  {
    "source": "ipahealthcheck.ipa.certs",
    "check": "IPACertTracking",
    "result": "WARNING",
    "uuid": "4d31e52d-0da7-4434-8da8-2fc4bcae5e25",
    "when": "20231027151337Z",
    "duration": "1.124710",
    "kw": {
      "key": "20231027130916",
      "msg": "certmonger tracking request {key} found and is not expected on an IPA master."
    }
  }

@rcritten
Copy link
Collaborator Author

IPA does not generate a tracking request for subCA's after creation. One needs to run ipa-server-upgrade to add them.

rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue Oct 27, 2023
The LWCA ids are UUID4 format and are stored in LDAP so
we can retrieve the list (ignoring the ipa entry) and
construct what the request should look like.

Fixes: freeipa#307

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue Oct 27, 2023
This was causing a cache miss in the LDAPCache class. The
'*' + all default attributes was confusing the cache. We in fact
do not need all attributes so this is fine. This increases the
cache hits in cert.py from 7 to 24, reducing the number of
duplicate LDAP searches.

Related: freeipa#307

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue Nov 2, 2023
The LWCA ids are UUID4 format and are stored in LDAP so
we can retrieve the list (ignoring the ipa entry) and
construct what the request should look like.

Add a cache for the get_expected_requests() function. The
certificates aren't going to change (or shouldn't) in the
middle of a run and there is no point in duplicating several
LDAP requests for each call.

Fixes: freeipa#307

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue Nov 2, 2023
This was causing a cache miss in the LDAPCache class. The
'*' + all default attributes was confusing the cache. We in fact
do not need all attributes so this is fine. This increases the
cache hits in cert.py from 7 to 24, reducing the number of
duplicate LDAP searches.

Related: freeipa#307

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue Nov 6, 2023
The LWCA ids are UUID4 format and are stored in LDAP so
we can retrieve the list (ignoring the ipa entry) and
construct what the request should look like.

Add a cache for the get_expected_requests() function. The
certificates aren't going to change (or shouldn't) in the
middle of a run and there is no point in duplicating several
LDAP requests for each call.

Fixes: freeipa#307

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
rcritten added a commit to rcritten/freeipa-healthcheck that referenced this issue Nov 6, 2023
This was causing a cache miss in the LDAPCache class. The
'*' + all default attributes was confusing the cache. We in fact
do not need all attributes so this is fine. This increases the
cache hits in cert.py from 7 to 24, reducing the number of
duplicate LDAP searches.

Related: freeipa#307

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
rcritten added a commit that referenced this issue Nov 7, 2023
The LWCA ids are UUID4 format and are stored in LDAP so
we can retrieve the list (ignoring the ipa entry) and
construct what the request should look like.

Add a cache for the get_expected_requests() function. The
certificates aren't going to change (or shouldn't) in the
middle of a run and there is no point in duplicating several
LDAP requests for each call.

Fixes: #307

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
rcritten added a commit that referenced this issue Nov 7, 2023
This was causing a cache miss in the LDAPCache class. The
'*' + all default attributes was confusing the cache. We in fact
do not need all attributes so this is fine. This increases the
cache hits in cert.py from 7 to 24, reducing the number of
duplicate LDAP searches.

Related: #307

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant