About renewal using eab-key

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 .

Thank you

EAB credentials are only used when your account is being registered.

2 Likes

To satisfy yourself that your specific renewal would work try

sudo certbot renew --dry-run --cert-name xyz.edu
4 Likes

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.

5 Likes

Oh right. I think by adding --server url after --dry-run it might work with their CA

4 Likes

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 ?

1 Like

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 :slight_smile:

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

5 Likes

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..

4 Likes

Or pay another $ 100 for a useless duplicate certificate :exploding_head:

2 Likes

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.

3 Likes

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.)

5 Likes

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. :slightly_smiling_face:

--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)

https://eff-certbot.readthedocs.io/en/latest/using.html#certbot-command-line-options

2 Likes

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 .

1 Like

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.

2 Likes

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.

2 Likes

It also won't save the acquired certs to disk and provide other such testing functionality.

I suppose what I'm saying is that one can use dry-run independently of the staging server.

2 Likes

Sure, but, if you are using a production --server with --dry-run why are you concerned about overlaying prior certs?

3 Likes

Let's just say there's a niche application for it when it comes to these kind of special circumstances.

2 Likes

When you're testing configuration changes and such, you might not want to replace certs and restart web servers.

3 Likes

sudo certbot renew --dry-run --server XXXX

Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/r0-mysql.umich.edu.conf


Simulating renewal of an existing certificate for r0-mysql.umich.edu and r0-db.umich.edu
Terminated

This is what I got back from the dry run and looks like it worked .

2 Likes