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

251–260 of 321 posts

Re: ACME v2 and Wildcard Certificate Support is Live

#251

Post by NKCSS »

cm2187 wrote: post #216
NKCSS wrote: post #144

I just wished there was a Windows client that just works with IIS. Every time I try, it just errors out and gives me headaches (certify, Let's Encrypt Simple Windows Client, etc.)

If you are using wildcard it doesn't need to be integrated with IIS. Use acmesharp which has a nice powershell interface (doesn't support wildcards yet). Then loading the certificate in the certificate store and assigning it to a website should be fairly easy in powershell.

Nah, I use a lot of SAN certificates; e.g. when a customer has 10 domains, and you want all of them to redirect to one, you have 1 site with just an SSL binding, and 1 site with all other domains and the non-SSL binding. That's a scenario that f's up a lot.

Re: ACME v2 and Wildcard Certificate Support is Live

#252

Post by alwillis »

peterwwillis wrote: post #210
schoen wrote: post #204

Earlier quoted context omitted.

Just a TXT record. https://tools.ietf.org/html/draft-ietf-acme-acme-03#section-...

Wow. A lot of sites are going to get owned.

>Wow. A lot of sites are going to get owned.

Why would you say such a thing?

Tens of millions of certificates have been provisioned using the ACME protocol without issue.

There’s a lot of cryptography behind the scenes that leads up to the TXT record being generated. You can read all about it at https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-...

Re: ACME v2 and Wildcard Certificate Support is Live

#253

Post by alwillis »

peterwwillis wrote: post #219
schoen wrote: post #218

Earlier quoted context omitted.

We've been using TXT records to authenticate certificate requests since Let's Encrypt launched. That hasn't changed.

Without verifying who controls the IP space? If you don't verify who controls the IP space, then if you can control the DNS, you can generate certs. Certs that appear valid to unsuspecting users. Putting that kind of trust in DNS is pretty crazy considering how insecure most DNS setups are. Not to mention general attacks on DNS. There's even a potential chicken and egg problem, if you need DNS to secure your HTTPS, b…

https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-...

DNS security

As noted above, DNS forgery attacks against the ACME server can result in the server making incorrect decisions about domain control and thus mis-issuing certificates. Servers SHOULD perform DNS queries over TCP, which provides better resistance to some forgery attacks than DNS over UDP.

An ACME-based CA will often need to make DNS queries, e.g., to validate control of DNS names. Because the security of such validations ultimately depends on the authenticity of DNS data, every possible precaution should be taken to secure DNS queries done by the CA. It is therefore RECOMMENDED that ACME-based CAs make all DNS queries via DNSSEC-validating stub or recursive resolvers. This provides additional protection to domains which choose to make use of DNSSEC.

An ACME-based CA must use only a resolver if it trusts the resolver and every component of the network route by which it is accessed. It is therefore RECOMMENDED that ACME-based CAs operate their own DNSSEC-validating resolvers within their trusted network and use these resolvers both for both CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.).

Re: ACME v2 and Wildcard Certificate Support is Live

#254

Post by zaarn »

nothrabannosir wrote: post #183
irq-1 wrote: post #178

Earlier quoted context omitted.

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.

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

Re: ACME v2 and Wildcard Certificate Support is Live

#255

Post by zaarn »

vertex-four wrote: post #85
blattimwind wrote: post #22

Earlier quoted context omitted.

I never understood why DNS providers are so reluctant to offer standards-based access, like nsupdate(1). It's easy to set up, it can do everything, it's secure, requires no custom anything and it just works.

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

Re: ACME v2 and Wildcard Certificate Support is Live

#256

Post by kureikain »

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

acme.sh is great because it support manual DNS mode. It also way easier to use compare with other similar client. This is all it takes for me.

./acme.sh --issue -d noty.im -d '.noty.im' --dns

It then told me to add TXT record, which I just manually do because I used RackSpace cloudns which has no built-in support.

I manually verify DNS with dig, when it's ready I just do:

./acme.sh --renew -d noty.im -d '.noty.im'

then the cert(private key and full chain) are stored in ~/.acme/noty.im/

These privateky and fullchain can be used directly with nginx without any modification.

Re: ACME v2 and Wildcard Certificate Support is Live

#257

Post by kureikain »

b3lvedere wrote: post #186
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 (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.

Re: ACME v2 and Wildcard Certificate Support is Live

#258

Post by kbuck »

komuW wrote: post #152

Shameless plug, I created sewer[1], which is a letsencrypt client that you can use both as a (minimalistic) python library or as a command line application. And I just added ACME v2 support. Check it out, 1. https://github.com/komuw/sewer

Thanks for this; I've been searching for something similar for a while now. I'll look forward to trying it!

Re: ACME v2 and Wildcard Certificate Support is Live

#259

Post by mbaha »

jack_jennings wrote: post #39

Now here's to hoping that Heroku supports this soon. That will to mean I can a last migrate a number of apps that require wildcard domains to their platform.

I have a feeling they've been working on this. Their https support has always been top notch!

Re: ACME v2 and Wildcard Certificate Support is Live

#260

Post by rkistner »

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…

They already disabled TLS-SNI-01 for new certificates because of security issues [1].

This was a major breaking change, without any advance notice, but nothing melted down.

I'm sure the other validation endpoints are used a lot more, but the effect shouldn't be any different, especially if give a deprecation notice of a year or two.

[1]: https://community.letsencrypt.org/t/important-what-you-need-...

Post reply on HN