Renewal of existing certificate fails due to domain authentication failure

Hello,

I received an email noting that my will expire. This is strange because everything has been working for some time now and there have not been any (intentional) changes made to anything.

My domain is: eafarcstats.com

I ran this command: certbot renew --dry-run

It produced this output:

Processing /etc/letsencrypt/renewal/eafarcstats.com.conf


Simulating renewal of an existing certificate for eafarcstats.com and www.eafarcstats.com

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: eafarcstats.com
Type: dns
Detail: During secondary validation: no valid A records found for eafarcstats.com; no valid AAAA records found for eafarcstats.com

Domain: www.eafarcstats.com
Type: dns
Detail: During secondary validation: no valid A records found for www.eafarcstats.com; no valid AAAA records found for www.eafarcstats.com

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.

Failed to renew certificate eafarcstats.com with error: Some challenges have failed.


All simulated renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/eafarcstats.com/fullchain.pem (failure)

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

The operating system my web server runs on is (include version): Debian 5.10.149-1

My hosting provider, if applicable, is: NA

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 2.10.0

Several of the other similar requests for assistance asked for the output of nginx -T, and is the following:

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

configuration file /etc/nginx/nginx.conf:

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
worker_connections 1024;
# multi_accept on;
}

http {

##
# Basic Settings
##

sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;

# server_names_hash_bucket_size 64;
# server_name_in_redirect off;

include /etc/nginx/mime.types;
default_type application/octet-stream;

index index.html index.htm;

    upstream app_server {
        server 127.0.0.1:51500 fail_timeout=0;
    }

    server {
    # if no Host match close the connection to prevent spoofing
        listen 80 default_server;
        return 444;
    }

    server {

    # This will be eliminated when you install certbot for https
    # Just using for testing right now

    # uncomment after updating Route 53 to point to this server
        server_name  eafarcstats.com www.eafarcstats.com;

        client_max_body_size 4G;

        keepalive_timeout 5;

        # path for static files
        root         /usr/share/nginx/html;

        location / {
        # checks for static file, if not found proxy to app
            try_files $uri @proxy_to_app;
        }

        location @proxy_to_app {
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header Host $http_host;
            # we don't want nginx trying to do something clever with
            # redirects, we set the Host: header above already.
            proxy_redirect off;
            #proxy_read_timeout 120s;
            # FIXME: turning this on prevents the overview from loading........, and downloads from working properly
            # gunicorn says this has to be on or you have to use asyncio workers. not really correct in your case.
            proxy_buffering off;
            #proxy_temp_file_write_size 16k;
            proxy_buffer_size 4k; # this is still used with proxy_buffering off
            # proxy_buffers number and size only used if proxy_buffering is on
            proxy_buffers 12 8k; # set the number and size of buffers (8 default, 4k|8k for size)
            
            # had proxy_temp_path set to /tmp for a long time. nginx apparently can't create a dir
            # in tmp, or tried to create /tmp/nginx/proxy_temp dir with mkdir() and failed. This
            # was in the error logs multiple times but was never an issue. Apparently it caused a
            # crash on 01/27/20 @ 04:29:01. Can't find much info on what this directory is even
            # used for. Set it to the nginx log directory. Not sure why it was set to /tmp to begin
            # with.
            #proxy_temp_path /tmp/nginx/proxy_temp 1;

            #error_log /var/log/nginx/error.log;
            proxy_temp_path /var/log/nginx/proxy_temp 1;
            proxy_pass http://app_server;
        }

        # redirect server error pages to the static page /40x.html
        #
        # CHECKME
        error_page 404 /404.html;
            location = /40x.html {
        }

        # redirect server error pages to the static page /50x.html
        #
        # CHECKME
        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }

    
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/eafarcstats.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/eafarcstats.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

##
# SSL Settings
##

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;

##
# Logging Settings
##

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

##
# Gzip Settings
##

gzip on;

# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

##
# Virtual Host Configs
##

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;


    server {
if ($host = www.eafarcstats.com) {
    return 301 https://$host$request_uri;
} # managed by Certbot


if ($host = eafarcstats.com) {
    return 301 https://$host$request_uri;
} # managed by Certbot


    listen 80;
    listen [::]:80;

        server_name  eafarcstats.com www.eafarcstats.com;
return 404; # managed by Certbot

}}

Thank you.

Error message isn't complaining about nginx.

Considering that it's only secondary validation, you could wait a few hours and try again. If that doesn't work, check that your NS records are what you need them to be.

2 Likes

Yes, check those. We have gotten a number of problems related to Route53 changing the set of name servers used for hosted zones. Double check they haven't changed.

It looks like at least one of them did change per

https://dnsviz.net/d/eafarcstats.com/dnssec/

2 Likes

Will do. Thank you.

3 Likes

I'm not sure what is meant by secondary validation. This has been going on for a few days now and so doesn't seem to be a time issue.

Checked the route 53 NS records and they added ns-1932.awsdns-49.co.uk. Updated the domain with it but am still getting the failure to renew. I assume it may take a while to propagate through.

I also have geolocation blocking enabled in Route53. Not sure if this would be an issue, it's been enabled for several years now and hasn't been an issue so far.

Hi @steeljav

Let's Encrypt uses Multi-Perspective Validation Improves Domain Validation Security - Let's Encrypt.

And

1 Like

It's an issue, yes. Secondary validation implies several requests from all over the globe, and that geography changed recently.

4 Likes

Also @steeljav try testing with the online Let's Debug.

1 Like

The issue was the geolocation blocking in Route53. Disabled it and was able to renew the certificate.

It would be good to know what the secondary validation endpoints are so that geolocation blocking doesn't have to get disabled to renew certificates. Or at least narrow it down to a continent or 2.

Let's Encrypt does not publish the locations as they can change at any notice.

2 Likes

They don't publish and an FAQ and many comments caution about relying on any specific pattern.

That said, see this thread which has some details about this recent change to the "remote" authentication sites

But be sure to also see this post in same thread by different staff member

2 Likes

Thank you.

2 Likes