Thanks. This looks like a Certbot bug to me.
In your order, all 3 authorizations are already fulfilled (because you have completed the requisite challenges “recently enough” on the same Let’s Encrypt account). So in reality, Certbot doesn’t need to do anything - it can in theory issue a certificate without doing any domain validation tasks.
Now, to the bug. Certbot creates a new order, as requested by you, and encounters this authorization, which was previously completed using the HTTP challenge.
At some point last year, Let’s Encrypt’s ACME server, Boulder, started deleting unused challenges, so they no longer appear in the server’s response. (e.g. If you completed an authz using the DNS challenge, then HTTP and ALPN become unused).
So, if we click onto that authorization, we see that only the http challenge is available. Notably, dns is missing, because it was deleted as unused.
I believe that Certbot is freaking out because the dns challenge is missing in that server response, even though the authorization is already complete.
I was able to reproduce this using Certbot 0.27 using this invocation:
# First issue a cert using HTTP, so that we get a valid authorization on our account
certbot certonly -d foo.monkas.xyz -a manual --preferred-challenges http
# Then try force renewing, forcing DNS challenge in Certbot
certbot certonly -d foo.monkas.xyz -a manual --preferred-challenges dns --force-renewal
What Certbot should be doing is checking that the authorization is already valid, and therefore avoid pointlessly crashing.
I think what you should do is just remove the --preferred-challenges flag from your command for now. It will allow you to renew your certificate.
In the meantime, I’m going to check whether this affects the latest version of Certbot and file a bug for it if so.