Let's encrypt SSL for domain host and cname

Hi,

I am working on a new web application setup. These domain names are just examples:

The app uses the domain called: myappdomain.com
I want to deploy instances for customers like with Lets’encrypt SSL certificates:
customer1.myappdomain.com >>> https://customer1.myappdomain.com
customer2.myappdomain.com >>> https://customer2.myappdomain.com

I am able to generate Lets’encrypt SSL for the hosts/subdomains customer1.myappdomain.com, customer2.myappdomain.com, …

Now, customers want to use their own company domains to point a CNAME to our host on which their app instance is deployed. To have something like:

app.customer1domain.com >>>> CNAME >>>>> customer1.myappdomain.com
app.customer2domain.com >>>> CNAME >>>>> customer2.myappdomain.com

As I am NOT the owner of the customer domains: customer1.myappdomain.com, customer2.myappdomain.com, …
what is the best approach to allow customers access the app via SSL from their domains and avoid getting any errors: https://app.customer1domain.com, https://app.customer2domain.com, …

Note: What if my domain myappdomain.com is protected by Cloudflare. Are there specific configurations to consider in Cloudflare?

Thanks

1 Like

There are a variety of approaches that I know of, but none of them are really completely straightforward.

The least work is going to an ACME-aware proxy, such as Traefik or Caddy. A simplified explanation:

  • Your web application configures the proxy (by generating a configuration file, for example) with what certificates should exist for customer domains.
  • The proxy automatically issues, uses and manages the certificates for the customer domains, and routes the requests to your web application backend. As long as your customers have setup the CNAME, this will all happen automatically.

I do not recommend trying to implement this by hand (for example, programmatically invoking Certbot and then programatically regenerating your nginx/Apache virtual hosts). There are simply too many ways for it to go wrong. Outsource as much of that pain as possible. Yes, it means you have to introduce a new webserver to your infrastructure, but it's a small price to pay.

It's not necessarily the case that Traefik/Caddy are the only solutions, but they're perhaps some of the friendliest ones. If you use Apache, you could consider using mod_md and dynamically generating the Apache configuration. It gives you the automated certificate management, without needing an additional webserver. I'm not sure that an analogue exists for nginx, but OpenResty + lua-resty-acme may come close.

Yes. If your web application is behind the Cloudflare CDN, then this becomes more complicated.

Cloudflare is the one who will need to issue certificates for all of your customers domains. I'm not sure whether that's possible - probably one of the higher-end paid plans.

3 Likes

Thanks a lot _az for the details. I will evaluate that and give a try and share the results.

1 Like

is there any suggested solution if already using Nginx as a webserver?
Ideally to keep the same Nginx to do that.

1 Like

Because the customers have pointed their hostname to your server (due to the CNAME), you can actually get a certificate without any problem. This is because requests for http://app.customer1domain.com/.well-known/acme-challenge/ will land on your servers.

If "on the fly" certificate generation isn't welcome, the only thing you need to know from your customers is the actual hostname used by your customer. Then, you can generate a certificate for the customer hostname any way you want.

Short summary: because of the CNAME, technically, there's nothing holding you back from generating certificates for your customers hostnames.

3 Likes

Thanks Osiris for the answer.

You mean if the cname is pointed BEFORE deploying the application and generating the lets'encrypt, we can request lets'encrypt for both app.customer1domain.com AND customer1.myappdomain.com . This seems to make sense. I will try that.

BUT what if the cname is pointed AFTER deploying the application, or the customer wants to change the cname? I assume, will need to add the customer domain to the already generated lets'encryot ssl. Is that correct?

You mean app.customer1domain.com (which is pointed to our domain cname > customer1.myappdomain.com) or something else?

1 Like

Yes.

Yes, you'd need to generate a new certificate, perhaps update the previous one or generate a new one and deploy it in parallel with the first one.

Yes. You'd need to know the hostname of your client to get a certificate for it of course :wink:

2 Likes

Not any that I'm aware of. There was ngx_http_acme_module back in the day, but it's been abandoned for some time. OpenResty (which is just nginx + the lua module on top of it) is what's available.

It might feel painful to use a separate proxy for your HTTPS port but it's probably preferable to dozens (or more) of development hours trying to wrangle it by hand and figuring all the weird and wonderful ways you got burned afterwards.

1 Like

Thanks [_az] for the clarification.

For OpenResty, I open sourced (1) GitHub - aptise/lua-resty-peter_sslers: OpenResty/Lua support for https://github.com/aptise/peter_sslers Certificate Manager and (2) GitHub - aptise/peter_sslers: or how i stopped worrying and learned to love the ssl certificate

The first package is a lua OpenResty(Nginx) plugin to enable dynamic ssl loading

The second package is a Pyramid application that bundles a Certificate Manager with an ACME v2 client. The Pyramid application can be driven by a Web Interface or programmatic API.

They work together like this: The OpenResty plugin will try to load a certificate from nginx worker cache, nginx shared cache, redis and then Pyramid. The Pyramid app can attempt an "autocert" fallback as well.

When we add a customer's domain into our stack, we enroll the domain into the certificate manager then periodically check for the DNS to be ready. when it points to our systems, we attempt to provision a certificate. all of this happens via apis.

2 Likes

Thanks [jvanasco] for sharing.
From an initial reading, this seems a little be complicated. or may be not (I am sure not for you as the creator/developer)!?

Is this recommended for deployments where you will have a dozen of application deployments using Let’sencrypt SSl certifications? Or it’s more recommended for large infrastructure deployments?

1 Like

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