
ACME v2 API Endpoint Coming January 2018 - okket
https://letsencrypt.org/2017/06/14/acme-v2-api.html
======
diafygi
I will update acme-tiny, letsencrypt-nosudo, and gethttpsforfree.com to
support ACME v2 when it is released.

~~~
pfg
Thanks for your (past and future) work on those clients!

In case you haven't seen it yet, Let's Encrypt is working on a testing-only
server implementation called pebble[1] that's based on the latest ACME draft.
Might come in handy if you want to start working on this before the production
ACME server (boulder) is ready.

[1]:
[https://github.com/letsencrypt/pebble](https://github.com/letsencrypt/pebble)

~~~
diafygi
Will there be a v2 staging domain like there is for v1?

~~~
jaas
Yes

------
yRetsyM
The blog post was a little vague on what the changes are to the standard.

Found the repo were development is being managed: [https://github.com/ietf-wg-
acme/acme](https://github.com/ietf-wg-acme/acme)

~~~
claar
Agreed -- the actual draft appears to be at
[https://tools.ietf.org/html/draft-ietf-acme-
acme-06](https://tools.ietf.org/html/draft-ietf-acme-acme-06)

~~~
teraflop
Does anybody know what significant changes were made in this draft, compared
to the version that was previously implemented by Let's Encrypt?

------
vbezhenar
Is there some tiny ACME client implementation with DNS validation and CSR
support? Basically: I don't want to make my private keys accessible for acme
software and I don't want to rotate them, so I want to generate CSR once and
re-use them to generate new certificates. So far I didn't like other
implementations, probably will make my own, but may be I missed something.

~~~
predakanga
It sounds like Dehydrated[0] suits your usecase - it's meant to be truly tiny
so it doesn't bundle DNS validation; that's generally handled by the DNS Tool
Lexicon[1], which includes an example config for use with Dehydrated.

0: [https://dehydrated.de/](https://dehydrated.de/) 1:
[https://github.com/AnalogJ/lexicon](https://github.com/AnalogJ/lexicon)

------
circlingthesun
Do we get wildcard certs?

~~~
yRetsyM
The spec draft still explicitly denies them:

> Wildcard domain names (with "*" as the first label) MUST NOT be included in
> authorization objects.

~~~
dc_gregory
Does anyone know why this is exactly?

~~~
pfg
This is not intended to prohibit wildcard issuance. It just makes clear that
identifiers in authorizations (and therefor challenges) are always actual
FQDNs. You may still submit CSRs that include wildcard identifiers, and
whether they're issued, which identifiers will have to be validated and what
challenge type is required is up to CA policy. This is mentioned in section
10.5 of the spec[1].

To me, Let's Encrypt not supporting wildcards seems mostly like a policy
decision where they're choosing not to support some use-cases in exchange for
a security win: Not having the compromise of one domain affect certificate
issuance for all of its subdomains, less overall complexity and preventing
users from getting into the habit of using one wildcard certificate with the
same key across multiple services.

[1]: [https://ietf-wg-acme.github.io/acme/#rfc.section.10.5](https://ietf-wg-
acme.github.io/acme/#rfc.section.10.5)

~~~
throwaway2048
Also ensuring a market for premium certificates, lets not forget that one
bullet point.

------
CaliforniaKarl
Props for collaborating to make ACME v2 an actual Internet Standard.

So many of the things we use today use custom APIs that can change on a whim.
That makes me sad.

------
atonse
This would be great especially for paid alternate CAs, so we can automate
renewals, etc easily.

You could also bring functionality similar to Caddy, for other CAs.

