Skip to content
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

[Question] Will wildcard certificates be supported in February? #2

Open
cwrau opened this issue Feb 1, 2018 · 4 comments
Open

[Question] Will wildcard certificates be supported in February? #2

cwrau opened this issue Feb 1, 2018 · 4 comments

Comments

@cwrau
Copy link

cwrau commented Feb 1, 2018

In February 2018 LetsEncrypt is adding wildcard subdomain support. It indicates this is accomplished via their ACME v2 API. Do we know what support will look like for this Docker container? Is this difficult to support and/or are there plans to support it?

We’ve got some exciting features planned for 2018.

First, we’re planning to introduce an ACME v2 protocol API endpoint and support for wildcard certificates along with it. Wildcard certificates will be free and available globally just like our other certificates. We are planning to have a public test API endpoint up by January 4, and we’ve set a date for the full launch: Tuesday, February 27.

Source

@samoshkin
Copy link
Owner

Since this container relies on "acme.sh" and "certbot" ACME clients, it depends on how and when they will pick up ACME v2 API changes, and wildcard support in particular.

From https://certbot.eff.org/faq/#will-let-s-encrypt-issue-wildcard-certificates

Will Let's Encrypt issue wildcard certificates?
Let’s Encrypt has announced wildcard support coming January 2018. Certbot plans to add support for wildcard certificates when Let’s Encrypt starts issuing them.

Right now, the container just passes domain(s) to acme/certbot CLI:
acme.sh -d example.com -d www.example.com

The simplest assumption on future wildcard support would be just using the same -d argument. In this case, it's rather simple to support. But this is just an assumption, and we need to wait until it's released.
acme.sh -d '*.example.com'

Another note from LE announcement on wildcard certificates:

We will initially only support base domain validation via DNS for wildcard certificates, but may explore additional validation options over time.

It means, the container would need to add support for automatic dns-01 challenge method. Right now it uses http-01 challenge type using webroot and standalone modes. Adding dns-01 challenge is more complicated, because:

  • manually configuring DNS challenge record on the DNS server is not acceptable, we need fully automatic solution
  • it depends on what particular DNS server you're using and it's API for automatically adding/removing new DNS records.
  • certbot and acme have support for some DNS servers, but in different way.

Conclusion:

  • right now I don't know how wildcard support would be exposed in acme.sh and certbot clients. Need to wait until the end of Feb 2018, when LE releases ACME v2 API, and then to wait for acme.sh and certbot catching up with ACME v2 API.
  • issuing wildcard certificates would require dns-01 challenge method, which is not implemented by this container right now.
  • technically it's possible to add dns-01 support (maybe for most commonly used DNS providers), but somewhat more complicated, than currently used dead simple http-01.

@cwrau
Copy link
Author

cwrau commented Feb 1, 2018

Thanks for the thorough answer!
Guess I'll have to wait then ⏳
If I can help in any way, I'd be glad to do so

@Stradivario
Copy link

Hello there guys! Any idea about the resolution of this feature ? I would love to have wildcard certificate since I have automation process exposing many containers with different subdomains.Basically now I am creating certs for every container on start.... Thanks in advance!

@cn-ml
Copy link

cn-ml commented Nov 10, 2021

@samoshkin Is there any update for this feature?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants