My theory was that multiple simultaneous validations performed by the staging server cause your server to drop network connections. That’s why I wanted you to try dry-run only a single certificate.
And it seems reproducible.
I can run on my own laptop:
certbot certonly -a webroot -w /tmp -d grandhighwizard.net -d darro.ch \
-d robin.darroch.id.au -d webdav.darroch.id.au -d www.darroch.id.au \
-d www.grandhighwizard.net -d www.robin.darroch.id.au \
--dry-run
and the result is mass timeouts.
If I get rid of the --dry-run (in other words, change from the staging to the live server), it changes from timeouts to the expected error (unauthorized/Invalid response).
If I keep --dry-run but reduce the domain count to only one domain, for me, it also changes to the correct error, the great majority of the time. To me, that confirms the network as being the cause.
There’s an important difference between the live and staging Let’s Encrypt servers.
The live server only makes one request per domain.
The staging server makes more like ~4 per domain.
4 * 8 domains = upto 32 requests simultaneously, enough for your internet connection or Apache to start timing out.
Combine this with your Apache logs complaining earlier about your MaxClients setting, add on that whatever network limits or firewalls macOS uses, and we have a hypothesis for why your dry-runs are timing out.