
Let's Encrypt ACMEv2 and Wildcard Launch Delay - cm2187
https://community.letsencrypt.org/t/acmev2-and-wildcard-launch-delay/53654
======
sdrinf
While HTTPS is being burned into the architecture of the Web, I have a humble
question to ask: what is the dear HN community's next-best-option in a
scenario if letsencrypt dies/gets sued/goes under/servers not accessible
anymore?

I ponder on this question seeing how Google is planning to increasingly
depreciate HTTP. While in general, I welcome the security upgrade, the lack of
next-best-free-options makes me vary of this config change locking us into a
$$$paid-only web publishing system.

~~~
kemitche
ACME is a protocol - I imagine most of us are hoping that, should LE fade off,
one or more others take the reins and implement it.

~~~
badrabbit
With PKI,a good protocol isn't the problem but rather making the cost of
infrastructure keep-up worthwhile. Anyways, non-pki protocols are in the
works.

~~~
sdrinf
> non-pki protocols are in the works.

Could you kindly link to relevant threads / RFCs / orgs / undertakings
currently working on that, please?

~~~
aeden
DANE might provide a solution. See specifically the section
[https://tools.ietf.org/html/rfc6698#section-2.1.1](https://tools.ietf.org/html/rfc6698#section-2.1.1),
certificate usage 3:

3 -- Certificate usage 3 is used to specify a certificate, or the public key
of such a certificate, that MUST match the end entity certificate given by the
server in TLS. This certificate usage is sometimes referred to as "domain-
issued certificate" because it allows for a domain name administrator to issue
certificates for a domain without involving a third-party CA.

~~~
tscs37
This would need DNS to be secured though and DNSSEC is still a bit of a mess
last I checked and not enabled for a majority of DNS traffic.

~~~
aeden
DNSSEC support is increasing each year, but that's just one issue. DANE would
also need to be implemented by browsers for full adoption, not just as a
plugin to specific browsers.

Then again, I was responding to the question about an RFC or other standard,
not whether it was feasible today. ;-)

~~~
tscs37
It would be feasible if DNSSEC wasn't a total mess, tbh. The support for it is
still abysmal and a lot of resolvers (including the one in my router) can't
handle DNSSEC responses _at all_.

I think using DNS over HTTPS in conjunction with signing the response is going
to be more viable since you don't have 200 ways a middle box will break it.

------
ocdtrekkie
It's hard to complain about a slight deadline miss from an incredible project
offering free stuff.

~~~
nodesocket
Precisely the problem. Real companies mostly prefer to use paid solutions
because they have comfort and confidence in knowing there is a business and
backing behind it. At least I know I do. I never got the whole developer
complex wanting and even expecting everything for free. Seems hypocritical and
counter-entrepreneur.

Also for what's worth, I've been deploying Let's Encrypt into production
recently using Caddy and (on-demand) TLS and while it works, the rate limits
being reset weekly is really scary and VERY VERY easy to hit. I know myself
and my clients would be willing to pay for Let's Encrypt Pro (higher rate
limits, etc). Take our money.

~~~
ocdtrekkie
That's not Let's Encrypt's role to play though. As a user, I'd be much more
skeptical of an LE cert'd site than a Verisign cert'd site. That's not a knock
on LE, that's just recognizing a higher barrier to entry. Let's Encrypt's goal
is to get everyone encrypted, not necessarily to ensure everyone is who they
say they are.

And as a fellow person who does real business at times, I often prefer paid
products because I know I can get support from the company backing it. I don't
think Let's Encrypt will replace the entire CA industry, and I don't think it
should. (As tyingq says, monocultures are bad.)

~~~
BrandoElFollito
> not necessarily to ensure everyone is who they say they are

How does Verizon (to take your example) ensures this? They have the same zero
verification process for the non-EV cert.

~~~
ocdtrekkie
At bare minimum, getting a cert almost anywhere else requires a credit card.

~~~
BrandoElFollito
This is not something which helps to decide whether the target website is what
they claim to be.

I can use my CC to buy faccebook.com, and I will get it (again, outside of
EV).

I may then be tracked by Interpol for fraud, but to the end user this does not
change anything: Verizon has issued a certificate for my faccebook.com

~~~
ams6110
IYAM, any major web property such as google, facebook, credit card issuers,
etc. should buy up all the most likely typo-ed versions of their domains so
that this doesn't happen.

The average user is going to blame Facebook anyway if they get duped into
logging in at faccebook.com, and it goes to protecting their brand (trademarks
are weakened if the owner doesn't defend them).

~~~
BrandoElFollito
They do, and if they don't, they end up like the White House a few years ago
when whitehouse.<I forgot the TLD> was bought and an almost exact replica was
created, according to Rule 34.

My point is that you can buy any site from a CA and no verification is done,
exactly as with Let's Encrypt.

Even with an EV there is no guarantee that the requester is genuine ("best
effort" to check)

~~~
tialaramex
With EV the checks basically care about:

1\. Does this entity exist, e.g. it's in an official government business
directory and the address details match what was specified 2\. Use a third
party directory (e.g. Dunn & Bradstreet) to look up this entity, and phone
them. Ask to talk to some specific role at the company e.g. "Head of the IT
department" and then confirm the details with that person.

This involves actual humans, albeit basically call centre employees, looking
at paperwork, making telephone calls, that sort of thing. I guess you could
label it "best effort" but to me that signifies much less.

For Americans a surprise problem with EV is that your country doesn't _have_ a
central business directory. Each State runs its own directory, most businesses
are registered in Delaware, regardless of their actual home state.

[https://stripe.ian.sh/](https://stripe.ian.sh/) has a completely genuine
Stripe, Inc. EV certificate, issued to a Stripe, Inc. just not the one that's
famous.

------
MertsA
Am I the only one who thinks the way we deal with certificates is just
completely backwards? Why should there even be a CA at all for DV certs? We
already have to trust the registrar as ultimately they can get whatever DV
certs they want so why not just limit our trust to them instead of adding
hundreds of additional organizations that can compromise our security? And we
pay them for the privilege of doing this??

I get CAs for EV and OV certs, of course you need an additional trusted party
there, but the vast majority of websites out there do not use EV or OV certs
and to be fair users by and large don't even notice the difference between a
DV and an EV certificate in the first place.

We already have DNS, we already trust DNS to issue certificates to people, why
don't we just cut out the middle man since they serve no additional purpose?

~~~
technion
The thing is that "control of the DNS" can mean different things.

I have control of the DNS on my network, and at the local coffee shop. I can
use that to attack users, but I cannot use that to obtain a certificate.

I still agree with you in a sense, an alternate solution would be great. But
we that middleman is the best we have right now.

~~~
josteink
> The thing is that "control of the DNS" can mean different things.

In every way this discussion is related, "control of the DNS" should mean
control of _the one authoritative DNS source_ , in a way which means that if a
service across the internet requests a DNS record, it won't be affected by
whatever DNS-trick your neighbourhood cafe's wifi may apply.

Trying to muddle the discussion of a fairly straight-forward, reliable
scenario with consumer-space DNS resolution is IMO not very productive.

~~~
icebraining
But that's the point - the CA is needed to make a reliable verification of the
data coming from the authoritative DNS source, since the consumer can't make
that check themselves in an untrusted network.

------
nickjj
I've been using LE from the start and it's been awesome (especially with
clients like acme-tiny), but wildcards changes everything.

How many of you are really going to set up a custom DNS updating script?

Maybe I misread something but I remember hearing wildcard certs will only work
with DNS based challenges.

Wouldn't that mean the verification tool would need to support every single
registrar's / DNS provider's API?

For example, I host my domains (and DNS) with namesilo.com. Is a challenge
script really going to know how to interface with their API to add / remove
the TXT records?

What about the 50 other popular DNS providers?

~~~
piracykills
Yes, but there's already scripts handling many of the most popular.

Check out acme.sh and remember, changing your DNS provider or hosting it
yourself really isn't that bad.

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

~~~
nickjj
Nice, it looks like they support namesilo and ~40 others.

So my suspicion seems accurate. The script will need to know how to interface
with each provider and you (as an end user) will also need to be responsible
for setting up your own API keys for whatever provider you use.

~~~
moviuro
If you're up for the task, I've wanted to write a script (POSIX /bin/sh
certainly) for interaction with DNS providers. Basically lower the entry
barrier, and avoid the web interface:

    
    
        $ foo mydomain.org --init ovh
        $ foo mydomain.org my.sub A 1.2.3.4
        $ foo mydomain.org my.sub AAAA 1234::abcd
        $ foo mydomain.org --remove my.sub A [1.2.3.4]
    

etc.

I have yet to find anything that handles any DNS changes in a simple, stupid
way. Most API clients I've seen only handle one kind of request: acme.sh only
does TXT challenges. DynDNS endpoint only does A records. Etc.

~~~
piracykills
It'd be cool to have and it's relatively straightforward from a software
engineering perspective, but it's so much boring grunt work that finding
someone who wants to implement it might be challenging.

If this is something you need to do a regular basis, you might consider
hosting your own DNS and using BIND's nsupdate tool.

~~~
moviuro
> hosting your own DNS

meh. There are some things that I'd gladly host, but DNS clerly isn't among
them. Too many ways to screw up, probable breakage ahead (only 1 dedicated @
OVH), so many rate-limits to implement; DNS servers a re filled with RCEs...
(bind being the worst).

Clearly, nope. Not doing this ;)

------
berbec
Crap. I had certs set to expire on 2/28! I was going G to be saved by
wildcard. Off to make a bunch of DNS entries....

~~~
schoen
Does your ACME client already support ACMEv2 and wildcards? I think only
acme.sh has so far claimed to (happy to be corrected if another client has
finished its implementation).

~~~
berbec
I use certbot. I'm not sure as I was just planning on figuring it out for the
night of expiration.

~~~
schoen
I'm part of the Certbot team and I can tell you that the ACMEv2 support is
still being implemented by my colleagues now; even if it had been included in
a release this week or next, you would have been cutting it pretty close! Many
of our users don't have the most current release because distribution
packagers don't ship it right away (or even for months or years, depending on
circumstances).

Certbot's own autorenewals (which I originally implemented and which I hope
are currently working for you -- I'm happy to try to find a way to get them to
work in your deployment if they're not!) try by default to renew certificates
30 days before expiry in order to give people a lot of time to notice and
intervene if something goes wrong. Consistent with that, I'd encourage all of
our users not to rely on anything happening less than 30 days before expiry as
part of their plan for keeping certificates current on their sites.

~~~
berbec
Thank you for all your work. My renewal went through fine. I had commented it
out of crontab, but went fine once I ran it. I was pleasantly surprised when
tls-sni worked flawlessly.

~~~
schoen
Great!

One thing to know about the TLS-SNI situation is that TLS-SNI-01 has been
disabled for new issuance and only works for renewals. The selection of
authentication methods is pretty transparent because the ACME protocol allows
the CA to state which methods it will accept for a particular domain
authorization (so for the renewals it can state that TLS-SNI-01 is permitted,
while for new issuance it can state that it's not, and a client can respond
accordingly).

Apparently the ACME WG is working on a TLS-SNI-03 method that will be safer
and that might be supported by Let's Encrypt (and ACME clients) at some point.
But it's also possible that TLS-SNI-01 could be disabled in the future, even
for renewals, even before TLS-SNI-03. So, if you happen to have anything in
your setup that prevents the use of HTTP-01 on port 80 for authentication, you
should be aware that renewals could potentially stop working at some point
(although this isn't imminent), and that you might also have difficulty adding
new domain names to your certificates.

[https://community.letsencrypt.org/t/important-what-you-
need-...](https://community.letsencrypt.org/t/important-what-you-need-to-know-
about-tls-sni-validation-issues/50811)

This unfortunate situation is a nice showcase of the ACME protocol's
flexibility, because the CA has a way to tell the client very specifically
what authentication methods to attempt or not to attempt for each domain (and
if new methods are specified in the future, they can be rolled out
incrementally without breaking compatibility).

~~~
tialaramex
One thing that'd be good here for outside observers is for Let's Encrypt to
bake a list of the Blessed Methods used into certificates as OIDs in the
Policy section.

Right now a researcher with 5 million Let's Encrypt certificates can see which
ones use public keys with unusual patterns, how many are for names in the
French .fr TLD, how many have longer key lengths, and so on, but they can't
see whether the validation was done with Method 10 (which had this unexpected
flaw) or some other method.

Another CA (can't remember which one) was looking at doing this, and it seems
like it'd be nice for Let's Encrypt too.

~~~
schoen
I like this kind of thing in principle, but certificates are already getting
kind of large and there are a number of other things that one might put in
them via OIDs. But I realize ASN.1 is pretty concise; do you know about how
much this proposal would increase the size of a certificate by?

Another concern might be that users might not want this to be disclosed
because it might give attackers suggestions about how to attack their renewal
processes (although of course CAs have been willing to publish information,
like issued certs, that some users wouldn't prefer to make public).

------
technion
It's not mentioned, but I'm assuming this feature with the same original
schedule:

Embed SCT receipts in certificates

Is also delayed? I think this has been quite underrated.

~~~
discreditable
I've been following progress in their GitHub issue for it:
[https://github.com/letsencrypt/boulder/issues/2244](https://github.com/letsencrypt/boulder/issues/2244)

Most recent comment:

> We're working hard on it, but will probably not land this in production
> before the end of February. Still, we are very much aware of the upcoming
> deadline and committed to meeting it. Thanks for the enthusiasm everyone!
> :-)

