7 ms·

ACME v2 API Endpoint Coming January 2018

58 points by okket 9y ago

yRetsyM 9y ago
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 9y ago
  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 9y ago
    Does anybody know what significant changes were made in this draft, compared to the version that was previously implemented by Let's Encrypt?
diafygi 9y ago
I will update acme-tiny, letsencrypt-nosudo, and gethttpsforfree.com to support ACME v2 when it is released.
- JoshTriplett 9y ago
  Thanks! I use acme-tiny quite successfully for my servers; I found it the easiest way to arrange privilege isolation between the ACME process getting a certificate signed and the server that needs access to the private key.
- pfg 9y ago
  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 9y ago
    Will there be a v2 staging domain like there is for v1?
    - jaas 9y ago
      Yes
atonse 9y ago
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.
circlingthesun 9y ago
Do we get wildcard certs?
- yRetsyM 9y ago
  The spec draft still explicitly denies them: > Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization objects.
  - dc_gregory 9y ago
    Does anyone know why this is exactly?
    - pas 9y ago
      The rationale put forward was that validating wildcards is hard, because public suffixes, etc. (So if the server checks a few subdomains randomly, a quick attacker can register those subdomains at the provider (eg at a site like github), and then get a cert for the whole domain. Of course, a DNS based validation scheme would work flawlessly for wildcards. (Something like put a TXT at the zone apex on the SOA nameserver.) But for some reason LE doesn't want to offer wildcards.
      - Narkov 9y ago
        > So if the server checks a few subdomains randomly Are you suggesting only random checks are completed? Why wouldn't it check all of them? > a quick attacker can register those subdomains at the provider (eg at a site like github), and then get a cert for the whole domain. Why would requesting a wildcard for a subdomain (i.e. pas.github.com) give me a cert that works for the root domain (i.e. github.com)?
        teraflop 9y ago
        > Why wouldn't it check all of them? If I request a certificate for "* .github.com", how do you propose that Let's Encrypt check all of the infinitely-many possible subdomains? > Why would requesting a wildcard for a subdomain (i.e. pas.github.com) give me a cert that works for the root domain (i.e. github.com)? The issue here is that it's only safe to issue a wildcard certificate to someone who already has full control over all of the domains covered by the wildcard, now and in the future. This is impossible to prove using only an HTTP challenge-response. For example, let's say an attacker requests a wildcard certificate for "* .github.io". Hypothetically, LE could say: "OK, to prove that you control all possible subdomains, place a particular nonce at http://e9cd20b9c359939c.github.io/.well-known/acme-challenge." http://e9cd20b9c359939c.github.io/.well-known/acme-challenge... Our attacker quickly registers the username "e9cd20b9c359939c" on Github, satisfies the challenge, and gets a cert that allows them to impersonate other Github users. Alternatively, you could require validation of "github.io" itself, and say that anyone with control over the top-level domain is assumed to be authorized to get wildcard certs as well. But this weakens security for everyone else. For example, Google probably wouldn't be happy if a compromise of their search engine at "google.com" was escalated to a compromise of "accounts.google.com" which handles user sign-in. These aren't fundamentally unsolvable problems, but there are enough edge cases that the ACME folks decided to postpone wildcards until all the details can be carefully figured out. See https://github.com/letsencrypt/acme-spec/pull/97 https://github.com/letsencrypt/acme-spec/pull/97 for some of the messy details.
CaliforniaKarl 9y ago
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.
vbezhenar 9y ago
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 9y ago
  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
- predakanga 9y ago
  Just discovered Lego[0], which is a batteries-included client written in Go, should be an even better option. [0]: https://github.com/xenolf/lego https://github.com/xenolf/lego

58 points by okket 9y ago

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 9y ago
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 9y ago
  Does anybody know what significant changes were made in this draft, compared to the version that was previously implemented by Let's Encrypt?

diafygi 9y ago

I will update acme-tiny, letsencrypt-nosudo, and gethttpsforfree.com to support ACME v2 when it is released.

JoshTriplett 9y ago
Thanks! I use acme-tiny quite successfully for my servers; I found it the easiest way to arrange privilege isolation between the ACME process getting a certificate signed and the server that needs access to the private key.
pfg 9y ago
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 9y ago
  Will there be a v2 staging domain like there is for v1?
  - jaas 9y ago
    Yes

atonse 9y ago

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.

circlingthesun 9y ago

Do we get wildcard certs?

yRetsyM 9y ago
The spec draft still explicitly denies them: > Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization objects.
- dc_gregory 9y ago
  Does anyone know why this is exactly?
  - pas 9y ago
    The rationale put forward was that validating wildcards is hard, because public suffixes, etc. (So if the server checks a few subdomains randomly, a quick attacker can register those subdomains at the provider (eg at a site like github), and then get a cert for the whole domain. Of course, a DNS based validation scheme would work flawlessly for wildcards. (Something like put a TXT at the zone apex on the SOA nameserver.) But for some reason LE doesn't want to offer wildcards.
    - Narkov 9y ago
      > So if the server checks a few subdomains randomly Are you suggesting only random checks are completed? Why wouldn't it check all of them? > a quick attacker can register those subdomains at the provider (eg at a site like github), and then get a cert for the whole domain. Why would requesting a wildcard for a subdomain (i.e. pas.github.com) give me a cert that works for the root domain (i.e. github.com)?
      - teraflop 9y ago
        > Why wouldn't it check all of them? If I request a certificate for "* .github.com", how do you propose that Let's Encrypt check all of the infinitely-many possible subdomains? > Why would requesting a wildcard for a subdomain (i.e. pas.github.com) give me a cert that works for the root domain (i.e. github.com)? The issue here is that it's only safe to issue a wildcard certificate to someone who already has full control over all of the domains covered by the wildcard, now and in the future. This is impossible to prove using only an HTTP challenge-response. For example, let's say an attacker requests a wildcard certificate for "* .github.io". Hypothetically, LE could say: "OK, to prove that you control all possible subdomains, place a particular nonce at http://e9cd20b9c359939c.github.io/.well-known/acme-challenge." http://e9cd20b9c359939c.github.io/.well-known/acme-challenge... Our attacker quickly registers the username "e9cd20b9c359939c" on Github, satisfies the challenge, and gets a cert that allows them to impersonate other Github users. Alternatively, you could require validation of "github.io" itself, and say that anyone with control over the top-level domain is assumed to be authorized to get wildcard certs as well. But this weakens security for everyone else. For example, Google probably wouldn't be happy if a compromise of their search engine at "google.com" was escalated to a compromise of "accounts.google.com" which handles user sign-in. These aren't fundamentally unsolvable problems, but there are enough edge cases that the ACME folks decided to postpone wildcards until all the details can be carefully figured out. See https://github.com/letsencrypt/acme-spec/pull/97 https://github.com/letsencrypt/acme-spec/pull/97 for some of the messy details.

CaliforniaKarl 9y ago

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.

vbezhenar 9y ago

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 9y ago
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
predakanga 9y ago
Just discovered Lego[0], which is a batteries-included client written in Go, should be an even better option. [0]: https://github.com/xenolf/lego https://github.com/xenolf/lego