Falha na renovação do certificado Certbot

Temos um problema com a renovação do SSL do certbot. Temos vários sites em /etc/nginx/sites-available/.

Temos este bloco de localização para o diretório .well-known

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

e temos configurações de renovação para cada site no diretório /etc/letsencrypt/renewal.
Este é um exemplo para um deles.

#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

Nossa versão do certbot é 2.7.4, atualizamos da 1.32.0 e também não funcionou.

Sabemos que nosso problema está relacionado com ip6tables, mas já temos regras ACCEPT para as portas 443 e 80.

Quando tentamos acessar os arquivos acme-challenge durante certbot renew --dry-run, conseguimos acessar os arquivos com sucesso. Portanto, as portas 80 e 443 não deveriam ser o problema.

Quando mudamos o filtro de entrada do ip6tables de DROP para ACCEPT, todos os sites conseguem renovar, mas quando usamos o filtro INPUT DROP, a maioria dos sites falha ao renovar com este erro.

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)

Já tentamos com o conjunto mínimo de regras e tentamos adicionar regras ACCEPT para as portas 80 e 443 no topo da cadeia de entrada, mas também não funcionou. Então estamos presos aqui.

Um exemplo de configuração do nginx pode ser encontrado nas linhas a seguir.

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;
}

A propósito, podemos ver códigos HTTP 200 nos logs do nginx para arquivos acme durante a renovação do certbot.

Acho que você obteria ajuda melhor em um fórum do nginx ou do let’s encrypt. Isso não é realmente uma pergunta do Discourse.