Live data from Hacker News

ACME v2 and Wildcard Certificate Support is Live

community.letsencrypt.org

131–140 of 321 posts

Re: ACME v2 and Wildcard Certificate Support is Live

#132
post #61

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…

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

Re: ACME v2 and Wildcard Certificate Support is Live

#133
post #132
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 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.

Re: ACME v2 and Wildcard Certificate Support is Live

#134
post #83
post #43

Earlier quoted context omitted.

The SSL zealotry drives me nuts. The infosec community screams constantly about "HTTPS everywhere", but they either don't know or don't care about all the effort and pain they're creating for developers who just want their software to work. How many perfectly good sites will be marked ominously as "insecure" by Chrome in the next few months? Sites that were working just fine until someone at Big G decided they weren'…

My favorite part of the internet were always the small hobyist websites. The guy that has an encyclopedic database about Grateful Dead trivia, the other guy that collects pictures of plants. Those people are independent, they're not technical and their 90s looking websites are going to go under because of blanket security policies that don't concern them.

If not SSL, then they'd go away at the point some other technical change dropped. Or do you suggest "we" continue using broken protocols forever in order to preserve them? Do you still support telnet to accommodate people who can't handle `ssh-keygen`?

In any case, (a small subset of) the random enthusiast sites and such are close to the only reason I use a browser recreationally anymore. I absolutely agree with you.

The answer isn't to stop fixing things. The answer is to make it easier and cheaper to be secure.

Kinda like what LE is doing, no?

Re: ACME v2 and Wildcard Certificate Support is Live

#135
post #78
post #49

Earlier quoted context omitted.

> developers who just want their software to work. Those devs are gonna be really surprised when they find out that unencrypted connections are routinely tampered with. > they either don't know or don't care about all the effort and pain they're creating You have not been paying attention to the hundreds of tools available to make HTTPS painless. > until someone at Big G decided they weren't. And Mozilla. And countle…

What about hosting HTTP content because you verify GPG signatures upon download? These content would then be super easy to cache on the local network. HTTPS defeats this and makes it uncachable. I hardly ever see people talk about this use case and how to solve it with https everywhere. AND it's super widely used: e.g. debian repositories.

HTTPS doesn't make it uncacheable - you can still mirror an HTTPS repository with another HTTPS repository (with its own domain name and certificate), and preserve the PGP signatures inside the repository. apt works fine with exactly this model: you use HTTPS for transport-layer protection and GPG for the existing things Debian's security model was already good at. The Debian repository is behind HTTPS at https://deb.debian.org - in existing Debian releases you may need to install apt-transport-https, and then just set your sources.list to

    deb https://deb.debian.org/debian stable main
HTTPS cannot be used as a replacement for PGP in this scenario, but that's the wrong way to see HTTPS. It doesn't provide purpose-built security for people who have custom threat models and need to build security infrastructure anyway (e.g., Debian verifies PGP signatures on sets of packages uploaded by developers, and then builds those packages and puts them into signed archives). HTTPS is baseline security - it's the security that every web connection should just have. It's not surprising that some specific use case like Debian repositories needs more-than-baseline security.

And because HTTPS is nothing more than baseline security, it's possible to automate it with things like Let's Encrypt and not add any more checking beyond current control of DNS or HTTP traffic to the domain.

(Another confusion along these lines is assuming HTTPS is useful as an assertion that a site isn't malware. It asserts no such thing, only that the site is who it claims to be and network attackers are not present. If I am the person who registered paypal-online-secure-totes-legit.com, I should be able to get a cert for it, because HTTPS attests to nothing else.)

Re: ACME v2 and Wildcard Certificate Support is Live

#136

Earlier quoted context omitted.

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

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

Technically, certificates automatically validated only guarantees that you are on the website that let's encrypt thinks correspond to facebook.com. MiTM state wide could tamper with it

Re: ACME v2 and Wildcard Certificate Support is Live

#137

Earlier quoted context omitted.

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.

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.

[deleted]

Re: ACME v2 and Wildcard Certificate Support is Live

#138
post #80
post #74

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

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.

I agree that it’s terrible, but the reason they used to recommend .local goes back to their Small Businness Server in the 1990s when it was very expensive and bureaucratic to register a domain - not something they could demand of their target market. MS’s error was their failure to update their recommendations after domain registration became cheap and easy.

Re: ACME v2 and Wildcard Certificate Support is Live

#140

Earlier quoted context omitted.

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.

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.

Btw the only problem I have with Netlify is the close name conflict with netflix. Chrome's autocomplete is completely confused.
Post reply on HN