Failed Authentication

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
ttrss.shiromar.com

I ran this command:
sudo certbot --nginx -d ttrss.shiromar.com

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for ttrss.shiromar.com
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. ttrss.shiromar.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://ttrss.shiromar.com/.well-known/acme-challenge/Gl2IdRzwnxLVSH9HQ-IXVjoXC7856IewMSBDvcyXMuU: Timeout during connect (likely firewall problem)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: ttrss.shiromar.com
    Type: connection
    Detail: Fetching
    http://ttrss.shiromar.com/.well-known/acme-challenge/Gl2IdRzwnxLVSH9HQ-IXVjoXC7856IewMSBDvcyXMuU:
    Timeout during connect (likely firewall problem)

    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.

My web server is (include version):
nginx version: nginx/1.14.0 (Ubuntu)

The operating system my web server runs on is (include version):
Ubuntu 18.04

My hosting provider, if applicable, is:
SELF

I can login to a root shell on my machine (yes or no, or I don’t know):
YES

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
NO

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
certbot 0.31.0

nginx server block:
server {server {
listen 80;
listen [::]:80;
server_name ttrss.shiromar.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name ttrss.shiromar.com;
root /var/www/ttrss;
index index.php;
access_log /var/log/nginx/ttrss_access.log;
error_log /var/log/nginx/ttrss_error.log info;
location = /robots.txt {
add_header Content-Type text/plain;
return 200 “User-agent: *\nDisallow: /\n”;
}

ufw status
Status: active

To Action From


OpenSSH ALLOW Anywhere
8181/tcp ALLOW Anywhere
Nginx Full ALLOW Anywhere
443/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
3000 ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
8181/tcp (v6) ALLOW Anywhere (v6)
Nginx Full (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
3000 (v6) ALLOW Anywhere (v6)

This was working at one point but I was using --standalone -d ttrss.shiromar.com, this would not auto renew for me.

I deleted all the keys using certbot delete --cert-name ttrss.shiromar.com.I can confirm the directory /letsencrypt/live only has the “README” file.

When I tried to create a new certificate I received the above error.

As I said this was working just yesterday but the certificate expired. I did check the IP on the server and has not changed and all the forwarding rules are still correct.

Any clues on where I went wrong?

–Thanks

Hi @amanalar

your configuration is curious ( https://check-your-website.server-daten.de/?q=ttrss.shiromar.com ):

Domainname Http-Status redirect Sec. G
• http://ttrss.shiromar.com/
209.6.66.94 -14 10.026 T
Timeout - The operation has timed out
• https://ttrss.shiromar.com/
209.6.66.94 -4 0.513 W
SendFailure - The underlying connection was closed: An unexpected error occurred on a send. Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
• http://ttrss.shiromar.com:443/
209.6.66.94 -8 0.523 A
ConnectionClosed - The underlying connection was closed: The connection was closed unexpectedly.
Visible Content:
• http://ttrss.shiromar.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
209.6.66.94 -14 10.024 T
Timeout - The operation has timed out
Visible Content:

Your http answers with a timeout. And your https closes the connection.

Works your http internal (curl from console)?

What says

nginx -T

Hey @JuergenAuer ,

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

The server block I posted above should be redirecting any traffic to 443

The error happens for any of my subdomains as well. I don’t really want to change what’s already in ttrss. Try below

http://tautulli.shiromar.com
https://tautulli.shiromar.com

I can reach the nginx default page on http and dead on https

Domain: tautulli.shiromar.com
Type: connection
Detail: Fetching
http://tautulli.shiromar.com/.well-known/acme-challenge/s4Kuej4s0OVU3Im9MLVUR4nRw-9OE_j3xsFqntyf1XI:
Timeout during connect (likely firewall problem)

nginx -T, with a capital T, displays the configuration.

I can’t reach it on http or https. http times out, https does something like close the connection without sending a response.

1 Like
nginx -T

# configuration file /etc/nginx/sites-enabled/ttrss:
server  {
        listen          80;
        listen          [::]:80;
        server_name     ttrss.shiromar.com;
        return          301 https://$server_name$request_uri;
}
#
server {
        listen          443 ssl http2;
        listen          [::]:443 ssl http2;
        server_name     ttrss.shiromar.com;
        root /var/www/ttrss;
        index index.php;
        access_log /var/log/nginx/ttrss_access.log;
        error_log /var/log/nginx/ttrss_error.log info;
        location = /robots.txt {
                add_header Content-Type text/plain;
                return 200 "User-agent: *\nDisallow: /\n";
        }
#
        location / {
            index           index.php;
        }

#       ssl_certificate         /etc/letsencrypt/live/ttrss.shiromar.com/fullchain.pem;
#       ssl_certificate_key     /etc/letsencrypt/live/ttrss.shiromar.com/privkey.pem;
#       ssl_trusted_certificate /etc/letsencrypt/live/ttrss.shiromar.com/chain.pem;

        location ~ \.php$ {
            try_files $uri = 404; #Prevents autofixing of path which could be used for exploit
            fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
            fastcgi_index index.php;
            include /etc/nginx/fastcgi.conf;
        }

}

Rechecked your domain, it’s the same picture: Only timeouts:

Domainname Http-Status redirect Sec. G
• http://ttrss.shiromar.com/
209.6.66.94 -14 10.030 T
Timeout - The operation has timed out
• https://ttrss.shiromar.com/
209.6.66.94 -4 0.503 W
SendFailure - The underlying connection was closed: An unexpected error occurred on a send. Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
• http://ttrss.shiromar.com:443/
209.6.66.94 -3 0.510 A
ReceiveFailure - The underlying connection was closed: An unexpected error occurred on a receive. Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
Visible Content:
• http://ttrss.shiromar.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
209.6.66.94 -14 10.027 T
Timeout - The operation has timed out
Visible Content:

Is this - 209.6.66.94 - the ip address of your server?

Use online tools to check if your server answers.

See https://www.uptrends.com/de/tools/uptime

All is red, thats your first http address.

1 Like

thanks @JuergenAuer ,

I’m using a vm backup thats working. The confusion in my part was that I can access http from the local network, though not https. Outside the network is as you show; unreachable.

So this was not a letsencrypt issue. The issue lies in ubuntu itself. I need to figure out that if the vm backup is working what changed in my current vm that makes nginx not accessible outside my network.

All my server blocks in nginx, ufw rules, port forwarding rules, all match between VMs. I’ll have to seek help on serverfault or something, I can’t figure out what’s changed…

1 Like

Okay then, let’s try this again :slight_smile:

I restored VM to a working state from a backup. Uptrends shows it to be reachable at:
https://ttrss.shiromar.com

sudo certbot --nginx -d ttrss.shiromar.com`
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for ttrss.shiromar.com
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. ttrss.shiromar.com (http-01): urn:ietf:params:acme:error:connection :: The server
could not connect to the client to verify the domain :: Fetching
http://ttrss.shiromar.com/.well-known/acme-challenge/yB_z3s4qb2ZhME0EoU-fR8j9tC7mcEh7QgrjslCt1IE:
Timeout during connect (likely firewall problem)

IMPORTANT NOTES:

  • The following errors were reported by the server:
    Domain: ttrss.shiromar.com
    Type: connection
    Detail: Fetching
    http://ttrss.shiromar.com/.well-known/acme-challenge/yB_z3s4qb2ZhME0EoU-fR8j9tC7mcEh7QgrjslCt1IE:
    Timeout during connect (likely firewall problem)
    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.

Well, everything is like before. Your site can’t still be accessed on port 80.
How about debugging ?

wget http://yourwebsite
from the inside of the network; does it work ? if yes, start on the server console a tcpdump session

tcpdump -i yourinterface port 80

then do again a wget, still on the inside of the network.
You should see a tcp connection (at least).
This will serve as a baseline, do a screen copy if your memory is not good enough.

Then do the same thing from the outside of the network
Do you get a TCP exchange similar to what you got from the inside ?

if not, if what you get is nothing there is a firewall somewhere between your computer and the Internet (your hoster, your corp box, whatever)

if yes, then and only then it can be a nginx problem.

I can’t see any way it could be a let’s encrypt bug or problem.

Okay I’m a bit confused, If I have traffic going out of port 443 why do I need to have port 80 open?

Because that’s how the let’s encrypt http certificate validation works.
You have to prove that you control the domain; you ask for it to let’s encrypt server on port 443. Then the let’s encrypt server replies by informing you that it is about to ask for the proof by querying the domain on the port 80, standard http port for a given file.
Why it works like that is beside the point. It’s how it is. If that’s not possible for you there is another kind of validation (dns based) but this not what you are doing at the moment.

That’s required to use http-01 validation.

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