Live data from Hacker News

ACME v2 and Wildcard Certificate Support is Live

community.letsencrypt.org

111–120 of 321 posts

Re: ACME v2 and Wildcard Certificate Support is Live

#111
post #80

Earlier quoted context omitted.

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.

The ".local" suffix was a terrible idea, to be sure. Active Directory domain rename in small environments is relatively painless.

Unless of course, you are running Exchange. In which case it's not supported :(

Re: ACME v2 and Wildcard Certificate Support is Live

#112

Can this be used for multi-level subdomains? Like *.subdomain.example.org?

No, but that limitation is due to wildcard certificates specifications - not LE.

I'm mainly just trying to solve an issue where I've got end users who think there's a security problem because they've typed www.myorg.example.org instead of myorg.example.org and the wildcard DNS entry in Route53 picks it up...which directs the user to an Insecure error.

Trying to figure out how to get Route53 to stop the wildcard at the top level or get a wildcard cert that will go down the path.

Re: ACME v2 and Wildcard Certificate Support is Live

#113
post #95
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…

You could do this before too, without wildcards.

You could, but the wildcard cert makes it much easier...

"One cert to rule them all, and in the darkness 'bind' them."

Re: ACME v2 and Wildcard Certificate Support is Live

#114
post #21

Can anyone list any negatives of Let's Encrypt? I've been using it since the start and just can't find any practical downsides.

The one that always sticks out is the certs’ extremely short expiration period. The IMHO weak rationale for this was mentioned in another thread here (See jjeaff‘s response upthread). It would be nice if they simply offered two choices: 1. I love automation! Give me a 90 day certificate. 2. I understand the security trade-offs. Give me a 3 year certificate.

But issuing 3-year certificates would disqualify them as a CA: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-...

Re: ACME v2 and Wildcard Certificate Support is Live

#115
post #26

On the face of it wildcard certs seem easy to implement - just match anything in place of the * - but clearly that's not the case as it took years to complete, anyone mind sharing some of the subtle challenges and complexities involved

Dynamic DNS providers is one -- I probably shouldn't be able to get a wildcard cert for any of these [1] domains, but permitting *.mysubdomain.hostname.com is probably OK [1] https://www.dtdns.com/dtsite/faq#hostdomains

Let's Encrypt uses the Public Suffix List (https://publicsuffix.org/) in their issuance process to handle those sorts of cases.

Re: ACME v2 and Wildcard Certificate Support is Live

#116
post #95

Earlier quoted context omitted.

You could do this before too, without wildcards.

Can you outline the approach how this would work? It was my understanding that in order to use Let's Encrypt you needed a public facing server to verify ownership.

For the standard LE certs, you need a public facing web server for the domain name in question, and LE give you a keyfile to put into:

'/.well-known/pki-validation'

For the wildcard certs, you just need to add a TXT record to the public DNS entry, no public web server required.

Even if you have no intention of using your internal DNS domain name on the internet, it's good practice to register it anyway.

Re: ACME v2 and Wildcard Certificate Support is Live

#117

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…

Idea that's been floated before: TOFU plus a distributed network of people automatically sharing what cert fingerprints they encounter. Chances are high that you already hit Facebook on your $device, and if you all of a sudden retrieved a certificate that didn't match the one you had before, or that most other people online hadn't seen, halt and throw up the warnings.

Given the exploitability, laziness, general failure to follow best practices, not to mention misaligned incentives that we're seeing from major CA vendors, having centralized CAs seems like an ever-worsening solution.

Re: ACME v2 and Wildcard Certificate Support is Live

#118
post #100
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…

Yeah, it is an argument you've lost, because it's a bad argument.

Even places like dreamhost give you a letsencrypt cert for free on any domain.

There is no case to be made for not securing your site, on principle or based on what's already happening out in the world, with shady providers injecting code into non-secure HTTP connections.

You see it as "a simple resume site," and I see it as a conduit for malicious providers to inject malicious code. Good on the browser folks for pushing back on you.

Re: ACME v2 and Wildcard Certificate Support is Live

#119
post #17

DNS providers and domain name registration companies are probably going to get pestered about API access for updating TXT DNS records now... :)

Store your DNS records under revision control, and updating your records can be as simple as a "git commit && git push".

https://dns-api.com/

Re: ACME v2 and Wildcard Certificate Support is Live

#120

Can this be used for multi-level subdomains? Like *.subdomain.example.org?

Yes in the literal sense you could have certificates like:

      *.internal.example.com

      *.external.example.com
But no in the sense that you were asking, where you'd want to register certificate for multi-level wildcard:

      *.*.example.com
Post reply on HN