# What's the Let's Encrypt URL? **URL:** \ **Category:** Issuance Tech\ **Created:** [February 5, 2021, 1:54am UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562 "2021-02-05T01:54:22Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Litbelb](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/litbelb/32/46707_2.png) [@Litbelb](https://community.letsencrypt.org/u/Litbelb)\ **Post date:** [February 5, 2021, 1:54am UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/1 "2021-02-05T01:54:22Z")
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 ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [February 5, 2021, 1:58am UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/2 "2021-02-05T01:58:11Z")
[https://acme-v02.api.letsencrypt.org/](https://acme-v02.api.letsencrypt.org/) or [https://acme-staging-v02.api.letsencrypt.org/](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. ---
**Author:** ![jillian](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jillian/32/11635_2.png) [@jillian](https://community.letsencrypt.org/u/jillian)\ **Post date:** [February 5, 2021, 2:06am UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/3 "2021-02-05T02:06:26Z")
We have all of our endpoints listed here: > **[ACME Protocol Updates - Let's Encrypt - Free SSL/TLS Certificates](https://letsencrypt.org/docs/acme-protocol-updates/#api-endpoints)** > > Last updated: Oct 7, 2019 | See all Documentation The IETF-standardized ACME protocol, RFC 8555, is the cornerstone of how Let’s Encrypt works. > API Endpoints We currently have the following API endpoints. Please see our divergences... Are you developing a client? Please read through our client integration guide and other relevant docs: > **[Integration Guide - Let's Encrypt - Free SSL/TLS Certificates](https://letsencrypt.org/docs/integration-guide/)** > > Last updated: Aug 8, 2016 | See all Documentation This document contains helpful advice if you are a hosting provider or large website integrating Let’s Encrypt, or you are writing client software for Let’s Encrypt. > Plan for Change Both... > **[Documentation - Let's Encrypt - Free SSL/TLS Certificates](https://letsencrypt.org/docs/)** > > Let's Encrypt is a free, automated, and open certificate authority brought to you by the nonprofit Internet Security Research Group (ISRG). ---
**Author:** ![Litbelb](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/litbelb/32/46707_2.png) [@Litbelb](https://community.letsencrypt.org/u/Litbelb)\ **Post date:** [February 5, 2021, 2:12am UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/4 "2021-02-05T02:12:07Z")
> [@jillian](#): > > Are you developing a client? Please read through our client integration guide and other relevant docs: This is exactly what I needed, thanks! > [@griffin](#): > > You can add `directory` to the end of either to get the ACME endpoints. Thanks I looked for documentation everywhere and couldn't find it, 😁 ---
**Author:** ![felixf](https://avatars.discourse-cdn.com/v4/letter/f/fbc32d/32.png) [@felixf](https://community.letsencrypt.org/u/felixf)\ **Post date:** [February 5, 2021, 5:16am UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/5 "2021-02-05T05:16:42Z")
> [@Litbelb](#): > > > [@griffin](#): > > > > You can add `directory` to the end of either to get the ACME endpoints. > > Thanks > > I looked for documentation everywhere and couldn't find it, 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](https://github.com/letsencrypt/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 😉 ). ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [February 5, 2021, 5:51am UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/6 "2021-02-05T05:51:35Z")
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`? ---
**Author:** ![felixf](https://avatars.discourse-cdn.com/v4/letter/f/fbc32d/32.png) [@felixf](https://community.letsencrypt.org/u/felixf)\ **Post date:** [February 5, 2021, 6:08am UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/7 "2021-02-05T06:08:01Z")
@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. ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [February 5, 2021, 6:21am UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/8 "2021-02-05T06:21:12Z")
> [@felixf](#): > > the user should provide the full URL 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. ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [February 6, 2021, 12:24am UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/9 "2021-02-06T00:24:43Z")
> [@griffin](#): > > I suppose they could be specified dynamically I'm thinking - provide a ~~pulldown~~ menu selection; So there are no typos. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [February 6, 2021, 8:27am UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/10 "2021-02-06T08:27:27Z")
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. ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [February 6, 2021, 5:20pm UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/11 "2021-02-06T17:20:00Z")
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! ---
**Author:** ![rmbolger](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rmbolger/32/27474_2.png) [@rmbolger](https://community.letsencrypt.org/u/rmbolger)\ **Post date:** [February 6, 2021, 10:18pm UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/12 "2021-02-06T22:18:51Z")
> [@rg305](#): > > 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] 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. ---
**Author:** ![Litbelb](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/litbelb/32/46707_2.png) [@Litbelb](https://community.letsencrypt.org/u/Litbelb)\ **Post date:** [February 6, 2021, 10:20pm UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/13 "2021-02-06T22:20:21Z")
> [@rmbolger](#): > > This seems like a lot of effort for very little gain I very much agree. I don't really see too much of a need. ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [February 6, 2021, 10:52pm UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/14 "2021-02-06T22:52:12Z")
> [@rmbolger](#): > > This seems like a lot of effort for very little gain. The gain is standardizing a single URL across all ACME implementations. Accepting: [http://myAMCE.implementati.on/funky/path/to/directory/files](http://myAMCE.implementati.on/funky/path/to/directory/files) AND having one extra redirection from: [http://myACME.implementati.on/standardized/directory](http://myACME.implementati.on/standardized/directory) TO: [http://myAMCE.implementati.on/funky/path/to/directory/files](http://myAMCE.implementati.on/funky/path/to/directory/files) Is really not that much of an extra effort. ---
**Author:** ![Litbelb](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/litbelb/32/46707_2.png) [@Litbelb](https://community.letsencrypt.org/u/Litbelb)\ **Post date:** [February 6, 2021, 10:56pm UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/15 "2021-02-06T22:56:04Z")
> [@rg305](#): > > The gain is standardizing a single URL across all ACME implementations. I, once again, still see little need. ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [February 6, 2021, 10:58pm UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/16 "2021-02-06T22:58:07Z")
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. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [February 6, 2021, 11:09pm UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/17 "2021-02-06T23:09:02Z")
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. ---
**Author:** ![rmbolger](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rmbolger/32/27474_2.png) [@rmbolger](https://community.letsencrypt.org/u/rmbolger)\ **Post date:** [February 7, 2021, 12:40am UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/18 "2021-02-07T00:40:04Z")
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`. > [@Osiris](#): > > Hardcoding an entry point would mean a certain hostname can only have a single ACME endpoint This too. ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [February 7, 2021, 2:52am UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/19 "2021-02-07T02:52:50Z")
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. ---
**Author:** ![rmbolger](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rmbolger/32/27474_2.png) [@rmbolger](https://community.letsencrypt.org/u/rmbolger)\ **Post date:** [February 7, 2021, 3:16am UTC](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562/20 "2021-02-07T03:16:23Z")
The standard already exists. It's called the directory endpoint as described in [section 7.1.1](https://tools.ietf.org/html/rfc8555#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. [Next page](https://community.letsencrypt.org/t/whats-the-lets-encrypt-url/144562.md?page=2)