Wildcard certificates

[byrnedo]

Hi,
Just wondering how long it will take to update to issuing wildcards come January? You think it's a big change?

[dvigueras]

I'm not a repo maintainer but I have to say this is not something easy to add. LE wildcard certificates will require DNS validation, and right now lua-resty-auto-ssl uses http validation.

[luto]

DNS validation would be nice to have, even not considering wildcards. A few thoughts:

• we need to wait for dehydrated to get ACMEv2 support first: dehydrated#420
• dehydrated already supports the (ACMEv1) dns-01 challenge. The dns-01 challenge in the current ACMEv2 draft looks identical or almost identical to me.
• the deploy_challenge hook of dehydrated supplies a domain and a token to be written into a TXT record.
• since we do not know how users are managing their DNS records, this part needs to be generic.
  1. support popular DNS APIs. We should at least add infrastructure to support "standard" APIs like the one provided by PowerDNS, CloudFlare or even nsupdate. In this case only some kind of authentication token is needed in our settings.
  2. must users will need a custom solution to set those records, like talking to a proprietary API or even calling dirty shell scripts. We should provide a generic hook for those cases:

  -- Define a function to store the validation tokens for DNS verification
  -- by let's encrypt in your DNS setup.
  auto_ssl:set("deploy_dns_challenge", function(domain, token)
    -- talk to your DNS-API to create a new TXT record _acme-challenge.$domain with value $token
  end)
  

• the storage layer currently assumes that it can use the full domain as a key to get the certificate. This will no longer hold true. My first idea is to store wildcards as parentdomain.com:wildcard:latest and make the storage layer check that key if a concrete certificate is not found.

Questions:

1. how do we know whether to generate a normal or a wildcard certificate? a new user-defined function is_wildcard_domain? A new return value for the existing allow_domain?
2. do we support DNS (for wildcards) and HTTP (for normal certs) validation at the same time, or just DNS for both? Note that HTTP might be a lot faster, since we control all the moving parts.

[luto]

FYI: there is now a ACMEv2 staging endpoint available. :)

[cpu]

The dns-01 challenge in the current ACMEv2 draft looks identical or almost identical to me.

You're right :-) Nothing has changed in the DNS-01 challenge between the V1 and V2 API.

[luto]

FYI: at least the development version of dehydrated now supports ACMEv2 as well as wildcard certificates. In case anyone wants to start working on this, now is your chance ;)

[kapouer]

I think resty-auto-ssl doing DNS validation is completely out of scope.
However, it should be possible for us to make resty-auto-ssl fall back to an "out of band" configured wildcard certificate.
For example i'm going to set up my service using bind9 and certbot to do wildcard certificate for a domain. Right now i don't think i can tell resty-auto-ssl to use that wildcard certificate instead of trying to generate one.

EDIT: well, it's not that out of scope. I did not know dehydrated could be configured with manual scripts to hook into a custom DNS api...

[Laboltus]

Is there a way to store a manually generated wildcard LE certificate to Redis so that resty-auto-ssl could use it ?

[akalipetis]

From what I understand from the code, this is not possible. We could easily add the following checks though in the storage interface, for each sub.domain.tld:

• sub.domain.tld:latest — current
• *.domain.tld:latest
• *.sub.domain.tld:latest

This way, we could have a first step towards wildcards, supporting only previously generated certificates for now. After doing so, we could move on and decide on a nice way to support generation of wildcard certificates, if we decide we want to do so.

Edit: I'd be happy to scratch an implementation of the above.

[kapouer]

@akalipetis did you try to see if setting

ssl_options.fullchain_der
ssl_options.privkey_der

would work in allow_domain ?
If it's possible then you could do a redis request in allow_domain and set those.

[jarthod]

For the record I just hit this issue, I use lua-resty-auto-ssl to generate certs for custom domain status pages on my monitoring service and most people would use my own domains like xxxx.status.updown.io for which it's way more efficient to use a wildcard cert.

I achieved this by using the allow_domain lambda to skip cert generation for *status.updown.io:

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

And then provided the wildcard as the default fallback cert:

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

I generated the cert manually using the DNS challenge with:

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

I'm not sure it's worth spending my time automating this as it looks complicated with the DNS challenge. It's low tech but it works as expected :)

[kapouer]

That's a nice workaround, and one that applies to many use cases.
However mind that DNS challenge has been made very easy with https://github.com/AnalogJ/lexicon !
It works well and supports a lot of providers. I even added one of them and the process is ridiculously easy.

[jarthod]

@kapouer thanks for the tip about lexicon, will keep it in mind if I want to automate ;)

[gtmadev]

For the record I just hit this issue, I use lua-resty-auto-ssl to generate certs for custom domain status pages on my monitoring service and most people would use my own domains like xxxx.status.updown.io for which it's way more efficient to use a wildcard cert.

I achieved this by using the allow_domain lambda to skip cert generation for *status.updown.io:

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

And then provided the wildcard as the default fallback cert:

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

I generated the cert manually using the DNS challenge with:

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

I'm not sure it's worth spending my time automating this as it looks complicated with the DNS challenge. It's low tech but it works as expected :)

I am also doing the same type of domain check for our app. If the user's portal host contains one of our "own" domains, then we just revert to using wildcard certs from a static CA. But I like your idea of still using LE and generating the wildcards manually.

I'm going to test this out.

Update
Okay, this is the solution that really does what I want. The cloudflare plugin. The docs are pretty good. I had it working within an hour or two.

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

[adityapatadia]

@jarthod any other workaround to automate this? Remembering to renew wildcard every 3 month is pain actually.

[jarthod]

@jarthod any other workaround to automate this? Remembering to renew wildcard every 3 month is pain actually.

Not on my side, I'm still using this and doing the manual renew every 3 months. Remembering is not a problem for me as I'm using my service (updown.io) to monitor the endpoint and it does alert me when the cert is about to expire.

[adityapatadia]

I am also user of your service. Anyway I went ahead and got traditional 1 year wildcard SSL. Now your service has job to remind me next year 😄

…

On 03-Oct-2020, at 10:30 PM, Adrien Rey-Jarthon ***@***.***> wrote:  @jarthod any other workaround to automate this? Remembering to renew wildcard every 3 month is pain actually. Not on my side, I'm still using this and doing the manual renew every 3 months. Remembering is not a problem for me as I'm using my service (updown.io) to monitor the endpoint and it does alert me when the cert is about to expire. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.