Cannot reissue certificates unless HTTPS redirect is first switched off

This is confusing to say the least...!

If I disable the firewall for the server and for plesk, the connection problem persists.

I have restarted the server and all services, but the connection problem persists...!

No matter what changes I make, with the firewall on or off, the problem is always the same. Renewals are ONLY possible if the HTTPS redirect is switched off first.

It is persistent and applies to every domain, whether they are WordPress or not.

It happens with the firewalls off as well.

As I have said previously, this has only started happening in recent weeks. Everything worked perfectly OK before - for ages.

Plesk has been updated, so has the Let's Encrypt extension. Could there be something going on there? But if that were the case I wouldn't be the only person with a problem...!

My detective work continues...

1 Like

I feel like the hypothesis in my previous post might hold sway. I believe that having no (functional) vHost (and no default, functional vHost) can appear to be a firewall problem. Correct me if I'm wrong here, @Osiris.

1 Like

Well, never say never and it's never "always" (at least in my field of work), but default Linux boxes won't drop packets out of the blue. For example:

osiris@erazer ~ $ telnet localhost 12345
Trying ::1...
telnet: connect to address ::1: Connection refused
telnet: connect to address Connection refused
osiris@erazer ~ $ 

Because there isn't a service listening. Which would also be the case if nginx would only contain a listen 443. For example, if I comment out my IPv6 listen part:

        listen 443 ssl http2;
        #listen [::]:443 ssl http2;

I see my nginx doesn't listen on port 443 any longer:

tcp        0      0    *               LISTEN      2138/nginx: master  
tcp        0      0   *               LISTEN      2138/nginx: master  
tcp6       0      0 :::80                   :::*                    LISTEN      2138/nginx: master  

(It did before.)

However, when I try to telnet to it:

root@raspberrypi:/etc/nginx# telnet -6 localhost 443
Trying ::1...
telnet: Unable to connect to remote host: Connection refused

And not a timeout.

Note that such things could also be due to missing portmaps in NAT routers. But that's also an external thing compared to the webserver itself.


What about if it's listening, but there's no default vHost functioning to answer for a certain host? I'm thinking maybe the port 80 vHost is being borked when the redirect is turned on.

1 Like

I don't know, but I'm thinking not a timeout, but some kind of HTTP error number.


I would hope. I (vaguely) recall you and I being involved with some other topics in the past where similar shenanigans have occurred. I just can't recall the outcomes (or the specific topics).

1 Like

Strange things are always possible :wink: That's why I almost exclusively use "mostly", "usually" and more of those terms :wink:


On the bright side, aside from lacking a canonical URL, I see from that and appear to be redirecting normally now. Strangely, the base URLs redirect properly, but /.well-known/acme-challenge/test redirects to the wrong target.

1 Like

I did some more research. This is very interesting...


redirects to this:

But this:

redirects to this:

The missing "." before well-known is intentional.


Hm, interesting indeed!

Looks like some kind of plugin which filters out requests which would otherwise not work and redirects them to some "best match" kinda thing.


Unfortunately, it's also "fulfilling" requests for certain "words" (where others return 404) even if actual content exists (challenge files) matching the requests.

1 Like

This is very kind of you to keep thinking about this issue. It is a conundrum. As I have said, the problems persist - even if the firewall is OFF. The odd redirects for random words also exist if all WordPress plugins are deactivated and I go to a basic theme. But that specific behaviour does NOT happen on other sites on the same server, even sites with the same set of WordPress plugins (though the HTTPS redirect needing to be OFF does remain).

1 Like