NEXTCLOUD: need help with authorization and timeout error while trying to obtain certificate

root@cloud:/var/www/letsencrypt# letsencrypt certonly -a webroot --webroot-path=/var/www/letsencrypt --rsa-key-size 4096 -d cloud92.ddns.net
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for cloud92.ddns.net
Using the webroot path /var/www/letsencrypt for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. cloud92.ddns.net (http-01): urn:acme:error:connection:: The server could not connect to the client to verify the domain :: Fetching http: //cloud92.ddns.net/.well-known/acme-challenge/MYUKB78hCofZxOW7oLTcvBUiic78mwqjXkmcVgYlBm8: Timeout

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: cloud92.ddns.net
    Type: connection
    Detail: Fetching
    http://cloud92.ddns.net/.well-known/acme-challenge/MYUKB78hCofZxOW7oLTcvBUiic78mwqjXkmcVgYlBm8:
    Timeout

    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. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.
    ===========================================================

By running this command below i get the following:-
root@cloud:/var/www/nextcloud# nginx -T | grep root
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
root /var/www/letsencrypt;
root /var/www/nextcloud/;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
root@cloud:/var/www/nextcloud# nano /etc/nginx/conf.d/nextcloud.conf

I cannot access http://cloud92.ddns.net/ either.

Are you sure nginx is running? (systemctl status nginx or service nginx status)

Did you check your firewall and A records like the error message suggests?

Does your domain work for you if you use a different Internet connection, such as from a smartphone or public WiFi?

Do you mean router firewall? I cant even access either from other machine.

This is the output of service nginx status
root@cloud:~# service nginx status
● nginx.service - nginx - high performance web server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2017-10-16 12:56:12 EDT; 23h ago
Docs: http://nginx.org/en/docs/
Process: 3210 ExecStop=/bin/kill -s TERM $MAINPID (code=exited, status=0/SUCCESS)
Process: 3217 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)
Process: 3214 ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)
Main PID: 3218 (nginx)
CGroup: /system.slice/nginx.service
├─3218 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.con
├─3219 nginx: worker process
├─3220 nginx: worker process
├─3221 nginx: worker process
├─3222 nginx: worker process
└─3223 nginx: cache manager process

Oct 16 12:56:12 cloud systemd[1]: Starting nginx - high performance web server…
Oct 16 12:56:12 cloud nginx[3214]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
Oct 16 12:56:12 cloud nginx[3214]: nginx: configuration file /etc/nginx/nginx.conf test is successful
Oct 16 12:56:12 cloud systemd[1]: Started nginx - high performance web server.

Output of systemctl status nginx
root@cloud:~# systemctl status nginx
● nginx.service - nginx - high performance web server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2017-10-16 12:56:12 EDT; 23h ago
Docs: http://nginx.org/en/docs/
Process: 3210 ExecStop=/bin/kill -s TERM $MAINPID (code=exited, status=0/SUCCESS)
Process: 3217 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)
Process: 3214 ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)
Main PID: 3218 (nginx)
CGroup: /system.slice/nginx.service
├─3218 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.con
├─3219 nginx: worker process
├─3220 nginx: worker process
├─3221 nginx: worker process
├─3222 nginx: worker process
└─3223 nginx: cache manager process

Oct 16 12:56:12 cloud systemd[1]: Starting nginx - high performance web server…
Oct 16 12:56:12 cloud nginx[3214]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
Oct 16 12:56:12 cloud nginx[3214]: nginx: configuration file /etc/nginx/nginx.conf test is successful
Oct 16 12:56:12 cloud systemd[1]: Started nginx - high performance web server.

In order to use webroot authentication, your server must be publicly accessible on the Internet at port 80 so the challenge file can be retrieved. So you must port forward from your router to the server certbot is running on if you want to get a certificate that way.

If you do not wish to make your server publicly available, you must use DNS authentication instead. (But unfortunately none of the clients support automating that with no-ip.com DNS right now. :slightly_frowning_face:)

Thanks Patches.

Yes, I have forwarded the port 80 and port 443 both. (should i port forward only 80 ?)

So does this means “noip” is not supported with any of the clients? Should i changes the dns provider?

Let's Encrypt only requires port 80 for http-01/webroot authentication, but you probably want port 443 forwarded for actual humans. :grinning:

It's possible that your ISP blocks port 80. You could try forwarding port 8080 or so from your router to port 80 on your server. If this results in your website being accessible at http://cloud92.ddns.net:8080/, then your ISP does block port 80, and you cannot get a certificate with --webroot.

If your ISP really is blocking port 80, then another method of website verification that might work for you would be more difficult with No-IP. But we should first confirm whether this is really the case, as the verification method you are currently trying to use should work fine with them.

Patches,

You were correct. ISP was blocking Port 80. Now i have the port 80 open from ISP website and also tested it via yougetsignal.com and it says port 80 is open.

It tried letsencrypt again , looks like i am not getting timeout error anymore but i am getting following error.

root@cloud:/var/www# letsencrypt certonly -a webroot --webroot-path=/var/www/letsencrypt --rsa-key-size 4096 -d cloud92.ddns.net
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for cloud92.ddns.net
Using the webroot path /var/www/letsencrypt for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. cloud92.ddns.net (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://cloud92.ddns.net/.well-known/acme-challenge/kYirjiJ3KostUiOat_7wRwdx7FpQdq1Pt3VxH9_k-EA: "

403 Forbidden

403 Forbidden


"

IMPORTANT NOTES:

Your webserver restricts access to the location /.well-known/acme-challenge/kYirjiJ3KostUiOat_7wRwdx7FpQdq1Pt3VxH9_k-EA

You have to allow access to that location in the nginx configuration.

I did check in nginx.conf file and i dont see anything about giving permission to this location.

Could you paste the Nginx configuration? There could be something like “location ~ /\. {” to block access to paths that start with “.”.

Also, check the Nginx error.log? It could be that the configuration is fine, but the permissions on the directories leave Nginx unable to access it.

Sure. Here is my nginx.conf file

user www-data;
worker_processes auto;

or: worker_processes 4;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
multi_accept on;
use epoll;
}
http {
server_names_hash_bucket_size 64;
upstream php-handler {
server unix:/run/php/php7.1-fpm.sock;
}
include /etc/nginx/mime.types;
limit_req_zone $binary_remote_addr zone=wp_ddos:20m rate=2r/m;
include /etc/nginx/proxy.conf;
include /etc/nginx/ssl.conf;
include /etc/nginx/header.conf;
include /etc/nginx/optimization.conf;
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” ‘
’"$host" sn="$server_name" '
'rt=$request_time '
'ua="$upstream_addr" us="$upstream_status" '
'ut="$upstream_response_time" ul="$upstream_response_length" '
‘cs=$upstream_cache_status’ ;
access_log /var/log/nginx/access.log main;
sendfile on;
send_timeout 3600;
tcp_nopush on;
tcp_nodelay on;
open_file_cache max=500 inactive=10m;
open_file_cache_errors on;
keepalive_timeout 65;
reset_timedout_connection on;
server_tokens off;
resolver 192.168.1.1;
resolver_timeout 10s;
include /etc/nginx/conf.d/*.conf;
}

le.error.log output
root@cloud:/var/log/nginx# more le.error.log
2017/10/20 06:43:45 [error] 18912#18912: *79 open() “/var/www/letsencrypt/.well-known/acme-challenge/MYUKB78hCofZxOW7oLTcvBUiic78mwqjXkmcVgYlBm8:” failed (13: Permission de
nied), client: 127.0.0.1, server: 127.0.0.1, request: “GET /.well-known/acme-challenge/MYUKB78hCofZxOW7oLTcvBUiic78mwqjXkmcVgYlBm8: HTTP/1.0”, host: “cloud92.ddns.net

============

there is nothing in /var/log/nginx/error.log file. its empty

What are the permissions on that path?

namei -l /var/www/letsencrypt/.well-known/acme-challenge
1 Like

Here is the permission of the path

root@cloud:/var/www/letsencrypt# namei -l /var/www/letsencrypt/.well-known/acme-challenge
f: /var/www/letsencrypt/.well-known/acme-challenge
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-x— root root www
drwxr-x— root root letsencrypt
drwxr-xr-x root root .well-known
drwxr-xr-x root root acme-challenge

/var/www and /var/www/letsencrypt probably need to be adjusted so Nginx can access them.

E.g. "chmod 755 /var/www /var/www/letsencrypt" to make them world-readable, or you could change the owner/group to www-data or whatever it runs as.

Thank you mnordhoff. That did the trick…permissions!!! Thanks again. :slight_smile:

1 Like

Now i have the certificate…

2 Likes

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