Thrilled that this is coming—will make my life a hell of a lot easier, especially for certs for non-web stuff (xmpp server, postfix and dovecot, etc). Bravo!
yes please !
Will we be able to “stack” wildcard domains? E.g. I have three domains (example1.org, example1.com, example1.net), will I be able to issue single certificate for *.example1.org, *.example1.com and *.example1.net?
The blog post says, “We will initially only support base domain validation via DNS for wildcard certificates” - does this mean that certificates for *.domain.com will be ok but *.api.domain.com will not? thanks
I think the intention of that sentence was that only the DNS challenge method will be allowed, not HTTP or TLS-SNI challenge methods. But I haven’t checked this with anyone responsible for the implementation.
This is great news for us. Will you allow longer than 90 days expiration for these? One of our use cases is on internal servers that can’t do the automated issuance (at least, I don’t think they can… it’s been a while since I’ve looked at the progress).
To put a number on it, a 6-month expiration term would be acceptable, but I’d grumble a little. A 1-year expiration would be ideal.
This is the correct interpretation of the blog post
There’s no plan to change certificate validity period at this point.
I rather see this reduced to 30 days than increased.
that’s the all idea behind automation
Have you looked into DNS01?
Thanks for the tip. We’re a Windows shop, so for any other n00bs like me reading this, I’m going to start with this blog post and see what I can set up on a development server. Also, it seems the proper search term on this is “DNS-01”.
Wildcard domain names (with “*” as the first label) MUST NOT be included in authorization objects
and there’s nothing in particular in the
dns-01 section explaining how to answer a DNS challenge for a wildcard domain.
many LE client implementations only call it DNS01 without the dash
I would love to see multi-level domain wildcard support - so
*.sub.domain.tld as well as
*.domain.tld. I have a scenario where I have customer labels on a regional subdomain like
customer-label.eu1.myservice.com which would be well served by this feature inclusion.
In ACME, an authorization is always meant to correspond to a specific domain name that can be validated. In ACME v2, you submit a CSR, and then the CA decides based on policy which authorizations you will need to satisfy in order to issue the certificate you requested. Per the blog post, Let’s Encrypt will be doing DNS-based validation of the base domain (e.g.
*.example.com. So if the CSR has wildcard DNS names in it, Let’s Encrypt will create a set of authorizations for the corresponding base domains, where the only available challenge method is DNS-01.
Per RFC 2818, you can’t combine those both into one certificate. But you should be able to do it using two separate certificates.
Could you cite a specific part of RFC 2818? I think this is inaccurate.
Ah, I see. So we are moving from “ability to set TXT on _acme-challenge.foo.example.org means I control foo.example.org” to “ability to set TXT on _acme-challenge.foo.example.org means I control *.foo.example.org”? Seems mildly scary but basically reasonable.
BTW, am I correct that the link I cited is the ACME v2 spec? It doesn’t actually use that name anywhere and I couldn’t easily find any spec that uses that name.
Yep, although I prefer the more readably-formatted version based on the current master branch in git: https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html.
Regarding v2 nomenclature, we’re using that to distinguish between “the early draft of ACME Let’s Encrypt and most clients currently implemented” vs “the final RFC version of ACME that Let’s Encrypt will implement.” It’s a little more straightforward that citing specific draft numbers. See our post about it: https://letsencrypt.org/2017/06/14/acme-v2-api.html