Is there an easy way to tell certbot doing --expand to ONLY expand the cert?

Help
#1

I had originally forgotten to include the mail domain for all my 50+ certs for the virtual hosting I'm doing, and I'm trying to fix them by writing a script to automate this to make my life manageable into the future.

I've run into what I think of as a bug with certbot, but it MIGHT BE because "I'm just not using it properly".

In particular, if I run a command such as:

$ certbot --expand -d primaryDomain.com,www.primaryDomain.com,mail.primaryDomain.com

Certbot throws up a complaint about how it can't tell what of the 50+ certificates I have should be updated, which is patently ridiculous.

NOTABLY, this confused me at first as I thought the command had not already updated the certificate. Rather, upon experimentation, it has in fact created the new certificate, and I STRONGLY SUSPECT it is asking this question because it thinks I want it to update the web server virtual hosting configuration, which I do not want it to do.

Since I need this to run in a script, the prompting is problematic for other reasons...

...In my opinion, as great as certbot is, its documentation could use some help... Is there an option I can use to suppress this behavior? And, I also think the messages should be more clear about what this second phase is all about (and that it already expanded the cert).

Thanks for your thoughts.

1 Like
#2

If you know which certificate you want to update the domains for, you can tell Certbot, and it won't bother trying to figure out the matching and domain overlap with the other 49:

--cert-name example.com -d example.com -d www.example.com -d mail.example.com

I guess that depends on what the other certificates are.

If the --expand allows Certbot to unambiguously figure out what certificate you mean to update, then it shouldn't prompt you.

2 Likes
#3

Hi _az, thanks for the reply.

I was trying to be clear; the certificate was updated properly! THERE WAS NO ACTUAL CONFUSION!

It's my assertion - and I might be wrong, as I haven't read the code much less written it! - that the update of the cert went fine and it's now in a second phase which is trying to figure out how to update my Apache configuration. ... At least, that's my guess.

I'm thinking that adding

certonly

will stop it from doing this but I'm trying to KNOW before I launch my effort - doing this one at a time is no fun since there are multiple domains in each cert and all too often they don't have the same pattern as all the others, so an automation tool that looks at the certs, one at a time, and intelligently asks for new certs to be created makes most sense.

Note that as these are primarily about adding mail as a subdomain that was simply overlooked originally, my Apache configuration can't help, and I think that's where it's getting stuck and prompting to be told which Apache config to update - which I don't want at all. ... That's what I tried to say in my initial question - sorry if I wasn't clear.

Does "certonly" fix this?

1 Like
#4

In that case, certonly might be what you want, yes.

One thing that is not obvious without carefully reading the docs is that:

certbot --expand -d example.com,www.example.com,mail.example.com

is really:

certbot run --expand -d example.com,www.example.com,mail.example.com

That (default) run subcommand tries to automatically tries to identify a combined installer/authenticator suited to your server (e.g. apache or nginx), and then uses it to acquire and install the certificate.

You can substitute run with certonly. Since it does not install certificates, you will only be required to specify the authenticator, but I think it should do what you want.

1 Like
#5

If I understand what you are trying to do well enough, I believe that you should...

  1. grep through the Certificate Name: and Domain: lines of sudo certbot certificates to determine the existing certificate and domain names
  2. use the following:
    sudo certbot certonly --cert-name $certname --apache (or --nginx) -d "maildomain,$existingdomainnames" --keep
1 Like
#6

Thanks again _az,

... I don't recall how to specify the authenticator, ATM, but I thought that for already existing certificates, adding a sub-domain isn't a problem? Hmmm...

... Since I used Apache to authenticate originally, do I do it like this:

$ certbot certonly --preferred-challenges apache --expand -d example.com,www.example.com,mail.example.com

or maybe

$ certbot certonly --apache --expand --cert-name example.com -d www.example.com,mail.example.com

?

1 Like
#7

I just gave you the answer (and the strategy). :slightly_smiling_face:

--apache and --nginx specify their respective authenticators

1 Like
#8

That looks right to me.

I think it's unfortunately still the case that you have to specify all of the original arguments again - they're not inherited.

2 Likes
#9

Isn't that conflicting?

I'm pretty sure --cert-name is more powerful than --expand (and used instead of --expand).

Consider using --cert-name instead of --expand, as it gives more control over which certificate is modified and it lets you remove domains as well as adding them.

1 Like
#10

YES, griffin, apologies, I didn't notice your reply until just now! Oops!

And, indeed, I already have code running certbot certificates to figure out each certificates domain contents and am already parsing them. I'm at the "OK, now what" phase of script development and would prefer not to screw up and have any down time for my sites!

And, indeed, certonly, and as you're saying, specify the cert-name instead of asking for expand... Got it!

I'm not familliar with --keep yet!

And, BTW, you've replied while I'm replying, that was a typo I was about to fix regarding BOTH --expand and --cert-name! Good catch, thanks! :smiley:

Thanks to BOTH you, griffin, and _az!

As an aside, I think I also need either -n or --noninteractive since it's inside a script...

2 Likes
#11

You don't need non-interactive if you follow my original reply. Notice the --keep? That automatically keeps your existing certificates where the domain names have not changed to prevent you from being prompted in the case of duplicate certificates. "Accident proofing"

I think you're on a good road. _az already had you on the right path. I just wanted to give you a strategy. If you run into any trouble though, just let us know. :+1:

1 Like
#12

And I curse at this fact daily... :grin:

certbot --expand -d example.com,www.example.com,mail.example.com

error: unspecified command

Now that's better. :upside_down_face:

@_az

Speaking of...

https://community.letsencrypt.org/t/how-i-wish-certbot-worked/138258

1 Like
#13

DARN, griffin?! I went to your how I wish certbot worked page and got:

Oops! That page doesn’t exist or is private.

You sure know how to make someone unhappy! :upside_down_face:

1 Like
#14

:grin:

That was for @_az. You need to become a regular, leader, moderator, staff, or the great and powerful _az to see that.

2 Likes
#15

The Wonderful Wizard of _az!

2 Likes
#16

Pay no attention to the man behind the curtain!

1 Like
#17

If I know him at all, I'd say he doesn't want the attention anyhow.

:rofl:

1 Like
#18

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.