Sorry if I sounded a bit short.
But if you read between your lines…
You are reasoning that trying to secure your server with an LE cert is somehow requiring you to make it insecure.
We are here to make things more secure not less.
The path at which the resource is provisioned is comprised of the
fixed prefix "/.well-known/acme-challenge/", followed by the "token"
value in the challenge. The value of the resource MUST be the ASCII
representation of the key authorization.
GET /.well-known/acme-challenge/LoqXcYV8...jxAjEuX0
Host: example.org
HTTP/1.1 200 OK
Content-Type: application/octet-stream
LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI
(In the above, "..." indicates that the token and the JWK thumbprint
in the key authorization have been truncated to fit on the page.)
A client responds with an empty object ({}) to acknowledge that the
challenge can be validated by the server.
RFCs, for me, are not instruction manuals nor do they explain things well. Since the 1980's they have done nothing but perplexed me. 
I seen nothing of that resource on the file system.
- It is a mistake to take these forums personel
- It is a mistake to think how a project does something is inherently the best way
- It is a mistake to think I can change policy. I am just implementing it.
I did this all before with openssl and then reimplimented to get two facotr authenecation on the encryption. It all worked until in expired. If I have to do it by hand I will do so. If I have tro do it through DNS, that is also fine. I just need to be pointed to instructions.
I don’t work for LE.
I don’t have anything to do with this project other than donating my time to this forum - to help those that need it.
I’m not asking you to change any policy.
If you read the several ways that I’ve pointed out how you can get a cert, you will see that you can keep within your mandated policies.
Yes, RFCs sometimes don’t seem to be saying anything understandable (in common English to a common person).
The link was to show that, yes, the /.well-known/acme-challenge/ folder is part of the spec.
Not something anyone just made up.
If you walk through the authentication steps maybe you can better understand how you can comply with your policies and still get a cert [while remaining completely safe(@home)].
This is a watered down English version of the process:
- (server) I need a cert for my domain
- (LE) OK, lets negotiate a token (and file name) you can use to prove to me that you really are who you say you are.
- (server/LE) that’s a good token, thanks.
- (LE) Now you must put that token in a file that I can reach via:
http://your.requested.cert.name/.well-known/acme-challenge/negotiated-name
[the name = your cert name]
[the path is ALWAYS/.well-known/acme-challenge/]
[the file name and contents are negotiated to this specific request] - (server) OK, I put the file there; please check it and give me my cert.
- (LE) Just one second, let me confirm that information…
- – different things may happen here –
a. The file is there and BAM! you get your cert.
b. The file is NOT there (404 error) – error, you don’t get your cert.
c. A redirection was used and the file is expected to be elsewhere… LE follows that redirection and repeats this step.
d. Access to the file requires authentication (403 error)! - well that won’t do… LE fails to get file and you don’t get you cert.
e. The domain was unresolvable (NXDOMAIN) - LE returns the error and fails to give you a cert.
f. LE was unable to connect (IPv6 address listed but not actually in use) - LE returns the error and fails to give you a cert.
[this list continues - but you should get the idea]
[there are very few ways to get this to work - you just aren’t providing one]
Thank you very much!
What I meant specifically here is that we are looking for a physical directory ./well-known/acme-challenge/ UNDER /usr/local/apach2/htdocs/ - a physical file? Or is this just a resource generated by the server or the scripts? Because I don't see that anywhere?
And I am looking at this FAQ/HOWTO
https://certbot.eff.org/lets-encrypt/pip-apache
It says :
wildcard *
Close button
Wildcard Certificate
A wildcard certificate is a certificate that covers one or more names starting with *. and that will be accepted by a web browser for any subdomain name with any label in place of the * character. For example, a certificate for *.example.com will be valid for www.example.com, mail.example.com, hello.example.com, or goodbye.example.com, but not for example.com.
From our Certbot Glossary
Follow Docker instructions
To get a wildcard certificate on this system, you'll need to run Certbot in Docker. You can do so by following these steps from our documentation.
Running with Docker
Docker is an amazingly simple and quick way to obtain a certificate. However, this mode of operation is unable to install certificates or configure your webserver, because our installer plugins cannot reach your webserver from inside the Docker container.
Most users should use the operating system packages (see instructions at certbot.eff.org) or, as a fallback, certbot-auto . You should only use Docker if you are sure you know what you are doing and have a good reason to do so.
Running with Docker
What does docker have to do with this?
https://certbot.eff.org/docs/install.html#running-with-docker
Not necessarily. You can change the underlying path to whatever you like.
As with the examples previously provided, you could use any path that can be accessed by the web service.
[I would recommend to create a new and dedicated path]
Note: If you use the document root for the site, then yes, it will append the /.well-known/acme-challenge/ to the file path location to math the requested URL.
BUT...
If you use a location statement, then you are already matching a greater part of the URL to the site-path/.well-known/acme-challenge/ directly. So, in that case no, it would not need /.well-known/acme-challenge/ in the real file path. Just the location path and the filename inside it.
It pretty much speaks for itself.
But to add some clarity...
Docker can be used to "separate" the certbot operation and requirements from the rest of the system.
To me, it seems "easy" only to those that are familiar with Docker.
If that is NOT you, I would ignore that advice and stick with the "simpler" client installs.
Thanks
I can install certificates by hand no problem. I need a domain wide certificate. Docker (as I am sure you know) is a virtualization of a container. I don’t know why you need docker at all to generate a certificate and install it on the system. It leaved me confused.
AH00526: Syntax error on line 358 of /usr/local/apache2/conf/httpd.conf:
DocumentRoot not allowed in context
OK so Apache isn’t quite as… agile as NGINX.
You will have to break that single step into two steps with an equal end result.
Step #1:
- Instead of
DocumentRoot /x/y/z/, redirect to a different local site (a.k.a. vhost config): - redirect / http(s)://some.other.NEW.site.name.you.can.manage/
[i.e. http://challenges.mydomain.com/]
Step #2:
- Create that other “site” that uses only the
DocumentRoot /x/y/z/(replaced in step #1).
[Step #3 restart Apache]
1 Like
OR
[after further reading on Apache]
See: https://httpd.apache.org/docs/2.4/mod/mod_alias.html#alias
You can also use the Alias directive to accomplish the “same” result as location + new DocumentRoot.
Here are their examples:
1 Like
got this, but then what do you use as your webroot option for certbot?
For that “example” use:
--webroot -w /ftp/pub/image/
The request will ALWAYS be to:
http://your.server/.well-known/acme-challenge/{new-file-name}
So the ALIAS within the vhost for “your.server” will redirect those /.well-known/acme-challenge/ requests to /ftp/pub/image/{new-file-name}
[just replace /ftp/pub/image/ with your specific path]
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.