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:
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.
ipa-getcert resubmit
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.