Fallo en la renovación del certificado Certbot

Instalación
,
1

Tenemos un problema con la renovación de SSL de certbot. Tenemos varios sitios en /etc/nginx/sites-available/.

Tenemos este bloque de ubicación para el directorio .well-known

    location ~ /\\.well-known {
        auth_basic off;
        root /etc/letsencrypt;
        allow all;
    }

y tenemos configuraciones de renovación para cada sitio en el directorio /etc/letsencrypt/renewal.
Este es un ejemplo de uno de ellos.

#renew_before_expiry = 30 days
version = 2.7.4
archive_dir = /etc/letsencrypt/archive/redacted.com
cert = /etc/letsencrypt/live/redacted.com/cert.pem
privkey = /etc/letsencrypt/live/redacted.com/privkey.pem
chain = /etc/letsencrypt/live/redacted.com/chain.pem
fullchain = /etc/letsencrypt/live/redacted.com/fullchain.pem

#Options used in the renewal process
[renewalparams]
allow_subset_of_names = True
account = 670273d7a9a89f2d3494cf6e38739b1c
rsa_key_size = 4096
post_hook = /bin/systemctl reload nginx
authenticator = webroot
webroot_path = /etc/letsencrypt,
server = https://acme-v02.api.letsencrypt.org/directory
key_type = rsa
[[webroot_map]]
redacted.com = /etc/letsencrypt

Nuestra versión de certbot es 2.7.4, actualizamos desde 1.32.0 y tampoco funcionó.

Sabemos que nuestro problema está relacionado con ip6tables, pero ya tenemos reglas ACCEPT para los puertos 443 y 80.

Cuando intentamos acceder a los archivos acme-challenge durante certbot renew --dry-run, podemos acceder a los archivos con éxito. Así que el puerto 80 y 443 no deberían ser el problema.

Cuando cambiamos el filtro de entrada de ip6tables de DROP a ACCEPT, todos los sitios pueden renovarse, pero cuando usamos el filtro INPUT DROP, la mayoría de los sitios fallan al renovarse con este error.

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: redacted.com
Type: connection
Detail: xxx.xxx.xxx.xxx: Fetching https://redacted.com/.well-known/acme-challenge/EIJFF3UFqtZJCZtG_Kv9Ca7BGA5LiuBdb9JIWxXIhVg: Timeout during connect (likely firewall problem)

Ya intentamos con el conjunto mínimo de reglas e intentamos agregar reglas ACCEPT para los puertos 80 y 443 encima de la cadena de entrada, pero tampoco funcionó. Así que estamos atascados aquí.

Se puede encontrar un ejemplo de configuración de nginx en las siguientes líneas.

server {
    listen [::]:80;
    server_name .redacted.com;
    return 301 https://redacted.com$request_uri;
}

server {
    listen [::]:443 ssl http2;
    server_name redacted.com;
    access_log /var/www/log/access/redacted.access.log main buffer=32k;
    error_log /var/www/log/error/redacted.com.error.log notice;
    limit_conn gulag 200;
    root /var/www/web/redacted.com/web;
    index index.php;

    ssl_certificate /etc/letsencrypt/live/redacted.com/fullchain.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/redacted.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/redacted.com/privkey.pem;
    include ssl_params;

    ## Standard site protection
    include	snippets/standard.conf;

    location ~ /\\.well-known {
        auth_basic off;
        root /etc/letsencrypt;
        allow all;
    }

    ## Deny illegal Host headers
    if ($host !~* ^(redacted.com|redacted.com)$ ) {
        return 444;
        break;
    }

    ## Drupal configuration
    include snippets/drupal7-php7.4.conf;

    ## php handling
    include snippets/php7.4.conf;
}

Por cierto, podemos ver códigos HTTP 200 en los registros de nginx para los archivos acme durante la renovación de certbot.

2

Creo que obtendrías mejor ayuda en un foro de nginx o Let’s Encrypt. Esto no es realmente una pregunta de Discourse.