Learn more about these different git repos.
Other Git URLs
When resubmitting a certificate request (e.g. on change of template-hostname setting to request more SAN DNS names), if the certificate request fails and the tracking request ends up in state CA_UNREACHABLE, and if the certificate expiry is far off, the request is not retried.
CA_UNREACHABLE
After restarting certmonger, the stuck request is retried then. But the expected behaviour should be to periodically retry submitting the request.
CA_UNREACHABLE should retry after 60 seconds. Do you have a more specific reproducer?
Sure. On f31:
systemctl stop pki-tomcatd@pki-tomcat
getcert resubmit -i $REQUEST_ID
systemctl start pki-tomcatd@pki-tomcat
I suspect it is because the certificate expiry is still a way off, the retry is rescheduled at a time approaching the notAfter date.
The default delay is 7 days. If you set the certmonger debug level to 3 in /etc/sysconfig/certmonger you'll see something like:
Will revisit Request9('20200203213238') in 604800 seconds.
See cm_decide_ca_delay() in src/iterate.c for the full gory details of how the delay is computed and how the remaining time of the issued cert is considered.
@rcritten thanks for clarifying. So, not a bug then. 7 days does seem like quite a long time to wait for something that may be a transient error, though. Especially for human-initiated actions like getcert resubmit. Looking at the code, moving to a shorter delay with backoff seems like it would be an intrusive and high-risk change.
getcert resubmit
Another UX affordance could be to expose the "next renewal attempt at ___" in getcert list output, so users can at least see that the request will be retried at a particular time. What do you think?
getcert list
certmonger doesn't really distinguish between user-initiated and iterative actions AFAICT. I think from the certmonger perspective it's like "oh hey, a failure. Geez, it doesn't expire any time soon, may as well give the remote server to fix itself, there is no rush."
This of course doesn't take into consideration when the certificate is being modified in some way. I'd have to see how certmonger can tell when a new CSR is needed to see if that bit of state is available when unreachable happens.
Adding the next renew attempt would be a pretty useful thing overall. I'll take a look.
I was just bitten by this too. The initial cert req fails because the network is not up and running when the req. happens. I think if certmonger could look closer or the actual error and retry earlier would be great. I cannot wait for 7 days as the cert is needed for WiFi
ATM I am testing: --- ./src/iterate.c.org 2020-05-20 11:12:41.888410345 +0200 +++ ./src/iterate.c 2020-05-20 12:02:00.559646305 +0200 @@ -1061,7 +1061,8 @@ cm_submit_done(state->cm_submit_state); state->cm_submit_state = NULL; entry->cm_state = CM_CA_UNREACHABLE; - when = cm_time_delay; + //when = cm_time_delay; + when = cm_time_soonish; if (delay < 0) { *delay = cm_decide_ca_delay(remaining); }
getcert resubmit in this case is probably a better path in your case. It will re-send the request.
hmm, I THINK my problem comes from initial cert req. I haven't checked for sure. I have a late init script that tries to req. a cert. if xxxx.crt and xxx.key are missing. I can see there is just a xxx.key file and if I restart certmonger then I get a xxx.crt and the state is MONOTORING in getcert list
Login to comment on this ticket.