Our current retrying policy applies exponential backoff to the following states:
- CSR_PUSHED
- CHALLENGES_VALIDATED
- CHALLENGES_PUSHED
And slow retries (1 day) to:
- CHALLENGES_REJECTED
- CERTIFICATE_ISSUED
At the same time, certcentral will set the status of a certificate to SELF_SIGNED when a non-recoverable error is found during the certificate issuance process.
Let's consider a brand new certificate, on config reload certcentral assigns the status INITIAL, generates the self signed certificate and moves it to SELF_SIGNED status. After that, certcentral will attempt to get a valid certificate from the configured ACME directory. If the process fails with a non-resumable error like the one described in T207737 certcentral will end setting the status again to SELF_SIGNED:
INITIAL --> SELF_SIGNED --> LE rejects the CSR --> SELF_SIGNED --> LE rejects the CSR --> SELF_SIGNED...
This is exactly the behaviour observed in the logs attached in T208326.
Certcentral must consider this as an additional status where the retrying policy is honoured rather than abusing the SELF_SIGNED status to restart the certificate issuance process from cercentral's point of view.