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

Don't error in DogtagCertsConnectivityCheck with external CAs #286

Merged
merged 1 commit into from
Jul 19, 2023

Conversation

rcritten
Copy link
Collaborator

The serial number of externally-signed CA's were being checked using ipa-cert-find which invariably would return a not found error.

Instead return SUCCESS to effectively skip the check.

Fixes: #285

Copy link
Contributor

@flo-renaud flo-renaud left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @rcritten
if IPA is installed with embedded CA, the connectivity check can use the RA cert in all the cases (self-signed or externally signed CA), as this cert always exists and can be found with PKI API.

@rcritten
Copy link
Collaborator Author

rcritten commented Apr 7, 2023

Excellent observation! Implemented.

Copy link
Contributor

@flo-renaud flo-renaud left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @rcritten
thanks for the update. Minor nitpicks, not related to this patch but that could be fixed with it:

  • line 141, the message is missing a closing }
  • lines 126, 132 and 138, we could replace the key 'cert_show_1' with 'cert_show_ra'

I tested the following scenarios with an externally-signed CA:

  • missing RA cert file
  • RA cert file contains a cert inconsistent with what is stored in LDAP
  • pki stopped
    All the above issues were properly reported.

src/ipahealthcheck/dogtag/ca.py Outdated Show resolved Hide resolved
The purpose of the check is to validate that communication
with the CA works. In the past we looked up serial number 1
for this check. The problem is that if the server was
installed with RSNv3 so had no predictable CA serial number.

It also was broken with externally-issued CA certificate which
cannot be looked up in IPA.

Instead use the IPA RA agent certificate which should definitely
have a serial number in the IPA CA if one is configured.

Fixes: freeipa#285

Signed-off-by: Rob Crittenden <rcritten@redhat.com>
@rcritten
Copy link
Collaborator Author

thanks for the update. Minor nitpicks, not related to this patch but that could be fixed with it:

* line 141, the message is missing a closing }

Fixed.

* lines 126, 132 and 138, we could replace the key 'cert_show_1' with 'cert_show_ra'

Done. I modified the test expectations as well, including the typical serial number for the RA (it doesn't really matter in the end but non-zero is more obvious)

Copy link
Contributor

@flo-renaud flo-renaud left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rcritten
thanks for the update, works for me. I tested the following scenarios with an externally-signed CA:

  • missing RA cert file
  • RA cert file contains a cert inconsistent with what is stored in LDAP
  • pki stopped

All the above issues were properly reported.

@flo-renaud flo-renaud added the ack label Jul 19, 2023
@rcritten rcritten merged commit 29855ec into freeipa:master Jul 19, 2023
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

error when the IPA is intialised with an extern CA
2 participants