Wildcard Certificate Support about boulder HOT 19 CLOSED

https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html

from boulder.

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

(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.

from boulder.

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

from boulder.

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

from boulder.

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).

from boulder.

Any updates?

from boulder.

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.

from boulder.

Filed letsencrypt/acme-spec#64

from boulder.

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 [email protected], [email protected], or a couple of others. The emails listed in the whois info of the domain were also valid verification options.

from boulder.

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

from boulder.

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.

from boulder.

Pinging @jsha

from boulder.

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.

from boulder.

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.

from boulder.

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.

from boulder.

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.

from boulder.

@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! :–)

from boulder.

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

from boulder.

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

from boulder.