Let's Encrypt can't access verification files (Nginx)


Letsencrypt client seems to not be able to see my verification files. I create them using the provided printf command, and using the right path that points to my web server root (/var/www/letsencrypt/).

Nginx conf file :

# Let's Encrypt ACME Domain Ownership Verification
location /.well-known/acme-challenge/ { root /var/www/letsencrypt/; try_files $uri =404; }

Based on this topic, I tried to do the same thing for nginx by adding this to the block

default_type text/plain; charset off;

I got :
INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection (1): example.com
WARNING:letsencrypt.plugins.manual:Self-verify of challenge failed.

Note that I can curl these files or access it in the web browser.
I tried the official client and acme-tiny, the error is the same on both of these clients.

What’s wrong with this?

Hello @sedna,

If you provide your real domain we could help you to test it, also what is the exact command you are using?.

Anyway, keep in mind that you should be able to access to http://yourdomain/.well-known/acme-challenge/heretherandomchallenge from the machine where you are executing the letsencrypt-auto command and from internet.

Check it creating a dummy test file:

echo -n "This is a challenge test" > /var/www/letsencrypt/.well-known/acme-challenge/dummy

And now try to get that file from the same machine where you are executing the letsencrypt-auto command and from an external site.

curl -i http://yourdomain/.well-known/acme-challenge/dummy

Good luck,

Hello @sahsanu,

I prefer to not provide the domain name since i’m not really sure about the overall security of the server. However, if you think it would really help, I will provide it.

I did this :

CSR generation
openssl req -new -sha256 -key example.com.key.pem -nodes -out example.com.csr -outform der -config my_openssl.cnf
Ownership verification
letsencrypt certonly --test-cert --authenticator manual --text --csr example.com.csr --register-unsafely-without-email

I didn’t do any previous letsencrypt-auto command, since the only command available in the Archlinux letsencrypt package is letsencrypt.

dummy file :
$ echo -n "Testing ACME" > /var/www/letsencrypt/.well-known/acme-challenge/test.txt
$ curl -i
HTTP/1.1 200 OK
Server: nginx/1.8.1
Date: Sun, 10 Apr 2016 16:55:42 GMT
Content-Type: text/plain
Content-Length: 13
Last-Modified: Thu, 07 Apr 2016 20:05:31 GMT
Connection: keep-alive
ETag: "5706bd8b-d"
Accept-Ranges: bytes

Testing ACME

It’s accessible from the server, the server’s local network, and outside (I checked through a remote proxy connection and through my GSM connection, I even asked to a friend if he could see the file and he sees it).

As said previously, I use the printf command :
printf "%s" verification_file_content > /var/www/letsencrypt/.well-known/acme-challenge/verification_file

Is there some rules to add to the firewall ? I just allow incoming HTTP and HTTPS.

Hello @sedna,

It is ok, if you already checked that you can access to challenge file from the machine you are executing letsencrypt and from internet it is fine. Anyway, if you want you can send me a private message with your domain and I'll check it... but I'm leaving now so I could check it a few hours or tomorrow.

Did you include in your my_openssl.cnf file the SANs?

You need to include your domain(s) using SAN.

Example in one line to include the domains yourdomain.tld and www.yourdomain.tld (note: the private key should exist before create the csr)

openssl req -new -nodes -sha256 -key yourkey.pem -out yourcsr.der -outform der -subj "/CN=yourdomain.tld" -reqexts SAN -config <(echo -e "[req]\ndistinguished_name=yourdomain.tld\n[yourdomain.tld]\n[SAN]\nsubjectAltName=DNS:yourdomain.tld,DNS:www.yourdomain.tld")

If you want to create the key at the same time:

openssl req -sha256 -nodes -new -newkey 4096 -keyout yournewkey.pem -out yourcsr.der -outform der -subj "/CN=yourdomain.tld" -reqexts SAN -config <(echo -e "[req]\ndistinguished_name=yourdomain.tld\n[yourdomain.tld]\n[SAN]\nsubjectAltName=DNS:yourdomain.tld,DNS:www.yourdomain.tld")

So, create again your csr with your domain(s) included in SAN and try again.

Good luck,

$ openssl req -new -sha256 -key example.com.key.pem -nodes -out example.com.csr -outform der -reqexts SAN -config my_openssl.cnf

Error Loading request extension section SAN
139735176423064:error:22097082:X509 V3 routines:DO_EXT_NCONF:unknown extension name:v3_conf.c:125:
139735176423064:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:v3_conf.c:95:name=countryName, value=Country Name (2 letter code)

my “my_openssl.cnf” template

[req] distinguished_name=example.com

[example.com] [SAN] subjectAltName=DNS:example.com,DNS:www.example.com countryName=Country Name (2 letter code) countryName_default=FR commonName=Name of the website commonName_default=My Website

I don’t see any difference with the inline one you provided me.

Hello @sedna,

You should remove countryName and commonName directives from your my_openssl.cnf.



also you need to include the subject in openssl command -subj "/CN=example.com"

openssl req -new -sha256 -key example.com.key.pem -nodes -out example.com.csr -outform der -subj "/CN=example.com" -reqexts SAN -config my_openssl.cnf


Letsencrypt still saying me that it doesn’t find the file :cry:
I PM you the domain name so that you can check when you have time.

EDIT : How do you PM someone on Discourse ? é_è

If you click on @sahsanu name ( or logo ) above, it should show a pop-up. on the right of that pop-up is a box “message”. Just use that.

1 Like

Am I stupid or … ? I dont see anything.

Your are not allowed to send messages yet, I’ve sent a message to you.

I did the latest command @sahsanu, but I can no longer reply, Discourse is trolling me…

“You have reached the reply limit for this topic
We’re sorry, but new users are temporarily limited to 3 replies in the same topic.
Instead of adding another reply, please consider editing your previous replies, or visiting other topics.”

I’ve changed your trust level, you should be able to post and reply more often now. Sorry about that!

1 Like

Just for the records.

The error @sedna get when trying to issue the cert for his domain in manual mode was WARNING:letsencrypt.plugins.manual:Self-verify of challenge failed. This is not a real error, is just a warning saying that the client can’t verify the challenge but doesn’t mean that letsencrypt boulder can’t verify the challenge, just the client.

If your shell supports colours, this warning is shown with a beautiful red colour :stuck_out_tongue: which is confusing because seems that it failed to issue your cert but if you continue reading the command output you get a Congratulations message which means that you finally get your cert from letsencrypt.

In this case, the challenge verifycation error from letsencrypt client was because @sedna was trying to run the command from its internal network and its domain pointed to the public ip which is forwarded from internet to an internal machine. The router used by @sedna can’t forward requests from internal network to external ip so it never reached the internal web server. To solve the issue, the simplest solution is to add in /etc/hosts file a new entry to resolve the domain to the private ip instead of the public ip. For example, if the web server is located on and the domain is superdomain.tld just add this to /etc/hosts file. www.superdomain.tld superdomain.tld

Once added, the letsencrypt client can resolve the domain to internal ip and can reach the web server to verify the challenge and letsencrypt boulder can verify the challenge because the router is forwarding the requests from internet to the right internal web server.

That’s all :wink:


1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.