Live data from Hacker News

ACME v2 and Wildcard Certificate Support is Live

community.letsencrypt.org

261–270 of 321 posts

Re: ACME v2 and Wildcard Certificate Support is Live

#261
post #255

Earlier quoted context omitted.

One option is to run your own BIND instance configured however you like, and pay for one or more secondary DNS services to sync off it. You can even hide your own BIND instance from everyone outside your network and just point your NS records at the secondaries, if you’re worried about misconfiguration/DoS attacks/etc.

That sounds interesting. Would you know of any secondary DNS service headquartered in Europe? I always wanted to host DNS myself but since I lack a secondary DNS...

Unfortunately don't know any EU-based services, but all the big services have their actual servers available in most locations.

Re: ACME v2 and Wildcard Certificate Support is Live

#262
post #177
post #78

Earlier quoted context omitted.

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.

There are a variety of attacks against GPG-signed repositories - an article [1] by Joe Damato explains them, and that all can be trivially mitigated by serving the repositories with TLS. [1]: https://blog.packagecloud.io/eng/2018/02/21/attacks-against-...

On HN: https://news.ycombinator.com/item?id=16432435

Re: ACME v2 and Wildcard Certificate Support is Live

#263
post #198
post #174

Earlier quoted context omitted.

> Putting a TLS certificate on your shit with LE takes minutes. Doing it through another CA is minutes if you have one server, yes. else it's the other way around, because if you have multiple servers you need to do a lot of fancy stuff. And LE also does not work in your internal network if you do not have some stuff publicy accessible. And it also does not work against different ports. Oh and it's extremly hard to h…

You can use Let's Encrypt certificates for non-publicly reachable hosts by using the dns-01 challenge type. That, of course, means that you need some way of properly automating your DNS infrastructure to add the necessary TXT records which, admittely, is sadly not the case in many organizations. It's a solvable problem, though. I don't understand your last point. Where do you see the problem with letting a reverse pr…

Well the last point means that I need to rollout the cert to multiple servers (as the poster below writes)

Re: ACME v2 and Wildcard Certificate Support is Live

#264
post #70

Earlier quoted context omitted.

A lot of ISPs, some huge like the "XfinityWifi" SSID, routinely inject their own javascript in HTTP pages. Some even take no care to namespace their javascript and wreck a party on your window globals, too.

This could be solved without HTTPS. People choose not to for ideological reasons.

How would you solve it without HTTPS?

Re: ACME v2 and Wildcard Certificate Support is Live

#265
post #245

Earlier quoted context omitted.

Is there a "standard" TLD for internal use that will also fit this requirement? The problem here is that there's no such thing as domain ownership, only domain renting. You forget to pay your bill (read: someone loses an email) and a core part of your infrastructure is up in smoke, or worse, taken over by a squatter.

Of course not. If there was a domain reserved for internal use and everyone could get a cert for it, everyone would be able to impersonate your internal hosts. I don't think there's a way around coming up with a reliable process for renewing your domain. You somehow manage to do it for lots of other things already.

Some years ago, at least one of the popular CAs used to issue certs for RFC1918 IP addresses. Fun times.

Re: ACME v2 and Wildcard Certificate Support is Live

#266

Earlier quoted context omitted.

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

For provider with DNS support, you can put it in a cron, and then create symlink or some copy step at the end of cron to copy private key and full chain to appropriate location of your web server. I think acme.sh is the easiet to use in all of clients.

Thanks again. Everything works.

I've put my DNS to Cloudflare and after that the acme.sh was incredibly easy to implement thanks to their API implementations.

Also learned a valuble lesson: *.provider.com is not the same as provider.com :)

Re: ACME v2 and Wildcard Certificate Support is Live

#267
post #254

Earlier quoted context omitted.

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

I doubt they would just break it. I imagine if they do this then this will be announced sufficiently in advance (probably around two or three years) to allow people to update their ACME clients. Then you can just operate the ACMEv1 for existing domains until noone is asking for more (and scale down the architecture).

The problem is that LE is being used as plumbing. I noticed MIAB was using LE because I recognise that SSL-out-of-the-box is something interesting, and I investigated. But I wager most people who use it will have no idea. They just install it, and "it works", as it should. great. What's HTTPS? That's the entire point of tools like MIAB, mind you:

> Technically, Mail-in-a-Box turns a fresh cloud computer into a working mail server. But you don’t need to be a technology expert to set it up.

https://mailinabox.email

I'm just choosing MIAB as an example here. This applies to anything that LE now enables. People don't know they're using LE, much like IOT users don't know they're using HTTP/1.1. It's part of the plumbing. What's an ACME client? What's LE? What's v1?

This is probably happening for IOT devices across the globe just the same. A 2y expiration date is an order of magnitude too low for plumbing. Imagine if we suddenly decided to phase out HTTP/1.1 within two years.

We have to recognise that we are shoving HTTPS down people's throats. Pretty soon, HTTP will get big f-off warnings. OK: fair enough. However, if we're doing that, we should also provide a viable alternative, with the same reliability. Otherwise, HTTPS is a massive step backwards for the decentralised web. LE is that alternative, but not if we start breaking backwards compatibility every 2 years.

Re: ACME v2 and Wildcard Certificate Support is Live

#268
post #254

Earlier quoted context omitted.

I doubt they would just break it. I imagine if they do this then this will be announced sufficiently in advance (probably around two or three years) to allow people to update their ACME clients. Then you can just operate the ACMEv1 for existing domains until noone is asking for more (and scale down the architecture).

The problem is that LE is being used as plumbing. I noticed MIAB was using LE because I recognise that SSL-out-of-the-box is something interesting, and I investigated. But I wager most people who use it will have no idea. They just install it, and "it works", as it should. great. What's HTTPS? That's the entire point of tools like MIAB, mind you: > Technically, Mail-in-a-Box turns a fresh cloud computer into a workin…

Again, I'm not saying that the two year expiration date means "v1 stops working".

Rather, "after this point, no new domains may setup via v1", so any existing certificates and installations are grandfathered. Two years is sufficient for MIAB to update their software and distribute to users.

>LE is that alternative, but not if we start breaking backwards compatibility every 2 years.

Not what I'm saying either. They have a v2 now, we don't know if they need a v3. And they want to keep v1 running for a while.

But there will be a point where v1 will need to be switched off, similar to how modern browsers have switched off SSLv1 despite a lot of people still having servers running with that.

LE will, at some point, have to decide between keeping v1 running or moving away from old protocols to be able to evolve. And that cannot be infinitely pushed backwards.

Re: ACME v2 and Wildcard Certificate Support is Live

#269
post #184

Earlier quoted context omitted.

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

I don't trust any US company, so it's not any more untrustworthy for me than DigiCert, for example. I'm dropping its name because they were offering free 3-year certificates and it was the best TLS experience I've ever had.

Re: ACME v2 and Wildcard Certificate Support is Live

#270

Earlier quoted context omitted.

I have been MitM'd by my ISP, Comcast, multiple times. Their injection only works on HTTP without TLS.

Sure, I've heard of the Xfinity MitMs which IIRC tracked users in some way. But would that realistically cause any "professional detriment" as expressed by the parent comment? Most users wouldn't even notice it's happening. Basically, I see it this way: - You can be MitMed broadly, like the Xfinity case, but the company in question can't really do anything crazy like inject viruses or do something that would cause th…

As less and less content is served over HTTP, it becomes more and more realistic for an attacker to simply inject their garbage into every unencrypted connection that has a browser user agent in it.

Consider the websites you view every day.. most of them are probably HTTPS by now.

It's the wild west, basically. Regardless of how likely it is that someone is waiting for you to hit a HTTP site right now so they can screw with it, why even take that risk when the alternative is so easy?

Post reply on HN