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

Wildcard Certificate Support #21

Closed
hsivonen opened this Issue Feb 5, 2015 · 19 comments

Comments

Projects
None yet
@hsivonen

hsivonen commented Feb 5, 2015

According to a presentation by Seth Schoen and according to brief inspection of the CA source code, Let's Encrypt is planning on not issuing wildcard certificates. IIRC, the reason given by Schoen was the lack of a method of checking that the ACME client really speaks for the whole domain subspace. Furthermore, it was observed that being able to quickly meant non-wildcard certificates for a particular host names in an automated fashion without payment makes wildcard certificates less necessary.

This doesn't address the wildcard use case that Sandstorm (https://sandstorm.io/) has: Minting randomly-generated host names all the time in order to generate new unguessable origins. In order for newly-minted origins to work immediately, it doesn't make sense to wait even for fast automatic certificate issuance. Also, I would imagine that as long as the Baseline Requirements don't exempt short-lived certificates from revocation infrastructure requirements, Let's Encrypt might not be too keen to have servers generate certs for throw-away hostnames all the time.

To address this use case, I suggest that Let's Encrypt issues a wildcard certificate when the ACME client can demonstrate that it speaks for several hostnames that are randomly generated by the Registration Authority. For some reasonable value for "several", the RA should be able to convince itself that there exists a DNS wildcard that makes hostnames that would match the requested wildcard certificates point to the server running the ACME client.

@bifurcation

This comment has been minimized.

Contributor

bifurcation commented Feb 5, 2015

This is an interesting suggestion. It would require an update to the ACME protocol.

I would suggest we address this issue by first figuring out what the protocol looks like, then circling back to implement the updated protocol in boulder.

@hsivonen

This comment has been minimized.

hsivonen commented Feb 10, 2015

@bjacobel bjacobel referenced this issue Apr 2, 2015

Open

SSL #40

0 of 4 tasks complete

@bdaehlie bdaehlie added this to the Defer milestone May 19, 2015

@jcjones jcjones changed the title from Issuing wildcard certificates isn't supported to Wildcard Certificate Support May 20, 2015

@anfedorov

This comment has been minimized.

anfedorov commented Jul 21, 2015

There was some discussion on the acme-spec issue about the possible implementations of this, although it looks like the final version left it up to the server.

The process I went through with COMODO for a wildcard cert I just got involved proving ownership of secret token sent to admin@domain.com, administrator@domain.com, or a couple of others. The emails listed in the whois info of the domain were also valid verification options.

@JasonSome

This comment has been minimized.

JasonSome commented Jan 31, 2016

So, @bdaehlie @jsha any update on what remains to be resolved for wildcard certificate support?

@lenovouser

This comment has been minimized.

lenovouser commented Mar 4, 2016

I think this should be possible now, as the DNS-01-Challenge has been implemented in staging. The client seems like it is going to support this soon too.

@JasonSome

This comment has been minimized.

JasonSome commented Mar 12, 2016

Pinging @jsha

@lenovouser

This comment has been minimized.

lenovouser commented Mar 28, 2016

Any updates?

@fpietrosanti

This comment has been minimized.

fpietrosanti commented Apr 2, 2016

The Tor2web project would to use it and implement/integrate this specs from letsencrypt implementation as soon as it's available https://github.com/globaleaks/tor2web

@lenovouser

This comment has been minimized.

lenovouser commented Mar 24, 2017

ietf-wg-acme/acme#124 has been merged, this should be possible now, right?

@rolandshoemaker

This comment has been minimized.

Contributor

rolandshoemaker commented Mar 24, 2017

ietf-wg-acme/acme#124 moves the wildcard issuance to a server policy position instead of a specification position. If a server chooses to allow wildcard certificates it will choose the set of requirements it needs satisfied based on its own policy for validating wildcards.

There is a possibility this could be further formalized (i.e. by providing a BCP policy for wildcard validation) but given the current WGLC state of this document this is not the place to do it.

@rolandshoemaker

This comment has been minimized.

Contributor

rolandshoemaker commented Mar 24, 2017

Blergh, thought this was an issue on ietf-wg-acme/acme.

Our position is that wildcard issuance is still not a high priority for Boulder, though it has now been unblocked by the specification update and is a possibility at sometime in the future.

@bdaehlie

This comment has been minimized.

bdaehlie commented Mar 24, 2017

We've considered issuing wildcard certificates in the past, and we're continuing to consider it, but we have no plans to issue them at this time.

@lenovouser

This comment has been minimized.

lenovouser commented Mar 25, 2017

Well, that's at least a clear answer now. Until now the "excuse" was that wildcard certificate support wasn't implemented in the ACME specification yet.

@kachkaev

This comment has been minimized.

kachkaev commented May 1, 2017

Wildcard Let’s Encrypt certificates could remove one serious privacy issue for those who use continuous integration and continuous deployment pipelines (CI/CD). It is to do with the public availability of all domains for which the certificates have ever been issued.

For instance, with GitLab it is possible to configure a git repo so that when someone commits to any branch or creates a merge request, a new temporary website is being created and made available at a custom subdomain. This helps developers continuously test their work and demo the changes to the management before the code reaches staging or production. Multiple versions of the same project are simultaneously available at example.com, staging.example.com, our-new-super-cool-feature.example.com, bug-fix-in-user-profile.example.com, bobs-experiment-with-payment-workflow.example.com, etc. (this list is dynamic).

When a team works in a cloud environment (e.g. deploys to a Kubernetes cluster), creating and running all these tens of websites ends up extremely cheap, because all the developers need to do is to just git push. And when Let’s Encrypt is properly configured within the cluster, all the test subdomains become effortlessly https-enabled out of box. A demo of this workflow can be viewed here: https://about.gitlab.com/2017/04/18/cloud-native-demo/.

It probably won’t be a surprise to anyone in this thread that due to the Certificate Transparency initiative, all the subdomains to which anyone has ever deployed anything, will land a publicly available list and stay there forever. Here are the hosts that the authors of the above demo have ever used: https://www.google.com/transparencyreport/https/ct/#domain=i2p.online&incl_exp=true&incl_sub=true

screen shot 2017-05-01 at 22 38 39
screen shot 2017-05-01 at 22 38 58

(the list goes on)

As we can see, there is quite a good chunk of potentially sensitive data!

The longer the team uses CI/CD, the more breadcrumbs are being left in the transparency report and the more harm this information can potentially cause. The most critical thing that can be leaked this way is a description of a security vulnerability within the product before a patch has become available – consider hackers discovering fixing-xss-in-search-form.example.com, which suggests that someone has just created a branch with such a name!

The more accessible CI/CD and cloud-native deployments become, the more teams start using them and the more prevalence of seamless Let’s Encrypt provisioning happens. With enough hidden complexity under the hood of the build tools, there is even no need to know that such thing as Let’s Encrypt exists at all in order to use it! Of course, strong dev teams will find means to protect themselves from the leaks by using paid wildcard certificates, but without a generally available free option to get a wildcard certificate, subdomain leaks are likely to spread quite widely.

Given the above, I believe that wildcard support for Let’s Encrypt should probably get a slightly higher level of attention than now. It's not only about reducing the number automated requests to the CA servers, as it turns out.

@kachkaev

This comment has been minimized.

kachkaev commented Jun 14, 2017

@dosire do you think there might be a room for some collaboration between GitLab and Letsenctypt to solve the branch name leak issue through certs? See the comment above. Given that your team shows a great progress with CD to kubernetes/letsencrypt, the issue can become pretty wide-spread quite soon. Autogenerated wildcard certs to the rescue! :–)

@PAStheLoD

This comment has been minimized.

PAStheLoD commented Jun 17, 2017

Just FYI, the current draft spec prohibits issuing authorizations for wildcards (which means prohibits issuing wildcard certs via ACME), however, LE seems to be making tiny steps toward issuing wildcards (such as introducing a new flow, and hints about a follow up spec for standardizing wildcard issuance).

@bjmgeek

This comment has been minimized.

bjmgeek commented Jun 29, 2017

Would another possible way to validate wildcard domains be to have an authoritative DNS server allow AXFR to the ACME server?

@cpu

This comment has been minimized.

@rolandshoemaker

This comment has been minimized.

Contributor

rolandshoemaker commented Jul 17, 2017

Closing in favor of #2874 which contains initial implementation details for the v2 API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment