I'm not sure if I'm just dumb, but I've been looking through Let’s Encrypt, Certbot, acme.sh, and lego code on GitHub. I can't find the URL as to how you can get a response from the Let’s Encrypt server. Is this a URL in the first place? The best guess I have is acme-v02.api.letsencrypt.org but I have no idea
3 Likes
https://acme-v02.api.letsencrypt.org/
or
https://acme-staging-v02.api.letsencrypt.org/
(The second one is down right now for maintenance.)
You can add directory to the end of either to get the ACME endpoints.
4 Likes
We have all of our endpoints listed here:
Are you developing a client? Please read through our client integration guide and other relevant docs:
7 Likes
This is exactly what I needed, thanks!
Thanks
I looked for documentation everywhere and couldn't find it, 
4 Likes
If you're implementing a client, do not assume that you can always append directory. That does not work in general. You should (also) test your client with Pebble, which for example uses the postfix dir instead of directory. In general, the URL provided to your client should include the directory/dir part. That guarantees that it will work with every other ACME server as well (at least until you reach other parts of the ACME protocol where things can behave differently 
).
6 Likes
Interesting. I was not aware of this. Where is one supposed to start if not the directory? How would a client know if it's dir?
4 Likes
@griffin because the user should provide the full URL, and not just the domain name or parts of the URL. That includes the directory part (or dir for Pebble).
For example, for BuyPass, the URL is https://api.buypass.com/acme/directory (a path element before directory), and for ZeroSSL, the URL is https://acme.zerossl.com/v2/DV90 (no directory or dir at all). If you always append directory, it will just not work for ZeroSSL.
6 Likes
I've always just hardcoded the Let's Encrypt staging and production directory URLs into my ACME clients. I suppose they could be specified dynamically, but I haven't looked into the idiosyncrasies of other ACME CAs enough to know if I trust the operation of my ACME clients with them.
3 Likes
I'm thinking - provide a pulldown menu selection; So there are no typos.
4 Likes
I think that, if you decide to support multiple ACME server CAs, you "should" give the user the choice for a certain CA and in the backend hardcode the corresponding ACME directory URIs. Production and staging if applicable. ACME directory URIs aren't supposed to change over time, unless there is some major change such as ACMEv1 -> ACMEv2 for Let's Encrypt.
Of course the user should be able to override the ACME directory URI anyway, but for most users such a technical thing shouldn't be something they should care about, they only care about the choice of CA.
5 Likes
Maybe there should be a default "Get current URI" URL that would never change and always point to the latest path [built into the ACME spec]
[or just redirect to it - LOL]
hmm...
That sounds a lot like a symlink!
4 Likes
This seems like a lot of effort for very little gain. All you're doing is changing what the ACME CA needs to publish from a URI to an FQDN. It still needs to be published and clients will still need to either know in advance or be told what they are for a given CA.
If you want things to be discoverable, I'd push for using DNS SRV records and standardizing on something like _acme._tcp.example.com to lookup the ACME endpoint for a given domain. It would also make it easier to horizontally scale and do DNS load balancing by adjusting priority and weight values.
3 Likes
I very much agree. I don't really see too much of a need.
3 Likes
The gain is standardizing a single URL across all ACME implementations.
Accepting: http://myAMCE.implementati.on/funky/path/to/directory/files
AND having one extra redirection from:
http://myACME.implementati.on/standardized/directory TO: http://myAMCE.implementati.on/funky/path/to/directory/files
Is really not that much of an extra effort.
2 Likes
I, once again, still see little need.
2 Likes
Then you fail to see the benefits of standardization.
It's OK - everyone doesn't have to get it.
Only majority vote is needed to pass something this simple and clearly beneficial.
It's no different than the RFC that requires postmaster@ and webmaster@ domain to accept emails.
Even thought there is hardly ever either account, an alias is generally added to funnel those emails to real mailboxes.
2 Likes
You can have multiple directories under a single hostname by having multiple directory paths. Hardcoding an entry point would mean a certain hostname can only have a single ACME endpoint, which is a regression from the current workflow.
4 Likes
Who benefits from standardization though? Users of most ACME clients don't have to worry about directory URLs because the client author generally embeds some sort of shortcut for common CAs. Client authors only ever have to include those once. And when they or end users go to look up what that is, it's no different to have to find out myacme.implementati.on versus https://myacme.implementati.on/funky/path/dir.
This too.
2 Likes
Standardization should stand the test of time.
It would not matter if the actual URL is ever modified or not.
You would always be redirected to it.
3 Likes
The standard already exists. It's called the directory endpoint as described in section 7.1.1.
In order to help clients configure themselves with the right URLs for each ACME operation, ACME servers provide a directory object. This should be the only URL needed to configure clients.
This is actually one of the nicest parts of RFC8555 in my opinion. A single URL is all that's needed to configure an ACME client. It's no different or more complicated than needing a single FQDN. And I'd argue that requiring only an FQDN with a "well-known" URL format actually makes things worse because it gives ACME CAs less control over how they provide the service.
5 Likes