
ACME v2 and Wildcard Certificate Support is Live - schoen
https://community.letsencrypt.org/t/acme-v2-and-wildcard-certificate-support-is-live/55579
======
kyledrake
First, congrats, this is great news! There's a lot of use cases out there that
require a wildcard cert or work far better with them.

> It is our intent to transition all clients and subscribers to ACMEv2, though
> we have not set an end-of-life date for our ACMEv1 API yet.

Please don't do this. It will break millions of sites needlessly. Most
installations of lets encrypt plugins aren't going to auto update to v2. A lot
of us are also using custom v1 code for various reasons that may not be easy
to change.

The preferable end-of-life date for ACMEv1 (sparing any existential security
issues) should be never. Otherwise you will be executing a Geocities-sized web
meltdown every time you phase out a version of the API.

~~~
jaas
The reason we haven't announced an EOL for ACMEv1 is that we won't announce
one until we are confident we won't cause the kind of meltdown you describe.

~~~
irq-1
You could block new domains (new to Lets Encrypt) from using v1.

~~~
nothrabannosir
This will break many tools which currently rely on LE. E.g. mailinabox, which
uses LE to set itself up.

~~~
zaarn
I doubt they would just break it. I imagine if they do this then this will be
announced sufficiently in advance (probably around two or three years) to
allow people to update their ACME clients. Then you can just operate the
ACMEv1 for existing domains until noone is asking for more (and scale down the
architecture).

~~~
nothrabannosir
The problem is that LE is being used as plumbing. I noticed MIAB was using LE
because I recognise that SSL-out-of-the-box is something interesting, and I
investigated. But I wager most people who use it will have no idea. They just
install it, and "it works", as it should. great. What's HTTPS? That's the
entire point of tools like MIAB, mind you:

 _> Technically, Mail-in-a-Box turns a fresh cloud computer into a working
mail server. But you don’t need to be a technology expert to set it up._

[https://mailinabox.email](https://mailinabox.email)

I'm just choosing MIAB as an example here. This applies to anything that LE
now enables. People don't know they're using LE, much like IOT users don't
know they're using HTTP/1.1. It's part of the plumbing. What's an ACME client?
What's LE? What's v1?

This is probably happening for IOT devices across the globe just the same. A
2y expiration date is an order of magnitude too low for plumbing. Imagine if
we suddenly decided to phase out HTTP/1.1 within two years.

We have to recognise that we are shoving HTTPS down people's throats. Pretty
soon, HTTP will get big f-off warnings. OK: fair enough. However, if we're
doing that, we should also provide a viable alternative, with the same
reliability. Otherwise, HTTPS is a _massive_ step backwards for the
decentralised web. LE is that alternative, but not if we start breaking
backwards compatibility every 2 years.

~~~
zaarn
Again, I'm not saying that the two year expiration date means "v1 stops
working".

Rather, "after this point, no new domains may setup via v1", so any existing
certificates and installations are grandfathered. Two years is sufficient for
MIAB to update their software and distribute to users.

>LE is that alternative, but not if we start breaking backwards compatibility
every 2 years.

Not what I'm saying either. They have a v2 now, we don't know if they need a
v3. And they want to keep v1 running for a while.

But there will be a point where v1 will need to be switched off, similar to
how modern browsers have switched off SSLv1 despite a lot of people still
having servers running with that.

LE will, at some point, have to decide between keeping v1 running or moving
away from old protocols to be able to evolve. And that cannot be infinitely
pushed backwards.

------
Jaruzel
One of the wonderful aspects of this, that no-ones pointed out yet, is that
these can used for INTERNAL domains, without you having to run your own
internal CA.

i.e. lets say your internal network DNS domain is 'my-company-lan.com' \- all
you have to do is ensure that 'my-company-lan.com' is also registered in
public DNS[1], and then you can secure ALL your internal services using a free
LE wildcard cert, that's automatically trusted by all platforms and
browsers[2]. For some companies that's going to be a BIG cost and resources
saving.

\--

[1] but not actually used for any public facing services.

[2] Mostly...

~~~
Jaruzel
Going to reply to my own comment here.

It's at this point that I swear profusely at Microsoft yet again, for pushing
the concept of '.local' domain suffixes a decade ago. As it's not a legal TLD,
I can't get certs for any of my internal services without rolling my own
internal CA, which only works automatically for Windows domain machines, and
not for anything else.

~~~
EvanAnderson
The ".local" suffix was a terrible idea, to be sure. Active Directory domain
rename in small environments is relatively painless.

~~~
Jaruzel
Unless of course, you are running Exchange. In which case it's not supported
:(

~~~
EvanAnderson
Unfortunately, yes. I've been lucky enough to be able to get domain renames
done in Exchange 2003 environments (which is supported) or in non-Exchange
environments. Migrating to a new domain because of a poorly-chosen name is a
real pain. (I have one Customer who has a "." in their NetBIOS domain name.
That creates some interesting kinds of hell-- completely breaks the NPS RADIUS
server in Windows 2012.)

------
massaman_yams
For anyone wondering how to actually obtain a wildcard cert this way, here's
the quick version:

1\. Use acme.sh:
[https://github.com/Neilpang/acme.sh](https://github.com/Neilpang/acme.sh)

    
    
      acme.sh --issue -d *.example.com --dns
    

If your DNS provider has a supported api, you may be able to automatically
publish the DNS records required using a slightly different command - see
here:
[https://github.com/Neilpang/acme.sh/tree/master/dnsapi](https://github.com/Neilpang/acme.sh/tree/master/dnsapi)

~~~
b3lvedere
Thanks! This looks awesome. Can i automate it as well?

I have been toying a little with wildcard using certbot on my Ubuntu OpenVPN
appliance, but was a bit unsuccessful at the moment.

Maybe i should just try and build a very tiny virtual sever that does nothing
but spit out a wildcard domain certificate to some predefined destinations to
have it used in anything that wants a certificate. Could be beneficial to a
(large) infrastructure to have an always-ready certificate to use for free.
Dunno if EV validation will uphold though.

~~~
kureikain
For provider with DNS support, you can put it in a cron, and then create
symlink or some copy step at the end of cron to copy private key and full
chain to appropriate location of your web server.

I think acme.sh is the easiet to use in all of clients.

~~~
b3lvedere
Thanks again. Everything works.

I've put my DNS to Cloudflare and after that the acme.sh was incredibly easy
to implement thanks to their API implementations.

Also learned a valuble lesson: *.provider.com is not the same as provider.com
:)

------
hardwaresofton
Don't forget to Donate:

[https://letsencrypt.org/donate](https://letsencrypt.org/donate)

Also the EFF:

[https://supporters.eff.org/donate](https://supporters.eff.org/donate)

~~~
diafygi
My suggested amount: recurring donation of $19.84 per month.

------
neals
The amount of money I've paid for this... I recon some of these providers are
going under soon?

~~~
eric_b
I'll happily pay money to get a cert that expires in 3 years instead of 90
days. Some of us don't feel like faffing about with cert renewal every
quarter. (I know there are tools and clients that can "make it seamless" \-
until the ACME endpoints are down or something).

~~~
mjrpes
I'm in the same boat. I haven't found a guide for an easy and flawless way to
automate cert renewal with letsencrypt when you use multiple services over
different servers. For my wildcard, I use the same cert for:

1\. Ubuntu VPS #1: a. dovecot ssl b. postfix ssl c. apache multiple virtual
domains ssl d. pureftpd ssl

2\. Ubuntu VPS #2: a. apache multiple virtual domains ssl

3\. Microsoft Server a. IIS multiple virtual domains ssl

~~~
slrz
Why does it have to be the same cert on every host? Use a separate cert for
each and automation will be much easier.

With Let's Encrypt, you don't need to minimize the number of certs just to
save some money.

~~~
mjrpes
I'm just saying how I'm running things now. Totally open to better ways. Right
now I pay $135 for a two year wildcard cert (very small business here). It
takes 1 hour of my time to update the cert for all these applications. 1 hour
of time and $135 every two years is not a lot. When I do a cursory look of how
to reliably automate letsencrypt across all applications, there are people who
have created scripts that help, but it does not give me reassurance that
everything will run smoothly every 90 days. I am waiting for letsencrypt to
get first-class support in dovecot, postfix, pureftpd, and IIS, so it can be
set and forget, and I know long term support will be there.

------
0x0
DNS providers and domain name registration companies are probably going to get
pestered about API access for updating TXT DNS records now... :)

~~~
blibble
is it common for DNS hosts to provide delegated access at the granularity of
individual records?

I don't want my webserver to have the ability to change my entire zonefile
just so it can authorise certificates!

~~~
level3
Not sure if it will work for your use case, but you can also CNAME the _acme-
challenge record to a different domain (or a subdomain with a separate
zonefile), dedicated only to authorizing certificates.

------
jack_jennings
Now here's to hoping that Heroku supports this soon. That will to mean I can a
last migrate a number of apps that require wildcard domains to their platform.

~~~
snowwolf
I'm intrigued. What kind of app that you could host on heroku requires
wildcard certificates? Bearing in mind that heroku can't really support
wildcard subdomains for a single app. Each custom subdomain for an app needs
to be added to the app. And then if you enable Automated Certificate
Management for the app (which uses LetsEncrypt under the covers), they'll
happily fetch a cert for each listed subdomain.

And Heroku already supports wildcard certs (that you need to provide yourself)
if you use the SSL addon.

~~~
detaro
> _Bearing in mind that heroku can 't really support wildcard subdomains for a
> single app._

Why not?

~~~
snowwolf
Well I suppose they could, but they'd have to be very careful of someone else
spinning up an app and adding your domain to it.

------
urda
This is great news! Let's Encrypt has helped me secure many of my own boxes
without having to maintain my own CA, very happy to see them grow.

------
rospaya
Can anyone list any negatives of Let's Encrypt? I've been using it since the
start and just can't find any practical downsides.

~~~
ocdtrekkie
The only significant concern I have is that if LE were to essentially "take
over" the CA industry, you know, due to being free, and awesome, we'd have a
massive single point of failure for the entire Internet's security model.

My biggest peeve with the whole "HTTPS Everywhere" push is not the general
notion of using encryption, but that the encryption is annoyingly coupled with
the CA system, which is terrible for many reasons.

~~~
elahd
The encryption part is easy -- you don't need CAs for that -- but they're a
necessary evil when it comes to verifying ownership. You need to delegate
trust to _someone_ , otherwise using the internet becomes too cumbersome.

~~~
ocdtrekkie
Automated SSL providers effectively mitigate the idea of "verifying ownership"
or "delegating trust", because for example, someone can buy a domain like...
googIe.com, get an SSL cert for it, and it's "valid". We're right back to the
same level of security of you just checking that the browser bar points at the
domain you actually intended to go to. (In this example, bear in mind, Google
doesn't use an EV cert, so they'd be equally valid to a web browser. And a lot
of EV certs I believe are getting distrusted soon as it is.)

CAs seem like a system that really doesn't work today, we've seen multiple
times that many of these CAs aren't worth delegating trust to to begin with,
and it causes an unnecessary cost and burden upon just... encrypting traffic.

~~~
vertex-four
> We're right back to the same level of security of you just checking that the
> browser bar points at the domain you actually intended to go to.

So you’re sitting in a cafe, and you go to Facebook.com. Lo and behold,
someone’s installed a MITM proxy on the router, that presents its own
encryption key instead of Facebook’s, and your browser has no way to tell this
because the CA system isn’t a thing. They now have your password, can steal
your session to spam your friends, whatever else. How do you prevent that?

Automated domain validated certificates are meant to ensure that when you go
to Facebook.com, you’re talking to Facebook.com and not a MITMing router on
the way there. They’re not meant to protect against phishing - they’re meant
to protect against the very real cases I’ve seen where my mobile ISP adds
random JavaScript into the web pages I view, and sells information about me
based on my use of the web.

~~~
Karunamon
Idea that's been floated before: TOFU plus a distributed network of people
automatically sharing what cert fingerprints they encounter. Chances are high
that you already hit Facebook on your $device, and if you all of a sudden
retrieved a certificate that didn't match the one you had before, or that most
other people online hadn't seen, halt and throw up the warnings.

Given the exploitability, laziness, general failure to follow best practices,
not to mention misaligned incentives that we're seeing from major CA vendors,
having centralized CAs seems like an ever-worsening solution.

~~~
megous
Where do you store the trust from all those people to be able to query the
statistics? That's just another central point of failure.

~~~
Karunamon
It's not as if distributed hash stores are new...

~~~
megous
That didn't answer anything. How can you trust the result if anyone can write
there. How can you trust the individual store that it doesn't manipulate its
contents, etc.

------
Santosh83
I do hope GitHub employs this for rolling out https for Pages sites using
custom domains too.

~~~
apearson
Not sure if it would help in your situation but I've moved all of my github
pages to netlify.com and they have a one button https feature for custom
domains.

~~~
mattwoodnyc
I did the same. Between Netlify and Zeit.co's Now, I don't see any reason to
complain about HTTPS, not to mention the devOps issues that both these
services solve.

SSL requires one click with Netlify, and it's on by default with Now.

~~~
apearson
Btw the only problem I have with Netlify is the close name conflict with
netflix. Chrome's autocomplete is completely confused.

------
sheraz
Great news, but interesting to see that they still recommend securing
individual domain names. I imagine this is for security purposes?

~~~
orthecreedence
Yeah, I think that if someone hacked your DNS provider, they could add
_secure-payments.yourbusiness.com_ and start spamming people with "late
payment! enter your credit card!" notices or something.

So I guess, make sure you trust your DNS provider if you're using wildcards.
Or is there another exploit I'm missing?

~~~
kardos
Not sure how the availability of wildcard certs changes that scenario, if I
can set the DNS record for secure-payments.yourbusiness.com then I can get a
non-wildcard cert for it and get on with the spamming straight away

~~~
orthecreedence
I think it's somewhat difficult to get a valid (CA-valid) certificate for a
domain you don't own, though. At least, that's what the job of the CAs is: to
verify that the certs they're issuing are for the actual owner of
yourbusiness.com.

~~~
web007
I thought that was the case, until CloudFlare issued a cert for a subdomain of
mine without a single email round-trip or even notification.

Any DNS-based validation is contingent on full DNS control, and that does mean
FULL. CNAME records are absolute, if I CNAME foo to xyz then I'm trusting xyz
100%. I won't get an email round-trip or CAA ping for the certificate unless
I'm looking for it, because CNAME implies that all things that apply to xyz
apply to anything pointed at it. So the CAA record for xyz applies, not the
CAA record for foo - it's not even valid to have any other record types for
the same name as a CNAME record, and CAA resolution stops if it gets a valid
response versus walking up to the domain root.

To be clear: CloudFlare issued a perfectly valid certificate for a perfectly
valid use case, it just bothers me that I couldn't tell it was issued until
after-the-fact by seeing it in CT logs, and couldn't have prevented it from
being issued by the mechanisms that seem to be built for that.

------
anubhavmishra
Thank you letsencrypt team! Really appreciate all the hardwork to get this
out.

------
mbonzo
Hi, I made a video on how to implement Wildcard Certificate for your
subdomains. I hope someone finds it useful :)
[https://www.youtube.com/watch?v=zvg8IXAcUwo&feature=youtu.be](https://www.youtube.com/watch?v=zvg8IXAcUwo&feature=youtu.be)

------
inetknght
This whitepages unless you disable javascript or enable connections to
discourse.org. How disappointing.

------
thinkloop
On the face of it wildcard certs seem easy to implement - just match anything
in place of the * - but clearly that's not the case as it took years to
complete, anyone mind sharing some of the subtle challenges and complexities
involved

~~~
kardos
Dynamic DNS providers is one -- I probably shouldn't be able to get a wildcard
cert for any of these [1] domains, but permitting *.mysubdomain.hostname.com
is probably OK

[1]
[https://www.dtdns.com/dtsite/faq#hostdomains](https://www.dtdns.com/dtsite/faq#hostdomains)

~~~
crtasm
LE requires setting DNS TXT records to get wildcard certs - do dynamic DNS
providers ever let you do that? My assumption is they don't.

~~~
kardos
Yeah that's a fair assumption. So no wildcards for subdomains at dynamic dns
providers -- probably not an important use-case anyhow.

~~~
crtasm
Also a large majority of them will be on the public suffix list, which LE uses
in their rate limiting checks.

[https://en.m.wikipedia.org/wiki/Public_Suffix_List](https://en.m.wikipedia.org/wiki/Public_Suffix_List)

------
gator-io
HTTPS vs HTTP usage:
[https://netmarketshare.com/report.aspx?options=%7B%22filter%...](https://netmarketshare.com/report.aspx?options=%7B%22filter%22%3A%7B%22%24and%22%3A%5B%7B%22deviceType%22%3A%7B%22%24in%22%3A%5B%22Desktop%2Flaptop%22%5D%7D%7D%5D%7D%2C%22dateLabel%22%3A%22Trend%22%2C%22attributes%22%3A%22share%22%2C%22group%22%3A%22secure%22%2C%22sort%22%3A%7B%22share%22%3A-1%7D%2C%22id%22%3A%22https%22%2C%22dateInterval%22%3A%22Monthly%22%2C%22dateStart%22%3A%222017-03%22%2C%22dateEnd%22%3A%222018-02%22%2C%22segments%22%3A%22-1000%22%7D)

------
NKCSS
I just wished there was a Windows client that just works with IIS. Every time
I try, it just errors out and gives me headaches (certify, Let's Encrypt
Simple Windows Client, etc.)

~~~
cm2187
If you are using wildcard it doesn't need to be integrated with IIS. Use
acmesharp which has a nice powershell interface (doesn't support wildcards
yet). Then loading the certificate in the certificate store and assigning it
to a website should be fairly easy in powershell.

~~~
NKCSS
Nah, I use a lot of SAN certificates; e.g. when a customer has 10 domains, and
you want all of them to redirect to one, you have 1 site with just an SSL
binding, and 1 site with all other domains and the non-SSL binding. That's a
scenario that f's up a lot.

------
komuW
Shameless plug, I created sewer[1], which is a letsencrypt client that you can
use both as a (minimalistic) python library or as a command line application.
And I just added ACME v2 support. Check it out,

1\. [https://github.com/komuw/sewer](https://github.com/komuw/sewer)

~~~
kbuck
Thanks for this; I've been searching for something similar for a while now.
I'll look forward to trying it!

------
Manozco
I did not see it on the forum, but seeing that the wildcard feature requires
DNS-01 challenge for getting the certificates, does it mean automatic renewal
is impossible without DNS api ? (or is it possible to renew without the dns
challenge ? )

~~~
hyperion2010
This thread [0] suggests that you do.

0\.
[https://www.reddit.com/r/programming/comments/84607r/lets_en...](https://www.reddit.com/r/programming/comments/84607r/lets_encrypt_releases_support_for_wildcard/dvn98d9/?st=jeq8o34j&sh=427b89e8)

~~~
schoen
Yes, for an unattended renewal you'll need a way of programmatically creating
TXT records. (Note that the validation follows CNAMEs, so the records you
create don't have to be in your main DNS zone.)

------
brightball
Can this be used for multi-level subdomains?

Like *.subdomain.example.org?

~~~
ShakataGaNai
No, but that limitation is due to wildcard certificates specifications - not
LE.

~~~
brightball
I'm mainly just trying to solve an issue where I've got end users who think
there's a security problem because they've typed www.myorg.example.org instead
of myorg.example.org and the wildcard DNS entry in Route53 picks it up...which
directs the user to an Insecure error.

Trying to figure out how to get Route53 to stop the wildcard at the top level
or get a wildcard cert that will go down the path.

------
peterwwillis
Does the DNS method require proving you control the IP space for the domain,
or is a DNS TXT really the only thing you need to generate a certificate?

~~~
schoen
Just a TXT record.

[https://tools.ietf.org/html/draft-ietf-acme-
acme-03#section-...](https://tools.ietf.org/html/draft-ietf-acme-
acme-03#section-7.4)

~~~
peterwwillis
Wow. A lot of sites are going to get owned.

~~~
schoen
We've been using TXT records to authenticate certificate requests since Let's
Encrypt launched. That hasn't changed.

~~~
peterwwillis
Without verifying who controls the IP space?

If you don't verify who controls the IP space, then if you can control the
DNS, you can generate certs. Certs that appear valid to unsuspecting users.

Putting that kind of trust in DNS is pretty crazy considering how insecure
most DNS setups are. Not to mention general attacks on DNS. There's even a
potential chicken and egg problem, if you need DNS to secure your HTTPS, but
you use HTTPS to manage your DNS.

What's really crazy too is it seems like this can't even be avoided. Even if
I'm not using Let's Encrypt, if someone owns my DNS, they can use Let's
Encrypt to get valid certs for my domain. That's insane.

What am I missing here?

~~~
cbo100
> What am I missing here?

If I "own your DNS" wouldn't I just change them all to an IP space I control
anyway? (If that was a requirement).

Unless I'm missing something, requiring "owning the IP space" seems to be an
impossible requirement to fulfil. I'm on a virtual host in Azure/AWS/Linode I
have no way of proving I own the IP (because I don't).

------
kuon
This is great, congrats, you are really doing a great service to the
community.

------
yani
Excellent! Wildcard certificates are getting deployed tomorrow.

------
kirankn
Wonderful news ! Looking forward to using the Wildcard SSLs.

------
johnr2
> Except most big orgs now employ MitM tools like BlueCoat to sniff SSL
> connections too.

This. A long thread mostly advocating HTTPS everywhere and only one mention of
this. Would any of the knowledgeable HTTPS advocates here care to comment on
it?

