Hi -- in the process of helping a Caddy user, I was just thinking... where should I point them to find the Let's Encrypt directory endpoint?
This one:
https://acme-v02.api.letsencrypt.org/directory
(Of course, I know what the endpoint is.)
I realized that the Staging Environment has its own page, but clicking around a bit I couldn't find the production endpoint.
Anyway, I just wonder if plastering that URL on the Let's Encrypt homepage, Docs page, or even the Getting Started page, would be better than wherever it is now. Apologies if I missed it somewhere obvious.
(I still wouldn't mind it being somewhere a little more obvious for quick reference. But maybe that's just because I'm a nerd and use it frequently, ha.)
Oh, very much agreed. My guess is that it's just buried where it is from back in the days when Let's Encrypt was trying to define ACME and so the URL would only be useful to client developers since of course the client would be defaulting to Let's Encrypt. Now, with ACME catching on in more places, and more clients which default to other CAs, it's the kind of thing that a server administrator might need to specifically configure and so yes should be featured more prominently somehow.
The FAQ would be better, but I still think the best place would be right at the top of either the homepage, the docs index, or the getting started page. I don't think of it as a question I have, I think of it as the one string I need to copy to be on my way. This should be the springboard info on the CA's website.
I do think the full Getting Started text is very helpful for visitors who are new to this, and that's great. But those of us who do this a lot just need to copy+paste that URL. Bonus points if it has a copy button by it!
I think that is far too prominent and presumptive.
The /directory URL is not the first thing people need to know. And, may not need it at all. Many ACME Clients have short-hand methods for specifying this.
What about just changing the title of below page to "ACME Protocol Endpoints" ?
And, even move it up to Subscriber Information instead of Client Dev.
I mean, it really is if you've configured ACME clients before, since this is THE parameter for choosing the CA. But indeed, not everyone will need it. That's why I think a link to getting started will be a good way to point people in the right direction, which you'll find in the mockup.
That'd probably help. I still like my idea though
Let's Encrypt has exactly one interface for using it (not counting the fake one). It's a single URL. Just seems so important to me that it should be highly visible.
If you're busy with configuring an ACME client manually, the user most likely will know how to find the ACME endpoint URI anyway.
While I agree it would be nice to have the current endpoint(s) mentioned somewhere logically, I wouldn't put it at the top, IN YOUR FACE, of a page also/mostly meant for people without any in-depth knowledge of ACME. That's too technical info at the wrong place.
Currently, LE has a single endpoint. This might change in the future (see the thread about multiple certificate profiles), which probably requires an explanation per endpoint and might warrant its own separate page.
ACME CAs have 1 configuration parameter, and that is it. If you want to use Let's Encrypt, you need that URL. I don't think that's too technical for people administering their own websites (usually sysadmins or web developers). They can understand a URL.
In fact, if Let's Encrypt didn't happen to pioneer ACME and have the burden of explaining it, most of Let's Encrypts docs could be boiled down to just the directory endpoint since that is the sole config parameter for using an ACME CA. (Other than EAB, if required, I guess.) I guess I'm saying, the crux of an ACME CA's documentation is their directory endpoint.
The users you're talking about probably aren't going to the Let's Encrypt docs anyway. Or they aren't intending to. What they PROBABLY want is the forums for help, or they the Certbot docs, or the [insert any other ACME client here] docs.
So show both if there's two. I mean, we could probably already do that: "Staging: ... Production: ..." -- not a big deal IMO. And if a separate page is needed at that point, that's fine, but it should still be prominent.
There ya go, the ubiquitous ACME client exposes the directory endpoint parameter. That seems pretty important to me.
There's also the explicitly stated desire to have people use TLS regardless of which CA, so the directory URL isn't that important.
Of course, we nerds know that different CAs, although they all do the same job, are different and can have different features and compatibility, and we'd wanto to choose explicitly.
I'm not sure I understand that. In order to use TLS (via ACME, of course) you need a directory URL. How is it not important? Especially if you want to be able to use multiple CAs, you need all their directory endpoints.
Right, and "most users" won't be browsing the Let's Encrypt docs, they should be browsing their ACME client docs instead. So tailor the LE website for the audience.
It isn't until the user learns there are several different CAs. If you're just starting you should just go with your ACME client defaults, hoping they're sane.
That would be a bit of an issue, with Let's Encrypt being nearly synonymous of acme and free certificates. I worry their trademarks might become genericized.
Exactly, so those users won't be (shouldn't be) in the LE docs in the first place, except maybe for a Getting Started page that turns them right back around and directs them to their ACME client docs. (That's basically what the Getting Started page does already, it directs to Certbot anyway).
I think we're talking about different things? This has nothing to do with the LE trademark.
I'm just saying that I think we need a URL -- a single short string -- more prominently visible on the LE website.
I think the theory being presented here is a vision of a future where more systems are like Caddy, which just have a bunch of CA directory URLs built in, even switching CAs on every certificate if it wants to, and needing to configure specific CAs or fiddling with directory URLs is a really advanced feature, only used if you're trying to integrate EAB for paid certs or something. For most users, they shouldn't need to know, or care, which CAs their web server switches between.