Is your feature request related to a problem? Please describe.
When enabling the new ARI functionality, Certificate resources are populated with status.acme.ari fields. These fields will be regularly updated by querying the relevant endpoint, updating the suggestedWindow based on the server response.
If this check (or the regular scheduling) subsequently results in the renewal of the certificate, the corresponding ari fields are not updated. This effectively means that the status.renewalTime field is updated to contain some future timestamp based on an estimation while the status.acme.ari.suggestedWindow are still related to the previous certificate instance. Such a state may be confusing when observed.
I would suggest to implement some logic that will ensure these fields are reconciled in a way that aims to ensure they are 'consistent', i.e. the status.renewalTime value will be within the window status.acme.ari.suggestedWindow.
An example to illustrate:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata: {} # not relevant here
spec: {} # not relevant here
status:
acme:
ari:
lastChecked: '2026-07-09T09:09:27Z'
nextCheck: '2026-07-09T14:29:11Z'
suggestedWindow:
end: '2026-07-08T14:14:40Z'
start: '2026-07-08T11:03:50Z'
conditions:
- lastTransitionTime: '2026-07-09T09:09:52Z'
message: Certificate is up to date and has not expired
observedGeneration: 2
reason: Ready
status: 'True'
type: Ready
- lastTransitionTime: '2026-07-09T09:09:52Z'
message: The certificate has been successfully issued
observedGeneration: 2
reason: Issued
status: 'False'
type: Issuing
notAfter: '2026-07-16T00:11:19Z'
notBefore: '2026-07-09T08:11:20Z'
renewalTime: '2026-07-13T18:51:19Z'
Describe the solution you'd like
I think there are two approaches to ensure a 'consistent' state:
- reset/void the
status.acme.ari.suggestedWindow data whenever a certificate is renewed, given it should be considered outdated
- whenever a certificate is renewed, immediately follow up with an ARI request, to ensure the data is updated to match with the new certificate
Describe alternatives you've considered
Ignore the 'inconsistent' state and wait until the next scheduled ARI check.
Additional context
Environment details (remove if not applicable):
- Kubernetes version: n/a
- Cloud-provider/provisioner: n/a
- cert-manager version: 1.21.0
- Install method: n/a
/kind feature
Is your feature request related to a problem? Please describe.
When enabling the new ARI functionality,
Certificateresources are populated withstatus.acme.arifields. These fields will be regularly updated by querying the relevant endpoint, updating thesuggestedWindowbased on the server response.If this check (or the regular scheduling) subsequently results in the renewal of the certificate, the corresponding ari fields are not updated. This effectively means that the
status.renewalTimefield is updated to contain some future timestamp based on an estimation while thestatus.acme.ari.suggestedWindoware still related to the previous certificate instance. Such a state may be confusing when observed.I would suggest to implement some logic that will ensure these fields are reconciled in a way that aims to ensure they are 'consistent', i.e. the
status.renewalTimevalue will be within the windowstatus.acme.ari.suggestedWindow.An example to illustrate:
Describe the solution you'd like
I think there are two approaches to ensure a 'consistent' state:
status.acme.ari.suggestedWindowdata whenever a certificate is renewed, given it should be considered outdatedDescribe alternatives you've considered
Ignore the 'inconsistent' state and wait until the next scheduled ARI check.
Additional context
Environment details (remove if not applicable):
/kind feature