Have you tried --staple-ocsp? I think you generally need to specify the --must-staple part on first creating the certificate and it won't have an effect for renewals. See also: Certbot enhance --must-staple - #3 by Xan
Do you actually need to use the --csr option? It disables most of Certbot features:
You cannot auto-renew AFAIK;
The certificates are saved in the current working directory, not in the usual /etc/letsencrypt/ location and they count up from 0000 I believe if new certificates are issued. There is NO symbolic linking to the most actual certificate/chain, so you'd either need to script something yourself to keep the actual certificate in the correct place, do that manually or manually reconfigure your service to point to the correct certificate. Note that certificates are only valid for 90 days and LE recommends to renew after 60 days.
Many options of Certbot don't work any longer.
My advice is not to use the --csr option. Maybe you require an option not available in your older version as @webprofusion already stated and you are required to resort to the --csr option? In that case I recommend to upgrade your Certbot, perhaps not using the package of your distribution, but change to the "snap" distributed version. Or "pip" if snap isn't an option.
I fail to see why deploying a non-standard webserver would require the --csr option? I would urge not to use that option as it complicates almost everything.
If you really require a wildcard certificate (which is often not the case, even if people think they require a wildcard.. Let's Encrypt certificates can contain up to 100 hostnames per certificate, so lots of room for many subdomains..) then yes, the dns-01 challenge is indeed necessary unfortunately.
As part of the automation to get a wildcard certificate I call certbot now with the option --manual-auth-hook to do the requested DNS changes automatically, but LE caches successful verification per DNS for some time (30 days?) and my script will not be called. Is there a way to enforce validation again (instead of waiting until it expires)?
When Certbot is being run with the --dry-run option, it won't reuse already valid authorizations. The --dry-run option also uses the staging environment, which should also be the environment used for testing, so that's a win-win.