First of all thank you for your help.
The thing is that I'm having problems applying certbot to my site configured in nginx, I'm not an expert on the subject so I've been guided by a tutorial. Anyway, here are my settings:
clarify that the domain points to the IP and the site is accessible from the internet through port 80
/etc/nginx/conf.d/lexapp.es.conf
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/html;
server_name lexapp.es;
}
The command I try :
sudo certbot --nginx -d lexapp.es
The results I get :
Plugins selected: Authenticator nginx, Installer nginx
Requesting a certificate for lexapp.es
Performing the following challenges:
http-01 challenge for lexapp.es
Waiting for verification...
Challenge failed for domain lexapp.es
http-01 challenge for lexapp.es
Cleaning up challenges
Some challenges have failed.
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: lexapp.es
Type: unauthorized
Detail: 2a02:4780:1:753:0:3313:4df6:5: Invalid response from
http://lexapp.es/.well-known/acme-
challenge/ebE6_4SJ0B0yOIzWDyoIdWP0q0fZTldwteCaiORiBNo:
404
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
I would appreciate any help
We have setup a nginx server with the following configuration but when trying to access the domain it is giving the . Nginx is installed on debian 10 machine
Error 404: Not found :-(
THe web server is not configured to handle this request. Are you sure you typed in the correct URL?. If yes, please contact the admin.
Following is the configuration of the nginx file
server {
listen 80;
server_name domain_name ;
root /var/www;
}
Permissions for /var/www is set correctly. Still not able to acecss the domain name . Please help here
how do i generate https for wildcard?
server {
server_name subdomain.domain.com www.subdomain.domain.com *.subdomain.domain.com ~^(.*)\.subdomain\.domain\.com$;
}
currently, for normal domains I generate certificates like this:
sudo certbot --nginx -d example.com
For wildcard just add another entry with *
sudo certbot --nginx -d *.example.com -d example.com
You can further refer here Let's Encrypt: Wildcard Certificate With Certbot
I used following to generate wildcard certificate and it worked like charm. Here we are doing dns challenge hence you should have access to your dns to make entries that will be read while create certificate.
sudo certbot certonly --manual -d *.example.com -d example.com \
--email admin#example.com --agree-tos \
--preferred-challenges dns-01 \
--server https://acme-v02.api.letsencrypt.org/directory
Hope this information will help you
with your command you are issuing a Certificate via HTTP-Challenge. Let's Encrypt doesn't support issuing Wildcard-Certificates via HTTP-Challenge.
Here is a link about challenge types supported by Let's Encrypt:
https://letsencrypt.org/docs/challenge-types/
For Wildcard-certs you need to issue the Certs via DNS-Challenge. Therefore you need API-Access to your hosting provider or dynamic dns provider. Certbot offeres some Plugins for some of them, here is a link to the Certbot-DNS-Plugins-Site: https://certbot.eff.org/docs/using.html#dns-plugins
If your provider isn't listed you can't issue Wildcard-Certs with Certbot. There are some other tools which supports DNS-Challenges for Let's Encrypt like acme.sh, here is a link to the Github-Repository: https://github.com/acmesh-official/acme.sh
I hope I could help you with this information.
Bananenkönig
On the server, Nginx is installed.
Let's Encrypt is working well with www.domain.com but is not working with static.domain.com
With PuTTY, when I enter :
sudo letsencrypt certonly -a webroot --webroot-path=/var/www/site/domain -d static.domain.com -d domain.com -d www.domain.com
I have the below issue :
Failed authorization procedure. static.domain.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://static.domain.com/.well-known/acme-challenge/c6zngeBwPq42KLXT2ovW-bVPOQ0OHuJ7Fw_FbfL8XfY: "<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>"
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: static.domain.com
Type: unauthorized
Detail: Invalid response from
http://static.domain.com/.well-known/acme-challenge/c6zngeBwPq42KLXT2ovW-bVPOQ0OHuJ7Fw_FbfL8XfY:
"<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>"
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address.
Somebody know what can be the issue?
I got an identical error message from certbot when I tried to install a certificate for the first time on my website.
Check the cause on the web server
I was using apache2, not nginx. I looked at the logs in /var/log/apache2/error.log for apache2 error messages associated with that 403 Forbidden event on my website and I found :
[Sun Aug 26 14:16:24.239964 2018] [core:error] [pid 12345] (13)Permission denied: [client 12.34.56.78:1234] AH00035: access to /.well-known/acme-challenge/5PShRrf3tR3wmaDw1LOKXhDOt9QwyX3EVZ13JklRJHs denied (filesystem path '/var/lib/letsencrypt/http_challenges') because search permissions are missing on a component of the path
Permissions and access problem
I googled this error message and found out that apache2 can't read the directory mentionned above (e.g. /var/lib/letsencrypt/http_challenges) because of incorrect permissions, such as:
$ sudo ls -la /var/lib/letsencrypt/
total 16
drwxr-x--- 4 root root 4096 Aug 26 14:31 .
drwxr-xr-x 72 root root 4096 Aug 18 00:48 ..
drwxr-x--- 27 root root 4096 Aug 26 14:26 backups
drwxr-xr-x 2 root root 4096 Aug 26 14:27 http_challenges
So, according to the above line with a dot (.) representing letsencrypt folder with permission rwxr-x---, no one except root user can read its content. To rectify permissions, I just did :
Solution
$ sudo chmod o+rx /var/lib/letsencrypt
which changes the above $ ls command output to :
$ ls -la /var/lib/letsencrypt/
total 16
drwxr-xr-x 4 root root 4096 Aug 26 14:31 .
drwxr-xr-x 72 root root 4096 Aug 18 00:48 ..
drwxr-x--- 27 root root 4096 Aug 26 14:26 backups
drwxr-xr-x 2 root root 4096 Aug 26 14:27 http_challenges
Now, the above line with a dot (.) representing letsencrypt directory indicates rwxr-xr-x, so that "other users" (like user www-data for apache2) can now read and go through letsencrypt directory.
Then certbot worked as expected.
In your server block, add:
# for LetsEncrypt
location ~ /.well-known {
allow all;
}
I guess you have another webroot for your sub domain and if so just need to specify that webroot. In your example you have the same webroot for both static.domain.com and domain.com.
from https://certbot.eff.org/docs/using.html
If you’re getting a certificate for many domains at once, the plugin
needs to know where each domain’s files are served from, which could
potentially be a separate directory for each domain. When requesting a
certificate for multiple domains, each domain will use the most
recently specified --webroot-path
certbot certonly --webroot -w /var/www/example/ -d www.example.com -d
example.com -w /var/www/other -d other.example.net -d
another.other.example.net
I came across a work around, since it is not the solution (not automatic), but it worked.
You can prove your domain ownership using DNS challenge, via The Certbot ;
sudo certbot -d domain.com --manual --preferred-challenges dns certonly
I had to remove the AAAA records for my domain as certbot was prefering IPV6. My webhost provider DNS had default AAAA records for www and # (root of domain).
After carefully examining the /var/log/letsencrypt/letsencrypt.log - down where it says "addressUsed", I saw that it was using an IPV6 address. In my case I don't have any website at www. or the root of my domain that are serviced by an IPV6 address so I removed the AAAA records and saw immediate relief to my problem. Due to dns propagation and record ttl, it may take longer for others to see relief.
certbot will try to connect to you using an IPV6 address if it was able to resolve one even though you're expecting the connection via IPV4 and that was the extent of my problems.
I suggested deleting the log so you have only fresh entries before continuing with the command - sudo rm /var/log/letsencrypt/legsencrypt.log - find the "addressUsed" and verify that it's an IPV4 address and not an IPV6 address. if its an IPV6 address, either forward that address at the gateway to your host and verify you're listening on IPV6 as well OR remove the AAAA records in DNS so that letsencrypt will connect to you using IPV4 address instead.
In case anyone still facing this issue, can try below and it worked for me :
location ^~ /.well-known/acme-challenge/ {
default_type "text/plain";
alias /home/nginx/domains/domain.com/public/acme-challenge/;
}
In my case I denied access to security related files (/.htaccess, /.htpasswd, etc.) via
location ~ /\. {
deny all;
}
Which I changed to
location ~ /\.ht {
deny all;
}
I don't want to unnecessarily repeat things, but it seems there are quite some different situations that can cause a 403 at certificate renewal. For me, it had to do with a changed nginx config because of Wordpress / url rewriting. Using Virtualmin btw.
There is a link above in the comments that refers to an issue on Github. One guy explains brilliantly how the location matches in nginx work and gives a solution for the 403. Still, there might be other issues causing this too.
Thus, for me the solution was to include a location match for /.well-known/.
location ^~ /.well-known/ {
#limit_req [tighter per-ip settings here]; ## kicked this one out
access_log off;
log_not_found off;
#root /var/www/html; ## kicked this one out
autoindex off;
index index.html; # "no-such-file.txt",if expected protos don't need it
try_files $uri $uri/ =404;
}
I am no nginx expert at all, so I would encourage you to read the post and check which parameters are needed for your situation.
I had working Let's encrypt certificates some months ago (with the old letsencrypt client).
The server I am using is nginx.
Certbot is creating the .well-known folder, but not the acme-challenge folder
Now I tried to create new certificates via ~/certbot-auto certonly --webroot -w /var/www/webroot -d domain.com -d www.domain.com -d git.domain.com
But I always get errors like this:
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: git.domain.com
Type: unauthorized
Detail: Invalid response from
http://git.domain.com/.well-known/acme-challenge/ZLsZwCsBU5LQn6mnzDBaD6MHHlhV3FP7ozenxaw4fow:
"<.!DOCTYPE html>
<.html lang='en'>
<.head prefix='og: http://ogp.me/ns#'>
<.meta charset='utf-8'>
<.meta content='IE=edge' http-equiv"
Domain: www.domain.com
Type: unauthorized
Detail: Invalid response from
http://www.domain.com/.well-known/acme-challenge/7vHwDXstyiY0wgECcR5zuS2jE57m8I3utszEkwj_mWw:
"<.html>
<.head><.title>404 Not Found</title></head>
<.body bgcolor="white">
<.center><.h1>404 Not Found</h1></center>
(Of course the dots inside the HTML tags are not really there)
I have looked for a solution, but didn't found one yet.
Does anybody know why certbot is not creating the folders?
Thanks in advance!
The problem was the nginx configuration.
I replaced my long configuration files with the simplest config possible:
server {
listen 80;
server_name domain.com www.domain.com git.domain.com;
root /var/www/domain/;
}
Then I was able to issue new certificates.
The problem with my long configuration files was (as far as I can tell) that I had the these lines:
location ~ /.well-known {
allow all;
}
But they should be:
location ~ /.well-known/acme-challenge/ {
allow all;
}
Now the renewal works, too.
I had a similar issue. My problem was, that I had this rule:
location ~ /\. {
access_log off;
log_not_found off;
deny all;
}
these lines where canceling every acces to any directory starting with a "." (point)
For some strange reason (I think the certbot script changed in some way), I was not able in any way to renew the certificates. I found this thread that finally helped me after almost 4 hours of research:
https://community.letsencrypt.org/t/solved-invalid-response-403-forbidden/64170/13
hope it helps somebody else.
The trick is to add this in the apache config :
DocumentRoot /var/lib/letsencrypt/http_challenges
<Directory /var/lib/letsencrypt/http_challenges>
Allow from All
</Directory>
Hope it works for someone else!