0

I have a problem with my Apache 2.4.18 server while using ssl encryption. My server setup is: the apache server redirects everything on port 80 (http) to port 443 (ssl), this I realized with different site configuration.

And now my problem is: if I open the link https://www.example.com, I get the website I want.

But if I open https://example.com, I get the error: ERR_CONNECTION_REFUSED

Why is that so, and how can I solve it?

Virtualhost file for ssl:

<IfModule mod_ssl.c>
    <VirtualHost *:443>
            ServerAdmin [email protected]

            DocumentRoot /var/www/html



            ErrorLog ${APACHE_LOG_DIR}/error.log
            CustomLog ${APACHE_LOG_DIR}/access.log combined


            #   SSLCertificateFile directive is needed.
            SSLCertificateFile /etc/letsencrypt/live/footprintgaming.de/fullchain.pem
            SSLCertificateKeyFile /etc/letsencrypt/live/footprintgaming.de/privkey.pem



            #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
            <FilesMatch "\.(cgi|shtml|phtml|php)$">
                            SSLOptions +StdEnvVars
            </FilesMatch>
            <Directory /usr/lib/cgi-bin>
                            SSLOptions +StdEnvVars
            </Directory>


     </VirtualHost>
 </IfModule>

  # vim: syntax=apache ts=4 sw=4 sts=4 
4
  • Please show your configuration. Aug 24, 2017 at 15:44
  • which of all those configurations?
    – MelcomX
    Aug 24, 2017 at 16:26
  • Configuration for example.com. I think it would be vhost. Aug 24, 2017 at 16:27
  • @AlexanderTolkachev I hope you mean this...
    – MelcomX
    Aug 24, 2017 at 16:35

1 Answer 1

0

footprintgaming.de has an A record pointing to 89.31.143.1, which appears to live at AS15598.

www.footprintgaming.de ultimately resolves to 46.5.192.81, which appears to live at AS29562.

Neither seems to have any associated IPv6 address record.

"Connection refused" means that the TCP SYN was responded to with a TCP RST/ACK. This typically happens when there is no listening socket bound to the IP address and TCP port in question, but may also be caused by firewalling.

I am able to connect to both just fine on port 80.

I am able to connect to the latter just fine on port 443, but not the former. This matches your results.

Some things to check:

  • Is the Apache instance listening on port 443? netstat -an | grep 443 will be a start.
  • Are there any relevant firewall rules in place? Assuming a moderately modern Linux, start with iptables -L -n and go from there. Other OSes will be similar yet different.
  • Is the mod_ssl module actually loaded? Try apachectl -M (and see here).
  • Silly, but has been known to happen: Have you reloaded the Apache configuration after editing it? apachectl configtest and apachectl graceful should be your friends.
  • Where is the ServerName for that virtual host? Check your apachectl -S output too. (This would normally cause you to get the wrong content or in this case a wrong HTTPS certificate, not a connection refused error, but I am including it because you're probably going to run into that the second you get a TCP connection...)
4
  • Thank you very much for your answer. After all this points, I believe the problem isn't the server itself, it's the dns-architecture(a little bit special) in front of it. But Thank you again...
    – MelcomX
    Aug 24, 2017 at 20:24
  • 1
    In this setup your certificate is also not valid for footprintgaming.de because the certificate is only for www.footprintgaming.de (if without the www is not accessible than LetsEncrypt could not make the certificate include that name)
    – Lexib0y
    Aug 24, 2017 at 20:51
  • @Lexib0y's comment is the most correct one. The other answer here by Michael contains alot of unnecessary step to verify thing that already works. For example that apache is listening on port 443? Ofcourse it does because www.footprintgaming.de does actually work!
    – Orphans
    Aug 25, 2017 at 5:25
  • @Orphans "For example that apache is listening on port 443? Ofcourse it does because www.footprintgaming.de does actually work!" Please tell us how a server listening on one IP address and port necessarily implies that there is something listening on a different IP address but the same port, even on the same host. Right at the very top of my answer I mention that the two host names resolve to different IP addresses in different ASes. I do briefly discuss certificate validity, but I have yet to come across any system where using a wrong certificate causes the TCP connection to be refused.
    – user
    Aug 25, 2017 at 10:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .