Thank you for the detailed issue report.

Dogtag can and should handle this scenario better. In particular, ACMEChallengeService.handlePOST should retry the challenge if state is "invalid" and can safely "do nothing" when state is "processing" or "invalid". (For "processing" state, it might be best to reset counters/timers or restart the validation thread).

BUT, this is also a bug in cert-manager. Its behaviour deviates substantially from RFC 8555. In particular, https://tools.ietf.org/html/rfc8555#section-7.5.1 states:

   Usually, the validation process will take some time, so the client
   will need to poll the authorization resource to see when it is
   finalized.  For challenges where the client can tell when the server
   has validated the challenge (e.g., by seeing an HTTP or DNS request
   from the server), the client SHOULD NOT begin polling until it has
   seen the validation request from the server.
   To check on the status of an authorization, the client sends a POST-
   as-GET request to the authorization URL, and the server responds with
   the current authorization object.  In responding to poll requests
   while the validation is still in progress, the server MUST return a
   200 (OK) response and MAY include a Retry-After header field to
   suggest a polling interval to the client.

Instead of polling the authorization resource as specified by RFC 8555, cert-manager is re-POSTing the challenge response. Therefore please also raise a ticket against cert-manager, if you have not done so already.

I'm going to mark this as done as the upstream pki ticket has been resolved.