Implement --dry-run flag

[maxxer]

It should run certbot --statging to test webserver setup with more gentle request rates.

https://letsencrypt.org/docs/staging-environment/

[jjakob]

I've had a consideration on how this should be done:

certbot has 2 different "dry run" type modes (certbot-auto --help testing):

1. --test-cert/--staging obtains a certificate issued by a self-signed (invalid) CA that isn't in the client certificate stores. This means we can't then do zmcertmgr verify as we can't get the CA from the system, we'd have to download it from letsencrypt's site, which seems hacky. If we skip zmcertmgr verify, I don't see the point. Perhaps it can be useful for testing the server setup before actually obtaining the real certificate, but it's still possible the subsequent real run will fail.
2. --dry-run obtains a test (invalid) certificate but doesn't save them to disk. Again, this is perhaps useful for testing the nginx setup, but not for zmcertmgr verify.

I'd say we do --dry-run, just to test the nginx setup and network ports, and exit before starting the deploy steps. Then the production certs can be obtained and deployed for real. Even if the deployment fails, rerunning certbot certonly will always ask the user if he wants to keep the existing certificate or request a new one, in which case he should select to keep it, and the deployment will deploy it. (unless he requested a staging cert before for the same domain, in which case he needs to request a new one and overwrite it).

Staging certs can always be done through --letsencrypt-params "--staging", but as mentioned above, they won't work to deploy because we need to download the staging CA.

So it's not that simple to do, and is a compromise in any case.

[jjakob]

This is how it looks when requesting a staging cert for an already existing domain:

Running /usr/local/bin/certbot-auto certonly  --test-cert --webroot -w /opt/zimbra/data/nginx/html --expand -d foo.bar
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/foo.bar.conf)

What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1 
Keeping the existing certificate

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate not yet due for renewal; no action taken.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Preparing certificates for deployment.

I'm not sure why it says the limit is 5 per 7 days if the staging servers have a higher rate limit, perhaps it's a bug in certbot.

[maxxer]

As you noted I'd use this just to test nginx config, which is as of today the biggest cause of trouble. I can't recall many times when real deployment fails.

We can choose to implement --dry-run and exit after certbot successfully run with --staging with a message saying nginx config has been tested successfully.

Otherwise, in order to be less misleading, the param could be called --test-nginx and do the same.