Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is: umich.edu
I ran this command: sudo certbot certonly --standalone --non-interactive --agree-tos --email email-id --server url --eab-kid xxxxxx --eab-hmac-key yyyyyyyyy --domain xyz.umich.edu --cert-name xyz.edu
It produced this output:
My web server is (include version): no webserver
The operating system my web server runs on is (include version): Linux
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know): yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 2.11.0
My question is , I don't have a webserver on my machine . I ran the above command and used the eab-kid and key in command line to request the certificate . Should I explicitly mention the eab-kid and eab-hmac-key in the renewal conf file for renewal to happen or does certbot know the options used in command line during renewal .
Well, dry-run might be misleading in this case, since it will use Let's Encrypt's staging server, even though the "real" cert is using some other CA. It'll check whether the server is accessible and such, but won't confirm that the production configuration is using the EAB settings.
Dry-run fails with a firewall port 80 error ( there is no staging server I guess ? ) . But this command works , **sudo certbot renew --force-renewal --deploy-hook /tmp/script.sh ** . Is this good enough to ensure that renewal works without the eab settings in conf file ?
No, Peter made good point that --dry-run sets the Let's Encrypt Staging server. You look to be using some other CA since you used --server in your first post. And, LE does not require EAB
As for --force-renewal, be careful to only use that once and not for your regularly scheduled renew. You'd end up getting a cert each time which might cause problems with your CA.
And, I'd avoid using --deploy-hook for renew command because that should already be in your renewal profile from your first command. See the /etc/letsencrypt/renewal folder for these profiles
I'm not sure my --dry-run suggestion works as-is with alternate CA. I know there was some sort of trick about adding --server URL but not sure if that actually works with --dry-run or was some other context.
Update: I found a previous thread which talks about --dry-run and --server. Should work
I think you've got the right idea, @MikeMcQ. A dry run is just an easy way of setting the server to staging and not installing the resulting cert. One can do that manually with any CA using certonly and --server STAGING_URL without using --dry-run..
Yeah, but --dry-run ensures the certs won't overlay your "non" dry-run certs, as you note. At least it does with regular certbot renew but now I am not certain it does when adding --server-name after --dry-run. My original thinking was that it did which is why I suggested it.
But, using certonly with --server Staging_URL will overlay any prior cert. With LE, at least, Certbot has some protection and sometimes need --break-my-certs to do that. I'm not sure all of the cases this is needed. If Staging_URL is an actual trusted CA then this doesn't matter but if it was an actual test CA system it does.
I regret suggesting --dry-run with alternate CA. I don't fully appreciate all the quirks that can result. Requires deeper evaluation probably on a per-CA basis.
And it doesn't help that many CAs don't have analogous staging environments like Let's Encrypt does. (I think Google and Buypass Go do, but I don't think there are many others.)
Haven't ever seen anyone use that in the field. I believe it's used with this, which should clear up some mysteries. Without the --break-my-certs option, I believe --staging does not save/overwrite the certs.
--test-cert, --staging
Use the Let's Encrypt staging server to obtain or revoke test (invalid) certificates; equivalent to --server https://acme- staging-v02.api.letsencrypt.org/directory (default: False)
--dry-run
Perform a test run against the Let's Encrypt staging server, obtaining test (invalid) certificates but not saving them to disk. This can only be used with the 'certonly' and 'renew' subcommands. It may trigger webserver reloads to temporarily modify & roll back configuration files. --pre-hook and --post-hook commands run by default. --deploy-hook commands do not run, unless enabled by --run-deploy-hooks. The test server may be overridden with --server. (default: False)
As you mentioned , the staging environment is disabled for Incommon in my organization . As an alternate to see if the renewal works and also to check if deploy script works , without mentioning the eab key in the conf file , I tried sudo certbot renew --force-renewal --deploy-hook /tmp/script.sh. It's a test server I tried and just wanted to make sure this is valid .
Per my post above with certbot syntax, you can always point the dry-run at the production URL with --server and get all the testing benefits of a staging dry-run except with the lower rate-limits of production. It's unorthodox, but can work in a pinch.
The only benefit of this I can think of is that --dry-run disables existing cached valid authorizations and thus will always require a new authorization.
Depending on the CA used, using a production API might cost you money though.
