#227 Address existing mal-formed CSRs that may be stored by certmonger
Opened by rcritten. Modified

Issue https://pagure.io/certmonger/issue/223 outlined how certmonger is generating an ill-formed CSR by encoding default values. The underlying problem is fixed and any requests generated after updating to the latest certmonger will remove this issue.

The problem is existing certmonger deployments. certmonger stores the generated CSR and if the underlying request parameters have not been modified then it will re-use the existing one. This will result in submitting malformed CSRs which may be rejected depending on the parser on the other side.

I suspect this will be particularly challenging in the future where at the time "older" certmonger clients are connecting with newer services with correct parsers. The "if it ain't broke, don't fix it" approach of some administrators to only update packages on very old systems when absolutely necessary may end up backfiring, leaving them vulnerable to failed renewals.

Some ideas to address this:

  • Create a script/program that can be run in rpm %post or by a user to examine all stored CSRs and remove/replace them. Potentially marking them in some way as having been replaced via a new field in the tracking request.
  • Create documentation how how a request fails when a bad CSR is presented to various CA's so that troubleshooting help can be found.
  • add an ipa-healthcheck rule that validates all CSRs

I have an idea that might be even easier to implement: Always generate a new CSR when certmonger renews a certificate. CSR creation is not performance critical. The slowest element is the RSA signature and even that is pretty fast.

Certmonger may already do the sensible thing and re-create a CSR on every update request. The first state of ipa-getcert resubmit is GENERATING_CSR.

I can an experiment to confirm my findings:

# vi /var/lib/certmonger/requests/20211008100906
(add some junk to csr field)
# systemctl restart certmonger
# ipa-getcert resubmit -v -w -f /var/lib/ipa/certs/httpd.crt 
Resubmitting "20211008100906" to "IPA".
State GENERATING_CSR, stuck: no.
State SUBMITTING, stuck: no.
State POST_SAVED_CERT, stuck: no.
State MONITORING, stuck: no.

Does renew on expiration also go through the GENERATING_CSR state?

An automatic renewal will also go through CM_NEED_CSR -> GENERATING_CSR so as long as certmonger has been updated on the machine (once updated packages are universally available) then this problem will go away.

Metadata