Mutiple dns-cloudflare requests do not copy all certs to /live

My domain is: trumail.pro and trumail.app

I ran this command: certbot certonly -d trumail.pro,*.trumail.pro -d trumail.app,*.trumail.app
(Everything else is in cli.ini)

It produced this output: Success

My web server is (include version):

The operating system my web server runs on is (include version): Ubuntu 20.04.6 LTS 64 Bit

My hosting provider, if applicable, is: RackNerd VPS

I can login to a root shell on my machine (yes or no, or I don't know): YEP

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Nope

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 2.8.0

The Issue: The second set of domains, trumail.app, did not recive the certs to the /live directory. Weird!
But running 'certbot -d trumail.app,*.trumail.app' alone for a second request did copy them down.

The question: Did I miss something for it to make the copy of all requested domains in the /live directory?

Thanks Ya'll

  • Cory C.

Normally each Certbot command gets one cert which contains all the domain names in the -d options. And, normally you either repeat the -d with a single domain multiple times. Or, have one -d with a comma delimited list of domains.

This is the first time I have seen someone try two -d each with a comma delimited list. Based on your description it sounds like all the names in each -d option were combined.

What does this show

certbot certificates
4 Likes

Well, after the second request for trumail.app, the cert was received, but verification was already completed in the 1st request, so it verified them all at the 1st request. I've seen a lot of examples done this way. I assume to make seperate certificates for each -d request.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: trumail.app
    Serial Number: 459d220f63a0c2377c76aa47b7218e564cb
    Key Type: ECDSA
    Domains: trumail.app *.trumail.app
    Expiry Date: 2024-03-28 01:20:56+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/trumail.app/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/trumail.app/privkey.pem
  Certificate Name: trumail.pro
    Serial Number: 497c5a26845f1d6fa85a33ece91cb9fbd18
    Key Type: ECDSA
    Domains: trumail.pro *.trumail.app *.trumail.pro trumail.app
    Expiry Date: 2024-03-28 01:14:56+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/trumail.pro/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/trumail.pro/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Notice that the timestamps are 6 minutes apart.

No, you can see from the certbot certificates that your first command got one cert with all 4 names in it. And, your second command with just 2 names got a cert with those 2.

You are correct that domain name authorizations for the same account are cached (currently) for 30 days. But, this does not affect the cert that is issued. It only affects the ACME API flow for the authorizations.

Looks like 6 minutes but who is counting :slight_smile:

3 Likes

Yeah, I updated that before I saw your reply . . . OOPS! :stuck_out_tongue_winking_eye:
Thanks, I ddin't notice that it had all 4. Hmm.
Well, I gues that's just how it works then. I'll make a permanent note.

  • Cory C.
3 Likes

Last comment, There's a lot of bad info out there. Friggen Internet!
It took me forever to figure out the correct installs and config to use Tokens with dns-cloudflare.

  • Cory C.
2 Likes

Had you seen this?

https://certbot-dns-cloudflare.readthedocs.io/en/stable/

3 Likes

I did, but nowhere in there did it say to use Snap to install dns-cloudflare, which I found to be the only option I could find that allowed Token use.

2 Likes

If you only need one of the two certs, then you should delete the unused cert.
certbot delete --cert-name trumail.app

Then recheck with:
certbot certificates

4 Likes

Yes, good idea.
Thank you.

1 Like

There's a "Note:" at the top of that page referring to the "Wildcard" tab of the instruction generator at Certbot Instructions | Certbot. For almost all OSses, it will generate the snap instructions.

3 Likes

Yes, and that was easy to find, but the Cloudflare plugin was vague and missing the "You gotta' use the Snap version for Tokens" part.

There's no need to use snap specifically to use tokens. I use tokens and don't use snap (can't even use it on my OpenRC system).

3 Likes

But the Cloudflare Token requires a version of dns-cloudflare that is compatible with token use. I tried everything the "Internet" told me to use and they all required the Global API and user email to work. I didn't want that and really had to dig to find just one tidbit that pointed me to install dns-cloudflare through Snap.
Thank you.

1 Like

Yes, support was added in the 1.2.0 version of certbot-dns-cloudflare.

Unfortunately, the internet is full of )#*$() as you've already seen.

As you should indeed.

Snap is actually the recommended method of installing Certbot.

I'm guessing you used to use Certbot from Ubuntus own packages. For 20.4 LTS that's unfortunately frozen at an ancient version of 0.39.0. That's the (very great) downside of distributions using such a package management.
Compare this with the rolling release distributions such as Arch or Gentoo: no issues there, almost always you'd get one of the most recent versions of a package.
And an alternative, not directly recommended, would be to use the pip method of installing Certbot (also mentioned on Certbot Instructions | Certbot). This also installs the most recent version, just like snap, but is way harder to maintain.

Thus, you see, snap is not the ONLY method of installing a compatible version of the plugin.

3 Likes

Amen to that!

3 Likes

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