ACME challenge and certificate issurance via CNAME (hosting)

Help
1

Hi. I'm trying to test a LetsEncrypt setup that I can use to apply letsencrypt certificates for my customers 3rd-party domains, using CNAME.
I've used the following documentation as inspiration: https://letsencrypt.org/2019/10/09/onboarding-your-customers-with-lets-encrypt-and-acme.html

My domain is: Loyaltykey.com and it's using Cloudflare DNS only.
My test domain (clubloyalty.dk) is hosted at a 3rd party and I've created 2 CNAME records. One for the ACME challenge and one for the homepage.
My ACME challenge CNAME record looks like this:

_acme-challenge.clubloyalty.dk CNAME 3600 clubloyalty.loyaltykey.com

On my loyaltykey.com domain I've created a TXT record that looks like this:

clubloyalty.loyaltykey.com TXT _acme-challenge.clubloyalty.dk

I ran this command:
certbot certonly --cert-name test.clubloyalty.dk --dns-cloudflare --dns-cloudflare-credentials /path/to/cloudflarecreds --server https://acme-v02.api.letsencrypt.org/directory -d "test.clubloyalty.dk" -d clubloyalty.dk

It produced this output:
Unable to determine zone_id for clubloyalty.dk using zone names: [u'clubloyalty.dk', u'dk']. Please confirm that the domain name has been entered correctly and is already associated with the supplied Cloudflare account.

... So it looks like the ACME challenge passed, but I cant figure out why it wants to find clubloyalty.dk in Cloudflare. Is my setup even possible when using Cloudflare DNS? Wildcard certificates is not a must-have, but I want certificate renewals to be automatic.

Hope it makes sense :slight_smile:

2 Likes
2

Hi @plann

I've never used that plugin. But the documentation

https://certbot.eff.org/docs/using.html

says nothing that this plugin supports such a CNAME solution.

So if you want to create a certificate with clubloyalty.dk, that zone is checked to create _acme-challenge.clubloyalty.dk, not loyaltykey.com.

With such a situation, http validation is easy. There you can use the CNAME, so the ip of your other domain is used (I have the same situation with some customers and subdomain.customerdomain.com CNAME subdomain.server-daten.de - my service).

2 Likes
3

Hi @JuergenAuer ,
Are you able to elaborate on your setup and what steps you took specifically to make this work?

My LetsEncrypt is running on my NGINX server, which acts as a loadbalancer for multiple web nodes. This makes HTTP validation a little tricky, as my ACME client doesn't have direct access to the codebase.

Can you think of another way to make this work? I'm fairly new to letsencrypt although I've read a lot of documentation.

Thank you!

1 Like
4

Why is that?

If you can modify the nginx configuration, and the customer points their domain at your nginx server, that's all you need to onboard your customer domains.

It could be as simple as this - no moving parts at all.

1 Like
5

Read

You can add a redirect (port 80 or port 443) to a new domain (something like acme-challenge.yourdomain.com), then:

  • Use only a single machine with that subdomain, no load balancer (or a fixed load balancer destination)
  • Then use webroot to create the validation file.
1 Like
6

@JuergenAuer
I've done some digging and found this fairly old commit, that was supposed to address my issue specifically: https://github.com/certbot/certbot/commit/195363c66cdf078bf6860567bb30316971e89901

Do you by any chance know what in the world happened to this functionality?
I'm using certbot 1.7.0 on Centos 7 and I have no such feature... :sob:

1 Like
7

@_az Thank you for the suggestion az. I will look at the acme.sh option in case I cannot fix this issue with Certbot.

I've done some digging and found this fairly old commit, that was supposed to address my issue specifically: https://github.com/certbot/certbot/commit/195363c66cdf078bf6860567bb30316971e89901
But it doesnt seem like this is available anymore...

1 Like
8

I have no idea.

Use the redirect solution, that should work. That's a standard solution.

1 Like
9

Yes, you can try do this by asking your customers to CNAME both example.com and _acme-challenge.example.com, and use DNS-01 issuance with a delegated zone. (Though that feature is not available in Certbot yet).

In my opinion this would be quite unnecessary and complex. Why ask customers to setup more CNAMEs than just the one?

Your situation is straightforward: A domain is pointed to your server (via CNAME), this means you can issue a certificate using HTTP.

Whether you do this using Certbot's--nginx or --webroot methods, the acme.sh equivalents, or the acme.sh stateless option is up to you. Any way you do it, you don't have to touch your codebase. It's a surface level change to the webserver configuration.

1 Like
10

I have a lot of experience with this setup (OpenResty, but it's an extended Nginx)

You have two problems:

  1. Getting the Certificates
  2. Using the Certificates

In terms of getting the Certificates, I am a fan of the HTTP redirect method, but I've found it difficult to troubleshoot issues in the past. Personally, I think the simplest way to handle obtaining certs is...

  1. Only one server runs Certbot, it's invoked with "standalone" mode, and on a higher port (e.g. --http-01-port=80801 )
  2. The Load Balancer / Gateway uses a proxy-pass to send all traffic in /.well-known/acme-challenge to the node which runs Certbot
location  /.well-known/acme-challenge  {
    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
    proxy_set_header  Host  $host;
    proxy_pass  http://192.168.1.47:8080;
}

There are no redirects, just the proxy pass, so I find it much easier to deal with active troubleshooting or logs.

In terms of using the certificates... that's up to you. You could install them on the load balancer and terminate ssl there, or sync them around to nodes. I load them into OpenResty/Nginx dynamically (and open sourced our tool GitHub - aptise/peter_sslers: or how i stopped worrying and learned to love the ssl certificate) Another option is to use a server like caddy as your firewall, and have it automatically procure certificates as needed.

All that being said, I'd figure out exactly how you want to deploy the certificates internally and then work backwards from there. That is the hardest part of a multi-node setup.

2 Likes
11

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