I did find this is cermonger log:
2021-03-10 14:58:26 [26058] CA6('cepces').renewal_reqs moved to state 'REFRESHING'
2021-03-10 14:58:26 [26058] Will revisit CA6('cepces').renewal_reqs on traffic from 84.
2021-03-10 14:58:26 [26058] CA6('cepces').encryption_certs retrieval unsupported
2021-03-10 14:58:26 [26058] CA6('cepces').encryption_certs moved to state 'DISABLED'

I am not sure what to make of that though

What is cepces?

getcert list-cas -c cepces

https://github.com/ufven/cepces

It is a plugin to certmonger:
cepces is an application for enrolling certificates through CEP and CES. It currently requires certmonger to operate, but may eventually be extended to a standalone application

Only simple deployments using Microsoft Active Directory Certificate Services has been tested.

I can get a cert using getcert request -w -v -M 644 -c cepces -T Machine -I MachineCertificate ....

getcert list shows this cert as monitored

I think you'll need to contact the owner of the plugin. It looks like certmonger is attempting a renewal and a new cert is not being obtained.

You can increase some log output by adding -d3 to your certmonger invocation (e.g. in RHEL/Fedora you can create /etc/sysconfig/certmonger with the contents OPTS=-d3 and restart certmonger).

That will increase debugging to point where the helper is called. It looks like there is a logging config for cepces so perhaps increase that to DEBUG to see what is happening.

This is odd, if I delete the old and req. a new cert( getcert request -w -v -M 644 -c cepces ...) I can do
getcert resubmit -i MachineCertificate -v -w
Resubmitting "MachineCertificate" to "cepces".
State GENERATING_CSR, stuck: no.
State SUBMITTING, stuck: no.
State SAVING_CERT, stuck: no.
State MONITORING, stuck: no.

just fine.

But older existing certs is stuck with NEED_CA but still valid to June 2021.
I don't understand..

ahh, now I see. If I do
getcert stop-tracking -k /etc/machine.key -f /etc/machine.crt -T Machine -I MachineCertificate
and then
getcert start-tracking -k /etc/machine.key -f /etc/machine.crt -T Machine -I MachineCertificate

then I get

> getcert resubmit -i MachineCertificate -v -w

Resubmitting "MachineCertificate".
State GENERATING_CSR, stuck: no.
State NEED_CA, stuck: yes.

> getcert list

Number of certificates and requests being tracked: 1.
Request ID 'MachineCertificate':
status: NEED_CA
stuck: yes

So it seems stop/start tracking looses something so resubmit fails.
I am building certmonger from src(Gentoo dist) so I can test patches.

So I found it, one must add -c cepces to start-tracking

certmonger is basically a big state machine.

A "ca" is defined in certmonger to handle communication using a helper script that takes environment variables to pass information like request type, storage locations, etc.

certmonger tracks resulting certs and will re-invoke the "ca" to do renewal.

So the fact that a certificate has not been renewed is not a bug in certmonger, but in the "ca" provider (cepces) since the logs show that certmonger invoked it.

Sure, it was user error.

I am working on a script to fix all our machines and I wonder, can I do a
getcert resubmit (or rekey) .. for a already expired cert ?

It depends partly on how the CA helper handles things. resubmit will try to reuse the existing CSR. Depending on the helper there may be additional shortcuts. For example with the dogtag CA, attempt to renew using the existing serial number.

A rekey would probably be treated as a brand new request so I'm not sure how the helper would react.

We do automatic cert deployment and we notice that if the network isn't up, we never get a cert. from certmonger. Is there a way to request a initial cert from certmonger
that will be executed automatically once the network is up an the CA is reachable?

certmonger will retry a failed request but it doesn't do active monitoring. It uses a schedule to retry requests. The retry times are hardcoded and for CA_UNREACHABLE it is one week until retry. These timeouts were designed for renewing existing certs and not requesting new ones. It is expected that the requester would noticed the a new cert was not issued.

Forgot to answer, sorry.

Could something be added to certmonger so that requesting an initial cert will make certmonger to retry often until a cert is received?

Not within certmonger without changing the hardcoded retry values, but as a use you can check the status and use getcert resubmit <option> to try again.