# uname -a
FreeBSD peets 11.0-RELEASE-p9 FreeBSD 11.0-RELEASE-p9 #0: Tue Apr 11
08:48:40 UTC 2017 root@amd64-
builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
Domain is lazygranch.site, basically a place holder to get the server working, then I will use lazygranch.com and another domain.
Relevant portion of nginx.conf
server {
listen 80;
server_name lazygranch.site;
#charset koi8-r;
#access_log logs/host.access.log main;
# # Letsencrypt needs http for acme challenges
location ^~ /.well-known/acme-challenge/ {
proxy_redirect off;
default_type "text/plain";
# root /usr/local/www/.well-known/acme-challenge ;
root /usr/local/www/ ;
allow all;
}
I verified that www.lazygranch.site/.well-known/acme-challenge is “reachable” by placing a file called test.txt there with the word “howdy” in it.
http://www.lazygranch.site/.well-known/acme-challenge/test.txt
returns “howdy!”
Initiating the certificate process:
# sh /usr/local/etc/periodic/weekly/000.acme-client.sh
acme-client: /usr/local/etc/acme/mydomain.site/privkey.pem: account key exists
(not creating)
acme-client: /usr/local/etc/ssl/acme/private/mydomain.site/privkey.pem: domain
key exists (not creating)
acme-client: adding SAN: www.mydomain.site
acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
acme-client: acme-v01.api.letsencrypt.org: DNS: 104.92.124.56
acme-client: acme-v01.api.letsencrypt.org: DNS: 2600:1406:1a:393::3d5
acme-client: acme-v01.api.letsencrypt.org: DNS: 2600:1406:1a:389::3d5
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: req-auth:
mydomain.site
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: req-auth:
www.mydomain.site
acme-client: /usr/local/www/acme/hash1: created
acme-client: https://acme-
v01.api.letsencrypt.org/acme/challenge/hash2/1319938077: challenge
acme-client: /usr/local/www/acme/hash3: created
acme-client: https://acme-
v01.api.letsencrypt.org/acme/challenge/hash4/1319938089: challenge
acme-client: https://acme-
v01.api.letsencrypt.org/acme/challenge/hash2/1319938077: status
acme-client: https://acme-
v01.api.letsencrypt.org/acme/challenge/hash2/1319938077: bad response
acme-client: transfer buffer: [{ "type": "http-01", "status": "invalid", "error": {
"type": "urn:acme:error:unauthorized", "detail": "Invalid response from
http://mydomain.site/.well-known/acme-challenge/hash1:
\"\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e404 Not
Found\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody
bgcolor=\"white\"\u003e\r\n\u003ccenter\u003e\u003ch1\u003e404 Not Found\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003e\"", "status": 403 }, "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/hash2/1319938077", "token": "hash1", "keyAuthorization": "hash1.hash5", "validationRecord": [ { "url": "http://mydomain.site/.well-known/acme-challenge/hash1", "hostname": "mydomain.site", "port": "80", "addressesResolved": [ "myip" ], "addressUsed": "myip", "addressesTried": [] } ] }] (1147 bytes)
acme-client: bad exit: netproc(62023): 1
I had sanitized the above text not knowing that the domain name should be shown. Also I have no idea what “hash” can be safely shown, so I replaced long coded with hash1, hash2, etc.
From the nginx access.log file:
66.133.109.36 - - [11/Jun/2017:19:38:53 +0000] "GET /.well-known/acme-challenge/hash1 HTTP/1.1" 404 169 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
66.133.109.36 - - [11/Jun/2017:19:38:53 +0000] "GET /.well-known/acme-challenge/hash3 HTTP/1.1" 404 169 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
File permissions:
# pwd
/usr/local/www
# ls -l
total 24
drwxr-xr-x 3 root wheel 512 Jun 10 00:19 .well-known
drwxr-xr-x 2 root www 512 Jun 11 19:38 acme
Directories /usr/local/www/.well-known/ and root /usr/local/www/.well-known/acme-challenge are empty.
In the future, can the long hash codes be safely uploaded?
(The test file returns “greetings” instead of "howdy.)