
Wildcard Certificates Coming January 2018 - darwhy
https://letsencrypt.org//2017/07/06/wildcard-certificates-coming-jan-2018.html
======
SwellJoe
Let's Encrypt is just about the best thing to happen to the web this decade.
It really is huge to have encryption be something that can Just Work. It is,
by far, the most popular feature we've added to Virtualmin in many years (and
we had support from very early on due to the high demand for it).

Wildcard certs have been a common request, but you can already specify
multiple domains using SAN. And, since you can issue a new LE cert on-demand,
it's actually not necessary for a lot of use cases that would have required a
wildcard in the past. In the bad old days, getting a new certificate (even
just to change details like adding a name to it) was time-consuming and often
cost money. Most of the time when our users have needed a wildcard, it was
just because they wanted to save a little money by having all of their
subdomains on one cert; and not so much that they really needed to be able to
spring up dozens/hundreds/thousands of new subdomains that could just
automatically be secured. If you have a fixed number of names that need SSL
with the same cert, you can already do that today with Let's Encrypt.

Nonetheless, this is great. I'm just super impressed by how effective the LE
folks have been at improving the state of security on the web, and for _free_!
They really deserve every kind word and every donation dollar that comes their
way.

~~~
mgkimsal
Can I ask for a virtualmin feature here wrt SSL certs (and maybe specifically
LE)?

I know it's not the first request, but an easy way from the GUI to force all
requests to be SSL would be great. The only way I see in GUI is a "redirect
everything", but... that also redirects requests for ".well-known" which means
renewal requests don't work (have been hit by this a few times). Some
recommended ways of handling "always use SSL" with LE renewals would help.

Thanks for VM work!

~~~
SwellJoe
That's a great request (though I thought .well-known would still work through
an http->https redirect, as long as nothing else messed with the request; we
do a redirect on virtualmin.com and our LE renewals work OK...but, I'll look
deeper into that).

It can be surprisingly tricky to get redirects right, because of how web apps
behave and how web apps often take over early request processing in an
htaccess file for things like nice URLs and special assets directories and
such, and there can be surprising interactions between redirect rules, but I
suspect we could make it work in the majority of cases pretty easily. I'll add
it to my todo list.

~~~
mgkimsal
we had a global redirect (from the gui - not sure what the screen name is)
which was interfering. Removing that, things seemed to work.

i suspect if you set up some defaults, most virtualmin users would adapt
around those.

(and thanks again)

------
randomf1fan
This is great news for organizations. I work at a large Fortune 150, and there
are lots of services that require wildcard certs. We have a process to get
these from our internal CA as well as a third-party - the internal CA is
automated, but the third-party (for external services) can be slow and
cumbersome, to the point where many departments just buy their own cert. And
then a year later, they move on, forget, etc, and suddenly we have services
that have expired certs and there's a scramble to fix them.

This move by Letsencrypt should hopefully make them the standard for any
external service that doesn't require an EV cert.

~~~
Klathmon
>This move by Letsencrypt should hopefully make them the standard for any
external service that doesn't require an EV cert.

I'm kind of worried about this myself.

No matter how well intentioned, secure, or "good" lets encrypt is, having a
significant portion of the world's TLS be under one umbrella isn't a good
thing.

I'm hoping that we will begin to see other services pop up that are similar to
lets encrypt (free, even using the ACME protocol) so that we don't have too
many of our eggs in one basket here.

~~~
nmjohn
> having a significant portion of the world's TLS be under one umbrella isn't
> a good thing.

Why is that? The damage from a CA being hacked is not proportional to the size
of the CA - they are all equally (small number of exceptions notwithstanding)
capable of issuing certificates for any domain which will be trusted by all
major browsers.

Is there another aspect I'm not considering? While I see how it feels like a
troubling thing, I'm struggling to actually come up with any real consequences
of it.

~~~
halomru
Punishing CAs for bad behavior (ie Security Problems) has more collateral
damage the bigger a CA is. Right now, if a CA is bad enough browsers just stop
accepting their certificates. After a certain size that becomes unfeasible,
removing a lot of pressure from that CA

~~~
roblabla
No, browsers don't do that. See how WoSign was distrusted[0]. Basically, they
still trusted existing certificates, but stopped trusting new certs (both
renewed or brand new). Through this, they kept collateral damage to a minimum,
while carrying the CA death sentence.

[0] [https://blog.mozilla.org/security/2016/10/24/distrusting-
new...](https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-
and-startcom-certificates/)

~~~
nsgi
The trouble is that's only possible with the CA's cooperation, because they
have the ability to backdate the certificates by falsifying the date. In the
case of WoSign Mozilla threatened to distrust them completely if they did
that, but if it's unfeasible to remove a CA that threat may be ineffectual.

~~~
dublinben
This kind of forgery can be mitigated by requiring all certificates to be
published to a Certificate Transparency server upon issuance. You can't
backdate a public ledger that is being watched by third parties.

------
dijit
I strongly dislike wildcard certificates.

I worked in a few places that had a *.company.com which covered, obviously,
everything under that domain.

That meant if that wildcard cert leaked then our EV cert for, say,
checkout.company.com would be essentially compromised too.

Not to mention. If you have a wildcard cert it's rather likely you're passing
those certs around servers, lots of scope for leakage.

I really think that if you feel the need to do wildcard certificates, then you
should at least try to figure out another way around it. I'm not saying you
absolutely must never use them, but be incredibly mindful of what is at stake
and limit the scope and availability of such certs as much as possible.

For instance. Don't put the same wildcard on mail servers and IM servers and
git servers and etc; a compromise of one will compromise them all and the
revokation system is not good enough.

[https://blog.dijit.sh/please-stop-advocating-wildcard-
certif...](https://blog.dijit.sh/please-stop-advocating-wildcard-certificates)

~~~
hakanensari
There are legitimate use cases: for instance, a multi-tenant app that
designates tenant by subdomain.

~~~
maccard
Couldn't you have a cert per sub domain? If you're using Let's encrypt, you
almost certainly have automated renewal in place, so you could allocate a cert
when you give them a subdomain

~~~
ceejayoz
You can only put 100 domains on a Let's Encrypt cert, so if you're a site like
Tumblr that's going to be a whole bunch (hundreds of thousands or millions of
certs) of mayhem.

~~~
maccard
You can contact Let's Encrypt to get those limits lifted I believe?

~~~
ceejayoz
That's not going to help.

Every time someone adds a domain to Tumblr, they'd have to re-do the certbot
challenges for all 50 MILLION domains.

Plus, all 50 million domains are listed IN the certificate. It'd be megabytes
worth of additional data for every visitor to Tumblr.

*.tumblr.com makes a lot more sense.

~~~
Whitestrake
I agree with the case for using a wildcard, but just to play devil's advocate
- why can't they take the CloudFlare approach?

Generate a cert for 100 of your client's domains, use that cert across those
domains. Cut your 50m domains down to 500,000 certificates. Serving the right
certificate for the right domain is a simple enough task.

As new tumblr domains are registered, generate more certs in batches of 100
domains.

I doubt anyone would ever seriously suggest putting millions of SANs on a
single certificate, but 100 isn't too farfetched.

~~~
voltagex_
This seems to be how wordpress.com does it.

~~~
ceejayoz
They appear to have a wildcard for the *.wordpress.com subdomains, though.

------
prdonahue
Looking forward to using these at Cloudflare for our Universal SSL product.
Our plan is let customers choose which CA they would like us to issue from,
with sane defaults based on constraints imposed by other settings, e.g., CAA
record prohibiting issuance from one of the CA choices.

------
madsushi
Wildcards were one of the two big blockers for Let's Encrypt adoption at a lot
of organizations. The second blocker, the operational discipline to
automatically refresh the cert and restart services every <90 days, will
likely be the only excuse left.

~~~
djstein
While I do not know the full potential of this, apparently certbot is the way
to go for refresh services:
[https://certbot.eff.org/](https://certbot.eff.org/)

In our prod we use [https://github.com/GUI/lua-resty-auto-
ssl](https://github.com/GUI/lua-resty-auto-ssl) to generate over 1k lets
encrypt certs that refresh as they expire.

Hope these can help

~~~
pricechild
I've really enjoyed using
[https://github.com/hlandau/acme](https://github.com/hlandau/acme) and we use
it in prod.

I'm not sure how up to date [https://github.com/hlandau/acme#comparison-list-
of-client-im...](https://github.com/hlandau/acme#comparison-list-of-client-
implementations) is.

------
middleclick
I am genuinely curious as to how much this will affect the cert providers
commercial business? Other than Lets Encrypt not being able to issue EV certs.
Does anyone have a resource that talks about this?

~~~
artursapek
I hope it hurts them enough that they stop with the shady business practices.

~~~
callalex
Decreased revenue tends to lead to even shadier business practices though.

~~~
RKearney
When we moved our certs away from COMODO we received a sales call from one of
them. They found the contact info for an executive here and told them that by
replacing our COMODO certs with another brand, we were at "tremendous" risk
for not having our websites work on the latest iPhones and iPads.

The entire call (which we ended up pulling and listening to, and then sent
back to COMODO as a prime example as to why we're threw with their business)
was designed to have a non-technical decision maker make an impulse decision
over the phone to buy thousands of dollars worth of certificates again.

Wildcard certs from Let's Encrypt cannot come soon enough.

~~~
Cumulonimbus
Fortunately (and unfortunately) all the way up to the assistant vice president
came from software engineers and systems engineers. So when Comodo did their
little scam, the AVP called bullshit on them and told them off. (The
unfortunately is that some of the higher ups are technically exceptional, they
have low regard of people skills).

We're on LE for 90%. There's a client (there always is...) that demands
Network Solutions certs. Yet they cannot put to words why that's their need,
other than stupid bullyish business practices.

We're still trying to wrap our heads how LE plans to offer wildcards.. But I
digress.

~~~
freehunter
Ugh, when I was a security analyst for an enterprise, I'd occasionally have
Network Solutions call me and try to sell me certificates. I'd explain that
it's not my decision, you've got the wrong person, how did you get this number
and turns out they'd call the front desk or the help desk and say they found a
security hole on our public facing websites. The security hole was that we
used another company for our certs.

The real security hole was that the operators were patching through salesmen
directly to the security staff without verifying who they were...

~~~
mjevans
Yes, the real security hole was 'operations' not sufficiently validating
credentials and being a proper gatekeeper.

------
mnglkhn2
I would feel even more comfortable if I would be able to pay a nominal sum.
Even $1 per cert would go a long way in securing their infrastructure. Maybe
Letsencrypt does not want to handle the hassle of managing payments.

~~~
jcwayne
You can: [https://letsencrypt.org/donate/](https://letsencrypt.org/donate/)

~~~
no_wizard
I personally donate to Lets Encrypt once a year. The trouble with donations at
my company, however, is that 'gifting' money is a lot more complicated than
buying _something_.

For instance, we are supporters of Vim, but we couldn't make a direct donation
to the project. Our corporate policies on this makes things a little stiff as
any donation like this is seen as potential publicity. so we couldn't move
forward on that. However, we do often buy things for corporate events from
Amazon, so we could use the affiliate link to buy our stuff and still
contribute to the project.

There was another instance, i can't remember what the project is as I didn't
deal with it directly, where you could donate directly or buy 'swag' (like
T-shirts, cups etc). I remember one of the teams that wanted to contribute
funds managed to expense it as swag for their department so everyone got hats,
t-shirts, pens, coffee cups etc. because again, can't directly donate.

And of course, sponsorship is usually out of the question, because they don't
want to be known as supporting one specific thing or another.

Sometimes its just easier to make a 'sale' than it is to get a donation from
huge users of your product.

------
kharms
Question on this topic - is there a method of encrypting subdomains when you
don't own the domain?

An example: I run a vm that exposes mysubdomain.azure.com, can I turn on ssl
at that level? A google search says "no" but I figure this is a place where
someone might have a workaround.

~~~
pfg
Each FQDN is treated separately, so generally speaking, if you can demonstrate
control for a FQDN under an ICANN TLD, you can obtain a certificate.

Something you have to keep in mind are rate limits. Unless the (parent) domain
owner has registered the domain in question as a public suffix[1], you,
together with all other users who have subdomains under the parent domain,
will be limited to 20 certificates per week.

Some domains, like for example the hostnames EC2 instances get that resolve to
their public IP, have also been explicitly blacklisted because they are
generally not assigned to anyone for longer periods of time, and it would be
easy to mint certificates for a large number of those hostnames by just
spawning tons of EC2 instances, which would make those certificates largely
useless.

Finally, domain owners may decide to prevent issuance using a CAA DNS record,
which are supported by Let's Encrypt.

[1]: [https://publicsuffix.org/](https://publicsuffix.org/)

------
eridius
What verification strategy are they using to determine when a wildcard cert
can be created? I see the discussion on [https://github.com/letsencrypt/acme-
spec/issues/64](https://github.com/letsencrypt/acme-spec/issues/64) suggesting
that they validate a sampling of randomly-generated subdomains, but it's
unclear if that's actually the strategy they're using (and an obvious downside
with that strategy is it won't work for a client that wants a wildcard cert
for whatever reason but hasn't configured DNS to handle arbitrary subdomains,
though you could of course argue that these clients don't actually need
wildcard certs).

~~~
jaas
Currently we're only planning to allow DNS method validation for wildcards.
You'll have to validate the base domain via DNS, that's all. No HTTP or file-
based validation option.

We decided not to offer HTTP-based (file-based) validation via randomly-
generated subdomains for wildcards in part because if you're required to set
up random subdomains you're modifying DNS to do that, and if you're already
modifying DNS you might as well just use the DNS validation method.

~~~
eridius
Glad to hear it. So the assumption is that if you control the DNS for
example.com then you control the DNS for all subdomains? That seems like a
reasonable assumption.

~~~
icebraining
To validate you actually need to create a specific subdomain (_acme-
challenge.<domain>), so effectively you do control the DNS for subdomains.

------
chtitux
One great advantage of wildcard certificates is the privacy of the domains.

If you use customer1.mycorp.com, customer2.mycorp.com, etc. the names of your
clients is exposed twice :

\- if you issue one certificate with all the domains, all the domains are
readable in the certificate (Cloudflare free cert. has this issue too)

\- all the LE certificates are published in Certificate Transparency logs. So
you can detect if anyone issues a cert. for your domain, but anyone can view
the certificates you issued.

With a wildcard certificate, the subdomains used are not public.

Note this issue applies to "internal" subdomains too. You probably don't want
to expose the hostname of your backoffice (admin.mycorp.com) or your new top
secret project (linux.microsoft.org).

~~~
overint
Would you not be exposing those subdomains via DNS anyway?

~~~
chtitux
You can't enumerate sub domains via DNS (except if you use DNSSEC with NSEC
algorithm, but nobody do that).

It does not prevent people guesssing it tough.

~~~
tptacek
Correction: you can also enumerate through NSEC3, the most common (and
default) mode of deployment; NSEC3 turns enumerable zone entries into the
equivalent of a password hash file, which can be cracked.

There's a hack to prevent this that seeds the zone with false entries, but it
requires the server to operate as an online signer. Since this is essentially
incoherent to the design of the protocol (which makes major cryptographic and
usability sacrifices to enable offline signers), there's an "NSEC4" being
worked on now.

DNSSEC is silly.

------
jpsim
Is there a write-up somewhere explaining why this was a technical hurdle
compared to base domain certs? Very curious.

~~~
tyingq
Some of the original discussion is here: [https://github.com/letsencrypt/acme-
spec/issues/64](https://github.com/letsencrypt/acme-spec/issues/64)

------
dopamean
The company I work for is a large user of Let's Encrypt certs (we order them
for our customer's sites). It doesn't look like we'll be able to use this
since we don't control our customer's DNS.

~~~
geetfun
Yup. We use a lot of Let's Encrypt certs with domain validation via http-01
where our internal API can handle all the requests and validation without the
end user requiring any technical knowledge.

It seems they will evaluate other options, but it's hard to imagine they would
use something as convenient as http-01 for wildcards as then it opens up the
platform to major abuse.

~~~
dopamean
How would it open up the platform for abuse (serious quetion, not snark)? The
CA we use to get wildcard certs for our customers uses a challenge process
very similar to LE's http-01.

------
LinuxBender
Serious question. What does LetsEncrypt buy me that I could not get from
having a knob in applications and browsers that lets me accept self signed
certs?

To be clear, the reason I am asking is that historically a CA was intended to
be a way to validate "who" you are talking to. LetsEncrypt is providing a
signed cert that does not validate an entity. It just solves the self signed
cert, which could also be solved in applications by having a setting to
"Accept Self Signed Certs". Some apps and appliances already have this.

~~~
azernik
CAs in practice don't verify who you are; they just verify that you are the
entity that controls a particular domain name.

LetsEncrypt does this automatically, for free, and in a more user-friendly
way. For information on the security considerations involved, see [1]. These
are similar considerations to those of most DNS-based CA verification methods
(which is most of them).

[1] [https://ietf-wg-acme.github.io/acme/draft-ietf-acme-
acme.htm...](https://ietf-wg-acme.github.io/acme/draft-ietf-acme-
acme.html#rfc.section.10)

~~~
protomyth
> CAs in practice don't verify who you are; they just verify that you are the
> entity that controls a particular domain name.

Strangely, our CA called our human resource department to verify a lot of the
information. I guess its all in who you chose.

~~~
pfg
It's not about the CA, it's about the level of validation your chose. All
major CAs offer all three levels of validation - DV, OV, EV. DV doesn't
involve any verification of personal/company details, no matter the CA.

~~~
tialaramex
You don't get to say "all major CAs" referring to everybody else now, Let's
Encrypt is definitely a major CA too now :-)

Also some (maybe you don't think they're major?) don't offer DV. After all
they can't be cheapest or fastest so why not focus on a product with higher
value.

------
e12e
This is fantastic news. I just whish x509/browsers/other clients could be
fixed with proper support/implementation for scoping, so signing a _CA cert_
limited to a single TLD wouldn't be a big deal.

That way, Letsencrypt could've just signed a CA cert that was authorised to
sign certs for anything under example.com - but not for anything else - and we
could bootstrap trust in internal/local CAs just as we now do with
certificates.

------
hdhzy
Wow, very cool. I wonder if elliptic curve certificates and intermediaries via
certbot are also in the pipeline. P-256 can be issued via manual CSR and EC
intermediaries are scheduled "before September" according to
[https://letsencrypt.org/upcoming-features/](https://letsencrypt.org/upcoming-
features/)

------
benth
I recently read about how Plex got trusted SSL certificates for all their
users in partnership with DigiCert, and was really curious if a similar scheme
could be accomplished with Let's Encrypt. The scheme required wildcard
certificates so I figured it wouldn't be possible. But with this announcement,
maybe it would be! I work on a product that generates a self-signed cert and
so our customers always get a cert warning. They can replace the cert with
their own if they like, but some customers aren't set up to do that. Offering
an alternative where we securely mediate creation of a trusted SSL cert would
be fantastic.

See: [https://www.plex.tv/blog/its-not-easy-being-green-secure-
com...](https://www.plex.tv/blog/its-not-easy-being-green-secure-
communication-arrives/) and [https://blog.filippo.io/how-plex-is-doing-https-
for-all-its-...](https://blog.filippo.io/how-plex-is-doing-https-for-all-its-
users/)

~~~
tialaramex
If your product consists mainly of a HTTPS service with some particular
Internet accessible fully qualified domain name, say [https://benth-
app.customername.example/](https://benth-app.customername.example/) where your
customer owns customername.example then it's possible already today although
you should ensure the customer is told what you're up to of course.

If your service doesn't provide HTTPS or customers don't have it accessible
from the public Internet then you'd need cooperation from them unless you
yourselves control the DNS records involved.

~~~
benth
In our case, the appliance usually can access the internet, possibly through a
proxy, but it's not accessible from the internet.

------
gsylvie
I want multi-wildcard-certs (using subject alternative names aka SAN). Also,
if I get a cert that covers:

    
    
        [*.a.company.com] and [*.b.company.com]
    

Can I please also have [a.company.com] and [b.company.com] stuffed into two
additional SAN slots!

p.s. How do I get an inline asterisk into my HN comment!?

~~~
pfg
Wildcard issuance and validation hasn't been implemented yet, but I see no
reason why this shouldn't be possible once the feature is rolled out. My best
guess is that you'll be able to mix wildcards and FQDNs to your liking,
provided that you can demonstrate control of all domains.

------
taylorbuley
In my best Oprah voice: "Subdomains for everybody! _You_ get a secured
subdomain.. _you_ get a secured subdomain..."

In seriousness, I pine for the post `~username`, pre-`/username` days where
services would hand out subdomains for user management. It still happens --
viz Tumblr, etc. -- but I feel like it's less frequently then it used to. One
reason I would avoid is that wildcard certs are pricey. Nice to see that will
commoditize a bit come January.

------
nvr219
Can I get Windows/IIS support please?

~~~
tialaramex
ACME is on the path to IETF standardisation, and all of Let's Encrypt is Free
Software, so Microsoft absolutely could enable this in a future IIS version.
If you're a customer it can't hurt to tell MS you want this.

Meanwhile you're at the mercy of third party probably volunteers to make what
you want possible.

------
rsanaie
Thank you so much for your efforts!!

------
gonmf
This is great news!

------
a1exus
thank you!

------
JepZ
Hooray!

------
ikrisztian
What if id like to scan objects with my phone's cam, and use those in VR?

------
IncRnd
It is a serious security issue to add wildcard certificates for multiple
unrelated domains.

------
stephenr
_Sigh_.

Wildcard certs, that are generally seen as a security risk, and could have
been alleviated for most legitimate uses with higher limits on issuance per
domain will be supported.

But S/MIME, the email encryption option that actually works out of the box in
basically every mail client, sorry, nothing doing.

