What's the Let's Encrypt URL?

Issuance Tech
21

If I'm understanding all this correctly, we are basically considering two types of potato: :potato:

  1. A stated URL that serves the directory (per the standard now) that could be basically anything
  2. A standardized starting point to "discover" the URL stated in (1)

I feel like the current discovery path is basically "RTFM". Having a standardized discovery path that... wait for it... programmatically exposes the variously available ACME services and their directories, say through an associative array presented via JSON that maps the services to their directories, could serve as a type of standardized "super directory", an index if you will. Granted you'd still need to understand what the indexed services mean, so a blurb could also be included in the JSON.

Did I actually just suggest creating an index page on the internet? :joy: How... novel.

3 Likes
22

In the end both are exactly the same. 2. means that the information that's contained in 1. is pushed into the FQDN, nothing more and nothing less. So instead of modifying the path component of a directory URI, CAs have to add a new subdomain for a new endpoint.

So I don't really see why FQDNs are 'better' than URIs for configuring ACME CA endpoints. Except if people do not like URIs and thinkg FQDNs are better. But end users don't like any of them when configuring their ACME client (or more probably, they use the default configuration), and for everyone else this really shouldn't make any difference.

3 Likes
23

Pardon my confusion here, @felixf, but I really need to get something straight in my brain. (It has been a confusing weekend for me). Can you give me an example of an FQDN and a URI as you're considering them here? I keep thinking of an FQDN as a URI without a protocol, port, or path component. Is that what you're using or... I think this might be my big confusion in this debate.

3 Likes
24

I'm a pretty-path person myself. I find that having to acquire certificates that include "extra" subdomains (or opting to use a wildcard certificate to avoid the hassle) motivates me towards the path route. I'm also all for eliminating the (IMO entirely unnecessary) www subdomain.

2 Likes
25

FQDN: subdomain1.subdomain2.domain.tld
URI: protocol://subdomain1.subdomain2.domain.tld/path?query (usually without ?query)

So whether we have an URI like https://ca.theacmeca.com/acme-01/directory or a FQDN like acme-01.ca.theacmeca.com, in the end the information which endpoint is used is encoded in the path (URI configuration method only), the FQDN (both URI and FQDN configuration method), or both (URI configuration method only).

So why create a new standard when there's already one (configure by URI)?

3 Likes
26

@felixf two times you used FQCN - were those supposed to be FQDN?
[that seems to be strictly a Java related term - which is NOT required by ACME nor HTTP]

3 Likes
27

Thanks for that, Felix. :blush: Now I know I'm on the same page.

I concur. I mean there could be a "standardized index" like I suggested at, say, /acmeindex if we wanted to programmatically provide a list of services and their descriptions to our users in our acme clients rather than hard-coding them. Probably more than most users need or care to consider though.

1 Like
28

Like site maps?

2 Likes
29

Basically, yeah. It would be a directory of directories. Really just a root to tie the directories of the tree together semantically.

2 Likes
30

Yes, sorry, I meant FQDN. (FQCN in this case comes from Ansible: fully qualified collection name. I've apparently typed that too often during the last year :D)

2 Likes
31

So it wouldn't be really a new standard for configuring ACME clients, but for listing ACME CA endpoints. So for configuring an ACME client configurator :wink:

I guess the interesting information per ACME endpoint would be:

  1. the directory URI,
  2. a flag whether it's staging/testing or production,
  3. a flag whether it allows new users to be created freely or not (not meaning EAB is required, or no new registrations are allowed);
  4. an URI for a list of root certificates used (in particular important for staging endpoints);
  5. some human-readable title and description.
4 Likes
32

And, what would also be useful is a protocol version, probably 2 for "RFC 8555" and 1 for "legacy Let's Encrypt ACMEv1 endpoint or compatible" (could be used by Let's Encrypt and BuyPass).

2 Likes
33

You've got it exactly and expanded upon it beautifully! :smiley:

I think RSA vs EC could fall in there somewhere too.

2 Likes
34

I totally support your suggestion in general, but this particular information is already communicated in a different way: in ACMEv1 the directory entries are lowercase and separate by hyphens, while in ACMEv2/RFC 8555 they are camel-case—for example key-change and keyChange. My recollection is that this is intentional in part because it allows clients to make this distinction, and in an explicitly non-backwards-compatible way. (But I'm not sure exactly what ACME will do if the IETF WG eventually wants to create a later non-backwards-compatible version. Still, I'm not sure that the mechanism you suggest is the right way to communicate protocol compatibility information, though I think it's a great idea for all the other kinds of information. The other one that people often want is a way to query rate limits—or, failing that, at least some kind of machine-readable information about rate limit policies.)

6 Likes
35

I looked out of curiosity and Certbot distinguishes them by looking for the newNonce directory entry: Add mechanism to detect acme version by ohemorange · Pull Request #5554 · certbot/certbot · GitHub. It was added in the -09 draft, which is well into v2 territory.

5 Likes
36

Yes, good point. But without some kind of "protocol version identifier", they'll have to rename some existing endpoint (should better be a prominent one like newOrder or newNonce so that clients really notice). Which also wouldn't be great. (Though it would probably be even better if that identifier would be part of the directory itself.)

1 Like
37

So to be clear, ACME clients need to look at the way the capitalization of the directory fields to try to determine the ACME version?

Did someone forget to add a "version" field to the directory or was that left out intentionally?

3 Likes
38

They only need to do that to distinguish between the legacy "ACME v1" API and the RFC 8555 API. So if you don't want to support the legacy APIs, you don't need to do that and can simply complain if you cannot find the RFC 8555 directory entries you are looking for.

But yes, for possible future standardized breaking changes, something like a version identifier would have been nice.

1 Like
39

I was thinking about future versions indeed. :slight_smile:

2 Likes
40

Directories could have references to other directories.

  1. Staging to production and vica versa
  2. Pointers to higher version ACME protocol implementation of the same CA
  3. URIs to directories of other CA's implementation
2 Likes