Cannot reissue certificates unless HTTPS redirect is first switched off

Help
21

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
22

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
23

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
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: 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 0.0.0.0:80              0.0.0.0:*               LISTEN      2138/nginx: master  
tcp        0      0 0.0.0.0:443             0.0.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
root@raspberrypi:/etc/nginx#

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.

2 Likes
24

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
25

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

2 Likes
26

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
27

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

2 Likes
28

On the bright side, aside from lacking a canonical URL, I see from redirect-checker.org that grahamjones.co.uk and www.grahamjones.co.uk 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
29

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

This:

http://www.grahamjones.co.uk/well-known/acme-challenge/best

redirects to this:

https://www.grahamjones.co.uk/2013/newswire/social-media-news/best-brands-on-twitter.html

But this:

http://www.grahamjones.co.uk/well-known/acme-challenge/value

redirects to this:

https://www.grahamjones.co.uk/2010/newswire/social-media-news/valued-opinions-highlights-use-of-social-media-in-online-market-research.html

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

2 Likes
30

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.

2 Likes
31

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
32

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
33

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