Hi,
Just wondering how long it will take to update to issuing wildcards come January? You think it's a big change?
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.
DNS validation would be nice to have, even not considering wildcards. A few thoughts:
deploy_challenge
hook of dehydrated supplies a domain and a token to be written into a TXT record.
-- 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)
parentdomain.com:wildcard:latest
and make the storage layer check that key if a concrete certificate is not found.Questions:
is_wildcard_domain
? A new return value for the existing allow_domain
?FYI: there is now a ACMEv2 staging endpoint available. :)
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.
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 ;)
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...
Is there a way to store a manually generated wildcard LE certificate to Redis so that resty-auto-ssl could use it ?
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.
@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.
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 :)
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.
@kapouer thanks for the tip about lexicon
, will keep it in mind if I want to automate ;)
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 likexxxx.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.
@jarthod any other workaround to automate this? Remembering to renew wildcard every 3 month is pain actually.
@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.
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 notifications@github.com 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.
Most helpful comment
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.