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/).
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.
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.
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.
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.
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")
$ 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.
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.”
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 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 192.168.1.100 and the domain is superdomain.tld just add this to /etc/hosts file.
192.168.1.100 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.
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.