permission issues in docker are common, we’ll see when verification works. 
I’ve been able to remove permission issue by copying security files to another folder but I still have this error:
to solve that you need to wait. it’s the only way. your MX record had way too high ttl and without A record, it took over. waiting lets caches forget the MX record and ask your authoritative servers for the A record.
1 Like
Let’s Encrypt always directly queries authoritative DNS servers and never relies on caches for its validations.
5 Likes
@Encrypt1919: probably unrelated, but you have a redirect loop on non-www gotobot.co
% curl -i https://gotobot.co/.well-known/acme-challenge/hwbryuh
HTTP/1.1 301 Moved Permanently
Date: Sun, 08 Mar 2020 01:43:59 GMT
Server: Apache
Location: http://www.gotobot.co/.well-known/acme-challenge/hwbryuh
Content-Length: 264
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.gotobot.co/.well-known/acme-challenge/hwbryuh">here</a>.</p>
</body></html>
% curl -i http://gotobot.co/.well-known/acme-challenge/hwbryuh
HTTP/1.1 302 Found
Date: Sun, 08 Mar 2020 01:44:03 GMT
Server: Apache
Location: https://gotobot.co/.well-known/acme-challenge/hwbryuh
Content-Length: 237
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://gotobot.co/.well-known/acme-challenge/hwbryuh">here</a>.</p>
</body></html>
1 Like
I’ve tried it now again, same error persists.
I think that redirect loop is probably the issue, can you tell me how can I remove that?
Right now the problem is that your server isn't answering on port 80:
% curl -i 184.72.187.19
curl: (7) Failed to connect to 184.72.187.19 port 80: Connessione rifiutata
double check that's the right ip, please. (curl ifconfig.me)
check your virtualhosts on port 443, and maybe your apps, something is redirecting to http
1 Like
I’ve run that command and I get this: 184.72.187.19
I will check them.
Then you have an exceptionally mean firewall. Tell it to relax and allow people to connect to port 80.
1 Like
I’ve went to /etc/nginx /nginx.conf and this is related to port 80, everything else is more or less commented out, I’ve check other folders like conf.d and defaults.d and they are empty.
I probably shouldn’t check locally but in my files that I’m trying to run with docker-compose.
I have there config file related to redirect to https:
server {
listen 80;
server_name _;
location /.well-known/acme-challenge/ {
# allow letsencrypt to verify challenges
root /var/www/certbot;
# put extra configuration here, if needed
}
location / {
# return 301 https://$server_name$request_uri;
return 301 https://$host$request_uri;
# return 301 http://$host$request_uri;
}
}
This is in nginx.conf:
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
include /etc/nginx/conf.d/*.conf;
}
This is default.conf
upstream api {
server 184.72.187.19:5005;
}
server {
listen 443 ssl;
server_name www.gotobot.co
# server_name localhost;
# only allow access while testing
# @TODO remove for production
#allow 127.0.0.1;
#allow 83.71.213.166;
#deny all;
include partials/common.conf;
include partials/ssl.conf;
# location /.well-known/acme-challenge/ {
# root /var/www/certbot;
# }
location / {
proxy_pass http://api/webhooks/rest/webhook;
include partials/common_location.conf;
include partials/cors.conf;
}
}
map $remote_addr $proxy_forwarded_elem {
# IPv4 addresses can be sent as-is
~^[0-9.]+$ "for=$remote_addr";
# IPv6 addresses need to be bracketed and quoted
~^[0-9A-Fa-f:.]+$ "for=\"[$remote_addr]\"";
# Unix domain socket names cannot be represented in RFC 7239 syntax
default "for=unknown";
}
map $http_forwarded $proxy_add_forwarded {
# If the incoming Forwarded header is syntactically valid, append to it
"~^(,[ \\t]*)*([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?(;([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?)*([ \\t]*,([ \\t]*([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?(;([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?)*)?)*$" "$http_forwarded, $proxy_forwarded_elem";
# Otherwise, replace it
default "$proxy_forwarded_elem";
}Check your firewall please.
I am an idiot. The redirect loop is not on the machine you are working on. It’s on the other one.
This is your only problem: Error cannot load certificate "/etc/letsencrypt/live/domainname/fullchain.pem"
You might need to enter that container while the validation is going on and read the nginx error logs. (maybe docker-compose logs will help you)
1 Like
In those logs is only this:
And I’ve “solved” this by copying the certificates into a local repo and loaded them from there.
So my error remained this:
edit this to 80:80 and 443:443, then try again.
Same error persists after I put my nginx ports like you said:
ports:
- "80:80"
- "443:443"
When I edit my vue docker port part to 80:80 instead of 80 I get this error:
vue:
container_name: vue-landing
build:
context: ./VueLanding
networks: ['rasa-network']
ports:
- "80:80"
This is very, very strange. @schoen ideas?
# for ns in `dig +short ns gotobot.co`; do dig +short @$ns a www.gotobot.co ; done
gotobot.co.
184.72.187.19
gotobot.co.
184.72.187.19
gotobot.co.
184.72.187.19
gotobot.co.
184.72.187.19
(this is from a vps, not from my dns-intercepted home network)
I’ve tried changing this in my default.conf from my ip adress of the ec2 instance(184.72.187.19:5005) to:
upstream api {
server <internal_ip_address>:5005;
}
and then I’m back at this error:
Hi @JuergenAuer, I saw that you posted on several threads with similiar issues like mine and checked their domains with this site:
Can you maybe read the problem from my?