Let's Encrypt ACMEv2 and Wildcard Launch Delay

https://community.letsencrypt.org/t/acmev2-and-wildcard-launch-delay/53654

by cm2187 • 8 years ago

140 74 8 years ago

community.letsencrypt.org

berbec3• 8 years ago

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

mustardo• 8 years ago

That's ok you still have almost 26 months ;-p

tty7• 8 years ago

slow clap :D

schoen4• 8 years ago

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

berbec3• 8 years ago

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

cm21874• 8 years ago

It’s not super hard to implement yourself, particularly given it is a variation of the first ACME protocol for which there is lots of code available, and the staging API for v2 is already up and running.

The main challenge is that wildcards require DNS authorization, so a full automation is DNS api specific. My DNS (OVH) has a neat rest API. But given the variety of DNS providers and APIs it is going to be challenging to rely only on a reference implementation without wrtiting a little bit of code yourself.

ocdtrekkie3• 8 years ago

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

tyingq2• 8 years ago

I am a little worried about the monoculture LE is creating.

I don't have any bright and practical ideas to fix that, however. Short of some other consortium making an equivalent, but with different tech underneath.

marcosdumay• 8 years ago

For TLS certificate authorities, a monoculture is way better than the alternative.

nodesocket• 8 years ago

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.

ocdtrekkie3• 8 years ago

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

cm21874• 8 years ago

For any medium or large company, the $200-ish cost of a commercial wildcard certificate is a non problem. I think let's encrypt is mostly useful for small businesses and individuals, who can live with these limits.

ryanqian• 8 years ago

Me too, the rate limit is preventing me to keep on using LE.

liveoneggs• 8 years ago

this is the second delay

sdrinf2• 8 years ago

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• 8 years ago

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.

badrabbit2• 8 years ago

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.

dorfsmay• 8 years ago

But it would have to be somebody who already have their public root keys in all the browsers.

cm21874• 8 years ago

But Let's encrypt is not just the ACME protocol, it is ACME + free certificates.

fulafel• 8 years ago

With Lets's Encrypt, consensus hopefully strengthens that the cert system is not a good situation. This may eventually web browsers to support TLS PKI methods other than X.509.

icebraining3• 8 years ago

Free is certainly nice, and I'd probably go back to self-signed for a few private subdomains, but you can get a paid cert for under $3/year. The only people really screwed would be those running a non-profit project that used many (sub)domains.

discreditable2• 8 years ago

Where are these $3/year certs? Cheapest I've found is about $9.

piracykills3• 8 years ago

The thing about certificate authorities is the whole system is as insecure as the worst of them, so you may as well go find the cheapest.

I've even managed to get wildcards for $30/year from an alphassl reseller.

nickjj3• 8 years ago

My automation tools are slowly migrating towards a proper PKI set up that supports ACME, self signed certs and external certs (vendor signed certs from anywhere).

I first saw this strategy used in the DebOps project's PKI Ansible role at https://docs.debops.org/en/latest/ansible/roles/debops.pki/.

Basically if LE goes down, all I have to do is make 1 line of YAML changes, run an Ansible script and my servers are secured by a different provider's certificate.

MertsA2• 8 years ago

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?

BillinghamJ• 8 years ago

This is the idea behind DANE :)

https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

Effectively, you’d serve a self-signed certificate, then use DNSSEC to state that the origin can use the self-signed cert. Then clients can use that without showing warnings.

However, it does rely on DNSSEC not being a total failure, so not likely to end up in widespread use anytime soon unfortunately.

Also, given the more recent growth of alternative solutions to the problems DANE solves, like Let’s Encrypt and CAA DNS records, I’m not sure we’re likely to see much more work being done on it sadly.

technion4• 8 years ago

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.

josteink2• 8 years ago

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.

ams61104• 8 years ago

So if I fix my DNS to 8.8.8.8 (or other well-known public DNS) does that not largely squash the coffee-shop attack vector?

MertsA2• 8 years ago

I mean strictly in the sense that we already have root servers pointing to TLDs pointing to individual domains all the way down. I'm not suggesting DANE in particular here I'm suggesting trust one "Super CA" that signs a "sub CA" for a TLD that signs another sub CA for the domain which can keep doing the same thing. Basically just chain each CA together but all of the sub CAs would be further and further constrained such that .ly couldn't sign certs for .com and ycombinator.com could only sign certs for subdomains of ycombinator.com.

In essence, we already trust the registrars to link a name to an entity, DV certs are just going to defer the judgement to the registrar so why bother trusting an additional entity to issue certs for every domain instead of just having the registrar sign your CA that can only issue for your domain and only until your domain expires.

Right now AFAIK I can technically get a SSL cert for a domain I control and have it expire well past when the domain expired and was transferred to another party. I now have a valid certificate for a domain that I don't own.

josteink2• 8 years ago

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.

You could also say the same for HTTP vs HTTPS (except HTTPS being considerably slower on unreliable networks).

So what's the value add in forcing everyone (even those who don't want to and have no need) to use HTTPS?

tialaramex5• 8 years ago

The "no need" case is pretty thin.

People seriously underestimate how little you are promised in the plaintext HTTP scenario over a potentially hostile network (ie almost any network)

Everything you say, or the site says, can be read and changed by any third party between you on the network and there'd be no sign they did so, no trace left.

That's almost never what you actually wanted, so, why should we keep allowing indeed arguably encouraging this practice?

ams61104• 8 years ago

Am I the only one who thinks the way we deal with certificates is just completely backwards?

No. https://www.tedunangst.com/flak/post/moving-to-https

technion4• 8 years ago

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.

discreditable2• 8 years ago

I've been following progress in their GitHub issue for it: 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! :-)

nickjj3• 8 years ago

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?

gerdesj• 8 years ago

pfSense has a dynamic DNS updater built in with support for a huge number of services - https://doc.pfsense.org/index.php/Dynamic_DNS . There's also an ACME client and HAProxy packages and a built in CA and cert handler.

Its all open source, so grab their scripts ...

yrro• 8 years ago

If only there was an existing standardized way to transfer zone updates to an existing DNS server...

piracykills3• 8 years ago

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

nickjj3• 8 years ago

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.

Let's Encrypt ACMEv2 and Wildcard Launch Delay

Related Stories