Certbot certificate renewal failure

Help
22

I think I found the issue.

In the documentation that @MikeMcQ shared it says:

For example if a domain name has an AAAA record that always times out and an A record with a webserver that redirects from HTTP to HTTPS then the IPv6 to IPv4 fallback will not operate correctly. The first request to the domain will properly fallback to IPv4, receiving a redirect from HTTP to HTTPS. The subsequent request will again prefer the IPv6 address but will timeout without falling back to IPv4. You can resolve this situation either by fixing the IPv6 misconfiguration or removing the HTTP to HTTPS redirect for requests to the ACME HTTP-01 challenge path

So I changed one of the sites configuration for 80 block like this

# HTTP server block
server {
    listen [::]:80;
    server_name .abs.skvare.com;

    # Location block for .well-known
    location ~ /\.well-known {
        auth_basic off;
        root /etc/letsencrypt;
        allow all;
        # No redirect for .well-known
    }

    # Redirect all other requests to HTTPS
    location / {
        return 301 https://abs.skvare.com$request_uri;
    }
}

And tried certbot renew --dry-run again. It didnt fail for abs.skvare.com but other sites still fails so I believe issue is related with redirection. I'm going to modify all sites and test again.

1 Like
23

If you're bypassing the redirection and it's working, there still probably is failing IPv6 connectivity (successful certificate due to the IPv4 fallback on only the first attempt, as explained by Mike, but the IPv6 issue would remain). So even if you're successful in getting a certificate, your IPv6 connectivity would still be down, leading either to lag or even an inaccessible website for IPv6 enabled users.

2 Likes
24

Yeah you are right. This is only a bypass but since we have the rules and cannot see any dropped packets in the logs I dont know what causes this issue tbh.

2 Likes
25

You probably just need to look harder.

If it doesn't work with your default policy set to DROP and it suddenly does work when you set it to ACCEPT, what else could it be than ip6tables? I'm not very good with iptables, so I too am not sure what's wrong with your rules, but if I were a betting man (which I'm not), I'd go all-in on iptables anyway.

Note that ip6tables -L INPUT -v should show you counters. I don't know how many visitors your host receives, but maybe you can see which counter increases per attempt. If the -A INPUT -p tcp --dport 80 -j ACCEPT rules are actually used, that counter should increment per (first) packet.

2 Likes
26

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