0

Background

I have an Ubuntu 16.04 server running Apache/2.4.18 (Ubuntu). I installed lets-encrypt from github and ran ./letsencrypt-auto --apache, choosing the second option from the following dialog:

Please choose whether HTTPS access is required or optional.
------------------------------------------------------------------
1: Easy - Allow both HTTP and HTTPS access to these sites
2: Secure - Make all requests redirect to secure HTTPS access
------------------------------------------------------------------

which resulted in the message

Congratulations! You have successfully enabled
my.own.server.tld

and an auto-generate virtual host file. Then I restarted the server.

The Problem

I tried to access my site, which worked with http (no problems), but not with https (Firefox and Chrome tried to load the page and timed out after two minutes). I expected the site to be available exclusively via https, or at least via https at all.

Configuration

There is only one file in /etc/apache2/sites-enabled/:
my.own.server.tld-le-ssl.conf

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerName my.own.server.tld

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html

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

        SSLCertificateFile /etc/letsencrypt/live/my.own.server.tld/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/my.own.server.tld/privkey.pem
        Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

where /etc/letsencrypt/options-ssl-apache.conf was also auto-generate by lets-encrypt and looks like

SSLEngine on

# Intermediate configuration, tweak to your needs
SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:...
SSLHonorCipherOrder     on
SSLCompression          off

SSLOptions +StrictRequire

# Add vhost name to log entries:
LogFormat "..." vhost_combined
LogFormat "..." vhost_common

The ... parts are not literally in the file – I just omitted these parts to make this question more readable.

What I Tried

  • Reloading/Restarting apache.
  • Restarting the complete server.
  • a2enmod ssl (prints Module ssl already enabled).
  • Writing <Directory /> SSLRequireSSL </Directory> inside the VirtualHost configuration. (Did not change anything. Website was still accessible using http, but not accessible using https.)
  • Writing SSLRequireSSL into /var/www/html/.htaccess. (Did not change anything. Website was still accessible using http, but not accessible using https.)

Additional Information

The server my.own.server.tld is running at my university. I only control the my part and have neither knowledge nor control over the underlying system, but I guess my server is an OpenStack instance. The server should have just one IP.

apache2ctl -S prints

VirtualHost configuration:
*:443                  my.own.server.tld (/etc/apache2/sites-enabled/my.own.server.tld-le-sll.conf:2)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/lock/apache2" mechanism=fcntl 
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33

netstat -pant | grep apache2 prints

tcp6    0    0 :::80     :::*    LISTEN    8592/apache2    
tcp6    0    0 :::443    :::*    LISTEN    8592/apache2 

netstat -l46n prints

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp        0      0 0.0.0.0:22    0.0.0.0:*       LISTEN
tcp6       0      0 :::80         :::*            LISTEN
tcp6       0      0 :::22         :::*            LISTEN
tcp6       0      0 :::443        :::*            LISTEN
udp        0      0 0.0.0.0:68    0.0.0.0:*

telnet localhost 443 prints the expected output.

iptables -L -n prints

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
f2b-sshd   tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain f2b-sshd (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            0.0.0.0/0   

There are no errors in /var/log/apache2/error.log.

2
  • Did https ever work before or stopped working once you switched to Let's Encrypt?
  • Is your server an Amazon EC2 instance? (Potential issue with security groups)
  • This similar question gives some ideas worth trying Why is https not working?:

Try connecting to the https port via telnet to see if it is reachable from the server itself. It should look like the following:

    $ telnet localhost 443
    Trying 127.0.0.1...
    Connected to localhost.localdomain (127.0.0.1).
    Escape character is '^]'.
  • What do your firewall rules look like? (iptables -L -n)
  • Is the https virtualhost pointing to the same folder as the http one? (Permission issue)
  • Anything in the in the apache error log? (/var/logs/apache2/error.log by default)
  • Does your server have multiple IPs configured?
  • Run netstat -pant | grep apache2 to see if apache is listening on port 80 and 443

By the way: If you want users to access your site only via https you need to configure something like this in the http Virtualhost to redirect them to https:

<VirtualHost *:80>
        ServerName my.own.server.tld
        ServerAlias www.my.own.server.tld
        RewriteEngine On
        RewriteCond %{SERVER_PORT} !443
        RewriteRule ^(/(.*))?$ https://%{HTTP_HOST}/$1 [R=301,L]
        RewriteCond %{SERVER_NAME} =www.my.own.server.tld
        RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
</VirtualHost>
  • Thank you for your answer. I updated the question with the wanted information. Regarding the question »Is the https virtualhost pointing to the same folder as the http one?«: There is only one virtualhost (https). The paths and permissions seem to be right. – Socowi Apr 23 '17 at 22:16
  • Time to dig deeper. Try running openssl s_client -connect my.own.server.tld:443 from your PC (If you got OpenSSL downloaded / installed) to see if the SSL handshake works or gives any clues. Try a portscan from your PC to see if port 443 is reachable (If allowed by your university). Alternatively try with telnet (or putty) to reach port 443. You could also capture the network traffic with Wireshark / Netmon to look for clues. – adiuva Apr 23 '17 at 22:29
  • 1
    openssl also times out. A port scan with nmap shows that only port 22 (ssh) and 80 (http) are opened. I try to contact the person in charge and ask if they block port 443. – Socowi Apr 23 '17 at 22:43
  • Thanks to your comments I found out, that the hoster blocked port 443. I contacted the hoster and asked him to open port 443. Now everything works. – Socowi Apr 24 '17 at 13:02
1

I got my cert w/ LE via the certonly option. Then modify your apache site definition to be:

<VirtualHost _DEFAULT_:443>
    ServerName example.com
    ServerAlias www.example.com
    ServerAdmin webmaster@example.com
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
    CustomLog ${APACHE_LOG_DIR}/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
    DocumentRoot /var/www-example.com
    <directory /var/www-example.com>
        Options All
                AllowOverride All
                Require all granted
    </directory>
    ErrorLog ${APACHE_LOG_DIR}/ssl-example.com-error.log
    CustomLog ${APACHE_LOG_DIR}/ssl-example.com-access.log combined
</VirtualHost>

Then enable SSL in apache - a2enmod ssl - and then restart apache2.

The output of apache2ctl -S you show looks like it is correct - if you (re)start apache2 does it show as listening if you look via netstat -l46n ?

  • Thank you for the answer. I copied your config, adapted the paths and domains, enabled mod_ssl (which was already enabled) and restartet the server. Sadly nothing did change. service apache2 restart does not print anything – it just restarts the server. – Socowi Apr 23 '17 at 22:24
  • What is output of netstat -l46n ? Do you see 443 listed? – ivanivan Apr 23 '17 at 22:46
  • The question was edited to include the output of netstat -l46n (So far I thought netstat -pant | grep apache2 already gave the required information). Port 443 is listed. – Socowi Apr 24 '17 at 6:42
0
SSLCertificateFile /etc/letsencrypt/live/my.own.server.tld/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/my.own.server.tld/privkey.pem

The pem file is just a container file and is not a certificate in itself. You will need a CRT file.

  • Thank you for your answer. Are you sure that I have to use a CRT file? It seemed like ivanivan had no problems using the PEM files on his server; lets-enrypts's auto-generated config worked for me on another server; and the official manual says to use the PEM files. Which files should I convert to CRT, fullchain and privkey or just one of them? – Socowi Apr 24 '17 at 11:49
  • Thats the way I have used SSL with apache. I usually generate a CSR (Certificate Signing Request) then generate the CRT (Certificate). Never used a PEM file or KEY file to establish SSL. – sridhar pandurangiah Apr 24 '17 at 11:56
  • Convert the fullchain.pem that is likely to contain the chain of certificates from the ROOT Certificate. – sridhar pandurangiah Apr 24 '17 at 11:59
  • I checked the Apache documentation. Your configuration seems right. Just wondering if you are using a version of apache that supports those directives. You should be on Apache 2.4.8 – sridhar pandurangiah Apr 24 '17 at 12:57
  • I'm using the Ubuntu version of Apache 2.4.18, as stated in the question. The problem is now resolved. Thank you for your inputs. – Socowi Apr 24 '17 at 13:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.