-
Notifications
You must be signed in to change notification settings - Fork 822
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support wildcard certificates with ACMEv2 #319
Comments
Wilcard certs will require |
Well that's a bummer. As Python-acme is part of certbot I'd guess they will implement v2 soon-ish, and then simple_le will able to support it as well in the future. Anyways, thanks! |
Unfortunately it's not as simple as that, let me clarify : support for ACME V2 will be implemented in simp_le, but
|
Oh, I see. Thanks for helping :) |
@raqbit I'm re-opening so the issue and the reason why we won't (/ can't) support wildcard certs have better visibility. |
Please see zenhack/simp_le#101 (comment) for updates on the upstream issue, since the v2 endpoint has finally been released to production. |
@almereyda as told in my first message on this issue and on the This is not the same thing as (or related to) Acme v2 support. |
I am curious. Can't simp_le be replaced with another components that could handle dns-01 challenge? If not, what are our options? Can't we hack the configuration a bit on our end to support it? |
It could, I've been thinking for a while about doing a fork of this project using As for other options, the most serious is probably switching to a bigger project like https://github.com/containous/traefik To be honest I have my doubts about the long term viability of the |
@buchdag thank you for your reply. |
The simp_le issue mentions that they are planning to support the DNS-01
challenge soon'ish.
…On 15 March 2018 at 10:51, Dragnucs ***@***.***> wrote:
@buchdag <https://github.com/buchdag> thank you for your reply.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#319 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABka_GISKEcuTX9F-FpUc2P_lNQPU3rIks5tejmzgaJpZM4RmAk2>
.
|
Errr no it does not. We (zenhack and I) said on that issue that ACME v2 support is planned (we said nothing about when, and it might turn out to be harder than expected) and that Again |
@buchdag Thanks for your contribution!!! Traefik works really fine with it!!! I am doing some tests around it and it seems pretty stable as well. Since I have a couple servers running this repo It will take a couple months to release something usefull, but thank in advance! |
Maybe give users a hint in https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion/blob/master/app/letsencrypt_service#L106 when they receive this useless error? Like adding the link to this issue in the output. We expect this to work, but it actually fails
It actually took me a while to figure out what happened. Thanks for the nice work tho |
@BirkhoffLee "expect this to work" "useless error" ... nice tone there. BTW the "useless error" actually comes from |
I’m sorry, I didn’t mean to say that. I’m not a native English speaker so..
haha
I’ll try to dig into the code and see if I can add a hint to the error when
I have free time :)
Sorry again for what I said, and thanks to everyone for the contribution to
the awesome project!
…On Wed, Apr 25, 2018 at 2:23 PM Nicolas Duchon ***@***.***> wrote:
@BirkhoffLee <https://github.com/BirkhoffLee> "expect this to work"
"useless error" ... nice tone there.
BTW the "useless error" actually comes from simp_le, not from this
container's code.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#319 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHxUf9jjsuyAqnU95EOfvJuJM1sQCOPEks5tsBZ9gaJpZM4RmAk2>
.
|
My bad, I did not realize you were a non native english speaker. 😅 You're right with the fact that some warnings about unsupported features (as of now) like ACME V2 endpoints and wildcard certificates should be added. I'll try to add this to |
Thanks 😄
…On Wed, Apr 25, 2018 at 2:50 PM Nicolas Duchon ***@***.***> wrote:
My bad, I did not realize you were a non native english speaker. 😅
You're right with the fact that some warnings about unsupported features
(as of now) like ACME V2 endpoints and wildcard certificates should be
added. I'll try to add this to dev this week.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#319 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHxUf2i0qWuzak52cgRseaj98kZ9vYikks5tsByhgaJpZM4RmAk2>
.
|
Hi, I am discovering this project. I see why the issue has been reopened but I also see there is a v1.12 solution for it. Is this finally solved? Thanks for sharing! |
Quoting myself:
|
great work. thank you! Is there a way to support your work with a donation? |
Now following suite with the release of v2 through #510 and #719, it appears even more possible to use In #510 (comment) @pini-gh communicated the existence of a fork --- that happens to find itself at https://github.com/pini-gh/docker-letsencrypt-nginx-proxy-companion in opposition to the link provided there --- that implements the requested change here. See the comparison in v2.0.1...pini-gh:dns-01-challenge Would this deem a suitable moment to issue a Pull Request from this PoC and test and extend it against the maintainer's expectations? |
@almereyda as usual I'd really like to give users a roadmap and stick to it, but you saw how well it went the last time I tried that. Things I can say for now:
|
Hello, any news regarding DNS challenge support? |
Is there a way to customize executed acme.sh when I want to do wildcard with dns-01 challenge, I'll use if-else per domain to append TOKEN and change to dns-01 challenge |
Hi, what about #916, any plans to merge it? |
Bumping this issue since not a single comment has been posted in response to the PR #916 which seems to implement wildcard certificates (albeit only supporting Cloudflare if I understood correctly). Is it planned to be merged ? Or is this feature simply not planned to be implemented in acme-companion for now ? |
@Miladiir @Hexalyse the PR #916 is unfortunately too much specific to cloudfare (because it's checking for the existence of I have created a PR (#1022) for adding generic support for DNS challenges which is fully working for "non-wildcard" domains with minor changes to the code base and being not specific to any provider. Based on what I have read in the #916 , the PR #1022 may not require a lot of additional work in order to support wildcards domains, because wildcard certs are issued based on DNS challenge : I think it only require to update the |
Are there any updates on this? This feature is gonna help us a lot |
If anyone is looking for a working alternative, here's an example of how to combine nginx-proxy with adferrand/dnsrobocert: Script to deploy certificates generated with DNSroboCert to nginx-proxy. It's working very well, feel free to use it in any way that you see fit. |
For anyone searching for wildcard certificate support in nginx-proxy: I've created a docker image which is based on go-acme/lego and works perfectly well with nginx-proxy. |
Here is another workaround, using acmesh-official/acme.sh to work with nginx-proxy. |
I confirm, thanks a lot for this image! The documentation being extra slim, I share my version: "2.4"
services:
nginx-proxy:
image: nginxproxy/nginx-proxy:alpine
container_name: nginx-proxy
restart: always
ports:
- "80:80/tcp"
- "443:443/tcp"
volumes:
- certs:/etc/nginx/certs:ro
- /var/run/docker.sock:/tmp/docker.sock:ro
networks:
proxy-network:
lego-acme:
image: cilenco/lego-cron-wrapper
container_name: lego-acme
command: >
--accept-tos --email=mail@example.com --dns ovh
--domains=*.example.com
environment:
- RUN_ARGUMENTS=--run-hook=/app/deploy
- RENEW_ARGUMENTS=--renew-hook=/app/deploy
- OVH_APPLICATION_KEY=<appkey>
- OVH_APPLICATION_SECRET=<appsec>
- OVH_CONSUMER_KEY=<conskey>
- OVH_ENDPOINT=ovh-eu
volumes:
- certs:/app/certificates
- /var/run/docker.sock:/var/run/docker.sock:ro
- ./deploy.sh:/app/deploy
networks:
- proxy-network-internal
website:
image: httpd:alpine
container_name: website
restart: always
volumes:
- ./website:/usr/local/apache2/htdocs/:ro
- ./httpd.conf:/usr/local/apache2/conf/httpd.conf:ro
environment:
- VIRTUAL_HOST=example.example.com
networks:
- proxy-network
volumes:
certs:
networks:
proxy-network-internal:
external: true
proxy-network:
external: true Please note that the |
This took way, way longer than I intended, but support for |
On January 27 letsencrypt will make star certificates fully available via the ACME v2 protocol.
Are you planning on adding support for this?
The text was updated successfully, but these errors were encountered: