Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:

Good day, all.
I can't get the let's encrypt sertificate.

My domain is: cloud0.projectsk.ru

I ran this command: certbot --nginx

It produced this output: Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems: Domain: cloud0.projectsk.ru Type: connection Detail: 212.49.98.198: Fetching http://cloud0.projectsk.ru/.well-known/acme-challenge/DTWoGg4o3cTGGvj3z9ftTKvz07VPyNupTIznK-GCcjw: Connection refused
In log file /var/log/letsencrypt/letsencrypt.log:

Blockquote 2023-08-14 16:27:48,286:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "POST /acme/authz-v3/254870815726 HTTP/1.1" 200 1044
2023-08-14 16:27:48,287:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Mon, 14 Aug 2023 11:27:48 GMT
Content-Type: application/json
Content-Length: 1044
Connection: keep-alive
Boulder-Requester: 1250976346
Cache-Control: public, max-age=0, no-cache
Link: https://acme-v02.api.letsencrypt.org/directory;rel="index"
Replay-Nonce: 691VxMFkrL21l6WygG-ZiKGO3Ni5FAEK7fmFHh1IXDT2SFrZfIE
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800
{
"identifier": {
"type": "dns",
"value": "cloud0.projectsk.ru"
},
"status": "invalid",
"expires": "2023-08-21T11:27:45Z",
"challenges": [
{
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:ietf:params:acme:error:connection",
"detail": "212.49.98.198: Fetching http://cloud0.projectsk.ru/.well-known/acme-challenge/DTWoGg4o3cTGGvj3z9ftTKvz07VPyNupTIznK-GCcjw: Connection refused",
"status": 400
},
"url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/254870815726/zhLY3A",
"token": "DTWoGg4o3cTGGvj3z9ftTKvz07VPyNupTIznK-GCcjw",
"validationRecord": [
{
"url": "http://cloud0.projectsk.ru/.well-known/acme-challenge/DTWoGg4o3cTGGvj3z9ftTKvz07VPyNupTIznK-GCcjw",
"hostname": "cloud0.projectsk.ru",
"port": "80",
"addressesResolved": [
"212.49.98.198"
],
"addressUsed": "212.49.98.198"
}
],
"validated": "2023-08-14T11:27:46Z"
}
]
}
2023-08-14 16:27:48,287:DEBUG:acme.client:Storing nonce: 691VxMFkrL21l6WygG-ZiKGO3Ni5FAEK7fmFHh1IXDT2SFrZfIE
2023-08-14 16:27:48,288:INFO:certbot._internal.auth_handler:Challenge failed for domain cloud0.projectsk.ru
2023-08-14 16:27:48,288:INFO:certbot._internal.auth_handler:http-01 challenge for cloud0.projectsk.ru
2023-08-14 16:27:48,288:DEBUG:certbot._internal.display.obj:Notifying user:
Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: cloud0.projectsk.ru
Type: connection
Detail: 212.49.98.198: Fetching http://cloud0.projectsk.ru/.well-known/acme-challenge/DTWoGg4o3cTGGvj3z9ftTKvz07VPyNupTIznK-GCcjw: Connection refused
Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.

My web server is (include version): nginx version: nginx/1.22.1

nginx -T

configuration file /etc/nginx/sites-enabled/cloud.conf:

server {
        listen 80;
        listen 443 ssl;
        server_name cloud0.projectsk.ru;

        if ($scheme = 'http') {
            return 301 https://$host$request_uri;
        }

        ssl_certificate /etc/nginx/ssl/cert.cert;
        ssl_certificate_key /etc/nginx/ssl/cert.key;

        root /var/www/cloud;

        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        client_max_body_size 10G;
        fastcgi_buffers 64 4K;

        rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;
        rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
        rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;

        index index.php;
        error_page 403 = /core/templates/403.php;
        error_page 404 = /core/templates/404.php;

        location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;
        }

        location ~ ^/(data|config|\.ht|db_structure\.xml|README) {
                deny all;
        }

        #location /.well-known {
        #       root /var/www/cloud;
        #}
        location ^~ /.well-known {
                location = /.well-known/carddav { return 301 /remote.php/dav/; }
                location = /.well-known/caldav  { return 301 /remote.php/dav/; }
                location = /.well-known/webfinger  { return 301 /index.php/.well-known/webfinger; }
                location = /.well-known/nodeinfo  { return 301 /index.php/.well-known/nodeinfo; }
                location ^~ /.well-known{ return 301 /index.php/$uri; }
                try_files $uri =404;
        }

        location / {
                rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
                rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
                rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;
                try_files $uri index.php;
        }

        location ~ ^(.+?\.php)(/.*)?$ {
                try_files $1 = 404;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$1;
                fastcgi_param PATH_INFO $2;
                fastcgi_param HTTPS on;
                fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        }

        location ~* ^.+\.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
                expires modified +30d;
                access_log off;
        }
}

The operating system my web server runs on is (include version): Debian 12.1

My hosting provider, if applicable, is:

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

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

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

Hi @dimnix, and welcome to the LE community forum :slight_smile:

It is very uncommon to handle HTTP and HTTPS within the same vhost.
Some would say that it is not possible and certainly most would say it is not recommended.
Is that something you've proven to work for you [as expected]?

2 Likes

Why would you do this?

Instead of this:

server {
        listen 80;
        server_name cloud0.projectsk.ru;
        return 301 https://$host$request_uri;
}
server {
        listen 443 ssl;
        server_name cloud0.projectsk.ru;

        # EVERYTHING ELSE
}
2 Likes

Thank you, for reply.

Now I have corrected the configuration file, but the error remains.

server {
        listen 80;
        server_name cloud0.projectsk.ru;
        return 301 https://$host$request_uri;
        }
server {
        listen 443 ssl;
        server_name cloud0.projectsk.ru;
        if ($scheme = 'http') {
            return 301 https://$host$request_uri;
        }

        ssl_certificate /etc/nginx/ssl/cert.cert;
        ssl_certificate_key /etc/nginx/ssl/cert.key;

        root /var/www/cloud;

        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        client_max_body_size 10G;
        fastcgi_buffers 64 4K;

        rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;
        rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
        rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;

        index index.php;
        error_page 403 = /core/templates/403.php;
        error_page 404 = /core/templates/404.php;

        location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;
        }

        location ~ ^/(data|config|\.ht|db_structure\.xml|README) {
                deny all;
        }

             location ^~ /.well-known {
                location = /.well-known/carddav { return 301 /remote.php/dav/; }
                location = /.well-known/caldav  { return 301 /remote.php/dav/; }
                location = /.well-known/webfinger  { return 301 /index.php/.well-known/webfinger; }
                location = /.well-known/nodeinfo  { return 301 /index.php/.well-known/nodeinfo; }
                location ^~ /.well-known{ return 301 /index.php/$uri; }
                try_files $uri $uri/ =404;
        }

        location / {
                rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
                rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
                rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;
                try_files $uri $uri/ index.php;
        }

        location ~ ^(.+?\.php)(/.*)?$ {
                try_files $1 = 404;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$1;
                fastcgi_param PATH_INFO $2;
                fastcgi_param HTTPS on;
                fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        }

        location ~* ^.+\.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
                expires modified +30d;
                access_log off;
        }
}

certbot --dry-run --nginx -d cloud0.projectsk.ru
Simulating a certificate request for cloud0.projectsk.ru

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
  Domain: cloud0.projectsk.ru
  Type:   connection
  Detail: 212.49.98.198: Fetching http://cloud0.projectsk.ru/.well-known/acme-challenge/p52O8eYv2SrHllTONmcrTKUcmdx59Kku6SkYA3w7G7A: Error getting validation data

Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.

this needs to go.

this is interfering with certbot. make sure .well-known/acme-challenge is left alone.

3 Likes

The --nginx plug-in does not support --dry-run.

What command did you actually use for that result?

Also, the --nginx authenticator should insert temp changes to your listen 80; server block. So, those location settings should not interfere.

But, it looks like port 80 is being blocked by a firewall. You must have port 80 open for the HTTP Challenge used by --nginx plug-in. Use the Let's Debug test site after you make changes to fix this

1 Like

[quote="9peppe, post:5, topic:203492, full:true"]

this needs to go.

Here is part of the config, but the result is the same..

server {
        listen 80;
        server_name cloud0.projectsk.ru;
        return 301 https://$host$request_uri;

location ^~ /.well-known{ return 301 /index.php/$uri; }
}

sudo certbot --nginx -d cloud0.projectsk.ru
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for cloud0.projectsk.ru

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
  Domain: cloud0.projectsk.ru
  Type:   connection
  Detail: 212.49.98.198: Fetching http://cloud0.projectsk.ru/.well-known/acme-challenge/LtAQpTU8HoxL05xB5AqPRA-VR61dV1roC4dMvbDjTAc: Error getting validation data

Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

sudo certbot --nginx -d cloud0.projectsk.ru

I don't have a firewall installed at the moment.

sudo netstat -tulpn | grep LISTEN
tcp        0      0 0.0.0.0:10000           0.0.0.0:*               LISTEN      861/perl            
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      858/exim4           
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      455/redis-server 12 
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      543/mariadbd        
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      485/sshd: /usr/sbin 
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      6659/nginx: master  
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      578/smbd            
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      6659/nginx: master  
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      578/smbd            
tcp6       0      0 ::1:25                  :::*                    LISTEN      858/exim4           
tcp6       0      0 :::22                   :::*                    LISTEN      485/sshd: /usr/sbin 
tcp6       0      0 :::80                   :::*                    LISTEN      6659/nginx: master  
tcp6       0      0 :::139                  :::*                    LISTEN      578/smbd            
tcp6       0      0 ::1:6379                :::*                    LISTEN      455/redis-server 12 
tcp6       0      0 :::445                  :::*                    LISTEN      578/smbd            

But I can put, for example, ufw, and configure it if you think it will help.

No, that won't help. The netstat shows nginx is listening on port 80 but it cannot be reached from the public internet. Something in front of nginx is blocking it. You should check your router or other comms config.

Use the Let's Debug test site I linked earlier to check changes you make to see if they helped. Once Let's Debug says it is OK you should try again to get a cert.

Here is more evidence that port 80 is blocked by something (filtered usually means a firewall somewhere)

nmap -p80,443 cloud0.projectsk.ru
Nmap scan report for cloud0.projectsk.ru (212.49.98.198)

PORT    STATE    SERVICE
80/tcp  filtered http
443/tcp open     https
2 Likes

Thank you very much for your help. The problem turned out to be in the rule on the router. I corrected it and everything worked.

nmap -p80,443 cloud0.projectsk.ru
Starting Nmap 7.93 ( https://nmap.org ) at 2023-08-15 09:47 +05
Nmap scan report for cloud0.projectsk.ru (192.168.0.189)
Host is up (0.00018s latency).

PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: cloud0.projectsk.ru
    Serial Number: 35fd8ac13f3af68ffaa360e48e1e0d4ef90
    Key Type: ECDSA
    Domains: cloud0.projectsk.ru
    Expiry Date: 2023-11-13 03:48:40+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/cloud0.projectsk.ru/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/cloud0.projectsk.ru/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

2 Likes

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