Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ACME v2 and Wildcard Certificate Support is Live

community.letsencrypt.org

Post reply on HN
Print view View original

181–190 of 321 posts

Re: ACME v2 and Wildcard Certificate Support is Live

#181

Post by [deleted] »

Siecje wrote: post #27
kyledrake wrote: post #7

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 lo…

When you run the Let's Encrypt official client (certbot), it updates itself.

[deleted]

Re: ACME v2 and Wildcard Certificate Support is Live

#182

Post by vbezhenar »

orf wrote: post #88
eric_b wrote: post #55

Earlier quoted context omitted.

> Those devs are gonna be really surprised when they find out that unencrypted connections are routinely tampered with. Except most big orgs now employ MitM tools like BlueCoat to sniff SSL connections too. > You have not been paying attention to the hundreds of tools available to make HTTPS painless. I have, and they don't. They make it easier, but you know what's truly painless? Hosting an html file over HTTP. What…

It's like one apt package and one cronjob away. I think some acme clients even do the Cron handling for you. So, like one command. There is a really great acme client written in bash which is incredibly painless to set up. Literally in the time you've spent thinking about and composing your reply you could have implemented free, secure TLS for your users.

It's not that easy if you don't want to run public http server. I had to write acme client myself because I didn't find a single one simple enough. I spent weeks doing that, comparing to 5 minutes issuing 3-year certificate from wosign when it was a thing. I hate that Google destroyed every free ssl certificate issuer and pushed their child to further dominate the world.

Re: ACME v2 and Wildcard Certificate Support is Live

#183

Post by nothrabannosir »

irq-1 wrote: post #178
jaas wrote: post #61

Earlier quoted context omitted.

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.

You could block new domains (new to Lets Encrypt) from using v1.

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

Re: ACME v2 and Wildcard Certificate Support is Live

#184

Post by niij »

vbezhenar wrote: post #182
orf wrote: post #88

Earlier quoted context omitted.

It's like one apt package and one cronjob away. I think some acme clients even do the Cron handling for you. So, like one command. There is a really great acme client written in bash which is incredibly painless to set up. Literally in the time you've spent thinking about and composing your reply you could have implemented free, secure TLS for your users.

It's not that easy if you don't want to run public http server. I had to write acme client myself because I didn't find a single one simple enough. I spent weeks doing that, comparing to 5 minutes issuing 3-year certificate from wosign when it was a thing. I hate that Google destroyed every free ssl certificate issuer and pushed their child to further dominate the world.

>wosign

Are you name dropping wosign just to be obtuse? They were untrusted because they were untrustworthy, not because Google just doesn't like them. https://www.schrauger.com/the-story-of-how-wosign-gave-me-an...

Re: ACME v2 and Wildcard Certificate Support is Live

#185

Post by niij »

rospaya wrote: post #153
greglindahl wrote: post #90

Earlier quoted context omitted.

You do realize you're making this complaint on a discussion about a tool that makes HTTPS easier for said small hobbyist websites? I've updated all of my hobby sites using Let's Encrypt, and I really appreciate how it was easy for me while also being good for my users.

My comment isn't against Let's Encrypt. It's against blacklisting text only sites that don't need HTTPS.

If a "text-only" website is on HTTP it can be MITM'ed and used to serve up malicious JS.

Re: ACME v2 and Wildcard Certificate Support is Live

#186

Post by b3lvedere »

massaman_yams wrote: post #169

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

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.

Re: ACME v2 and Wildcard Certificate Support is Live

#187

Post by mynameisvlad »

Karunamon wrote: post #96
eric_b wrote: post #55

Earlier quoted context omitted.

> Those devs are gonna be really surprised when they find out that unencrypted connections are routinely tampered with. Except most big orgs now employ MitM tools like BlueCoat to sniff SSL connections too. > You have not been paying attention to the hundreds of tools available to make HTTPS painless. I have, and they don't. They make it easier, but you know what's truly painless? Hosting an html file over HTTP. What…

Oh, so you know better than me what kind of content is on my site? So a static site with my resume needs SSL then to protect the other users? Absolutely yes. Without that layer of security, anyone looking at your resume could either be served something that's not your resume (to your professional detriment) or more likely, the malware-of-the-week. (Also to your professional detriment). Do you care for the general saf…

So I've heard this argument countless times, and it completely makes sense from a theoretical perspective. Yes, it's very possible for MitM to happen, and that would cause one of the two scenarios you described.

But how likely is it to actually happen? For the former, someone would need to target both you and specifically the person who you think will view your resume, and that's, let's be honest, completely unlikely for most people. The second case I can see happening more in theory as it's less discriminating, but does it actually happen often enough in real life to the point where it's a real concern?

FWIW, I have HTTPS on all my websites (because, as everyone mentioned already, it's dead simple to add) including personal and internal, but I still question the probability of an attack on any of them actually happening.

Re: ACME v2 and Wildcard Certificate Support is Live

#189

Post by gumby »

jaas wrote: post #133
gumby wrote: post #132

Earlier quoted context omitted.

You might simplify things for yourself to some extent by requiring ACMEv2 for wildcard requests, which will reduce the number of people deploying the old client and spur many to upgrade. And your old client still works on the systems it's deployed on (by definition) so you could just stop development on that.

Wildcards are only available via ACMEv2. The post linked to here says that.

d'oh, I overlooked that (and I still had the post open in another window!). Thanks.

It's bad enough that some people comment without reading -- I apparently commented without paying attention.

Re: ACME v2 and Wildcard Certificate Support is Live

#190

Post by PuffinBlue »

eric_b wrote: post #100
BryantD wrote: post #92

Earlier quoted context omitted.

I hear you. Moving to SSL for millions of old websites is a pain in the ass. It's a degree of effort that people often skim over. Speaking as someone who's maintained a lightweight presence on the Web for over 20 years, I've thought about the tradeoff and I think it is worth it. Our collective original thinking about protocols skipped security and we've been suffering ever since. I was sitting in the NOC at a major I…

Yeah, I'm not opposed to HTTPS. In fact, the reason I get frustrated is because, like you, I've dealt with it at scale for years. I agree it should be used most places, but what about static documentation sites? What about blogs? I've even used Let's Encrypt a few times, and it seems like a great service. But who wants to set up that machinery for a simple resume site? That machinery has a cost. With every barrier we…

> It's so much easier to just say "HTTPS everywhere" than to examine the tradeoffs.

This touches on the real point of all this, which doesn't seem to have been contained in any replies to you.

There's no real choice in the matter, https is a requirement if, and that the very big if right there, we truly acknowledge that the network is hostile. With a hostile network the only option is to distrust all non-secure communication.

https isn't about securing the site as you know, it's about securing the transmission of data over the transport layer, and it's needed because the network is hostile.

It doesn't matter one little iota what the data is that's traversing it, as there's no way to determine its importance ahead of time. A resume site might not be of much worth to the creator, but the ecosystem as a whole ends up having to distrust it without a secure transport layer because the hostile network could have altered it.

It doesn't matter the effect of that alteration might be inconsequential, as there's also no way to determine that effect ahead of time. The ecosystems 'defense' is to distrust it entirely.

And that's the situation the browsers/users/all of us are left with. There's is no option but to distrust non-secured communication if the network is hostile.

Post reply on HN