Why is https not working?

Question

I am trying to redirect just the root of my site to https. Although the rewrite happens, https does not yield anything. The browser says. connecting to thinkingmonkey.me... and stagnates.

Listen 80 & Listen 443 are present in the conf file.

I have restarted httpd.

I am using the proper certificate file & private key file.

No errors are present in the httpd logs, SSL logs (Ihave a separate log for SSl).

Literally nothing has been logged into SSL-access log even if I try to access the https://thinkingmonkey.me directly.

A netstat -pant | grep httpd has this:

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name  
tcp        0      0 :::443                      :::*                        LISTEN      1334/httpd          
tcp        0      0 :::80                       :::*                        LISTEN      1334/httpd

.htaccess:

RewriteEngine on
RewriteBase /

RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} ^/$
RewriteRule ^(.*)$ https://thinkingmonkey.me [L,R=302]

rewritelog data:

my-ip - - [24/Jan/2012:19:01:14 +0000] [thinkingmonkey.me/sid#7fa2335ceb18][rid#7fa2339336d8/initial] (2) init rewrite engine with requested uri /

my-ip - - [24/Jan/2012:19:01:14 +0000] [thinkingmonkey.me/sid#7fa2335ceb18][rid#7fa2339336d8/initial] (1) pass through /

my-ip - - [24/Jan/2012:19:01:14 +0000] [thinkingmonkey.me/sid#7fa2335ceb18][rid#7fa2339336d8/initial] (3) [perdir /mysite/] strip per-dir prefix: /mysite/ ->

my-ip - - [24/Jan/2012:19:01:14 +0000] [thinkingmonkey.me/sid#7fa2335ceb18][rid#7fa2339336d8/initial] (3) [perdir /mysite/] applying pattern '^(.*)$' to uri ''

my-ip - - [24/Jan/2012:19:01:14 +0000] [thinkingmonkey.me/sid#7fa2335ceb18][rid#7fa2339336d8/initial] (4) [perdir /mysite/] RewriteCond: input='80' pattern='80' => matched

my-ip - - [24/Jan/2012:19:01:14 +0000] [thinkingmonkey.me/sid#7fa2335ceb18][rid#7fa2339336d8/initial] (4) [perdir /mysite/] RewriteCond: input='/' pattern='^/$' => matched

my-ip - - [24/Jan/2012:19:01:14 +0000] [thinkingmonkey.me/sid#7fa2335ceb18][rid#7fa2339336d8/initial] (2) [perdir /mysite/] rewrite '' -> 'https://thinkingmonkey.me'

my-ip - - [24/Jan/2012:19:01:14 +0000] [thinkingmonkey.me/sid#7fa2335ceb18][rid#7fa2339336d8/initial] (2) [perdir /mysite/] explicitly forcing redirect with https://thinkingmonkey.me

my-ip - - [24/Jan/2012:19:01:14 +0000] [thinkingmonkey.me/sid#7fa2335ceb18][rid#7fa2339336d8/initial] (1) [perdir /mysite/] escaping https://thinkingmonkey.me for redirect

my-ip - - [24/Jan/2012:19:01:14 +0000] [thinkingmonkey.me/sid#7fa2335ceb18][rid#7fa2339336d8/initial] (1) [perdir /mysite/] redirect to https://thinkingmonkey.me [REDIRECT/302]

Here are my Virtual Hosts.

<VirtualHost *:80>
     ServerName thinkingmonkey.com
     ServerAlias www.thinkingmonkey.com  www.thinkingmonkey.me

     RewriteEngine on
     RewriteCond %{HTTP_HOST} ^(www\.)?thinkingmonkey\.(com|me)$ [NC]
     RewriteRule ^ http://thinkingmonkey.me%{REQUEST_URI} [L,R=301]
</VirtualHost>

<VirtualHost *:80>
    ServerAdmin webmaster@dummy-host.example.com
    DocumentRoot /mysite/
    ServerName thinkingmonkey.me
    ErrorLog logs/site-error_log
    CustomLog logs/site-access_log common
    RewriteEngine On
    RewriteLog "/var/log/rewrite.log"
    RewriteLogLevel 3
</VirtualHost>

<VirtualHost *:443>

ServerName thinkingmonkey.me

ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

SSLEngine on

SSLProtocol all -SSLv2

SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW


SSLCertificateFile /path/to/my.crt
SSLCertificateKeyFile /path/to/my.key
SSLCertificateChainFile /path/to/my.ca-bundle


<Files ~ "\.(cgi|shtml|phtml|php3?)$">
    SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>
SetEnvIf User-Agent ".*MSIE.*" \
     nokeepalive ssl-unclean-shutdown \
     downgrade-1.0 force-response-1.0

CustomLog logs/ssl_request_log \
      "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

</VirtualHost>

lsof -i -P | grep 443
httpd    1334     root    6u  IPv6   3297      0t0  TCP *:443 (LISTEN)
httpd    1335   apache    6u  IPv6   3297      0t0  TCP *:443 (LISTEN)
httpd    1336   apache    6u  IPv6   3297      0t0  TCP *:443 (LISTEN)
httpd    1337   apache    6u  IPv6   3297      0t0  TCP *:443 (LISTEN)
httpd    1338   apache    6u  IPv6   3297      0t0  TCP *:443 (LISTEN)
httpd    1339   apache    6u  IPv6   3297      0t0  TCP *:443 (LISTEN)
httpd    1340   apache    6u  IPv6   3297      0t0  TCP *:443 (LISTEN)
httpd    1341   apache    6u  IPv6   3297      0t0  TCP *:443 (LISTEN)
httpd    1342   apache    6u  IPv6   3297      0t0  TCP *:443 (LISTEN)

What is going wrong here?

As was discussed in the comments on your [previous question](http://serverfault.com/q/352903/72586), your SSL listener was binding only to `:::443` and not `0.0.0.0:443`. Is that still the case? What do you get from `lsof -i -P | grep 443`? — Shane Madden, Jan 24 '12 at 19:29
@ShaneMadden have updated with details: only ipv6 is being listened to. What do I have to do to change this? — ThinkingMonkey, Jan 24 '12 at 19:31
@ThinkingMonkey An error *should* be thrown when it fails to bind the IPv4 port. Try changing your `Listen 443` directive to `Listen 0.0.0.0:443` and restart - if it doesn't bind, then it will definitely throw an error. — Shane Madden, Jan 24 '12 at 19:35
@ShaneMadden no error is getting thrown! Checked the logs as well. — ThinkingMonkey, Jan 24 '12 at 19:39
@ThinkingMonkey You're right, my mistake - it's using mapped addresses, so only the IPv6 should show. You've got a separate error log set for your SSL host - is there anything of note in that log? — Shane Madden, Jan 24 '12 at 19:41
@ShaneMadden whether SSL logs is initiated during the startup, I changed the private-key file to a non-matching one. `ssl-error_log` does have a `mismatch` error now. — ThinkingMonkey, Jan 24 '12 at 19:51

cjc · Accepted Answer · 2012-01-24T20:03:43.260

16

OK, try this:

telnet localhost 443

Does that give a response, or does it hang? If it's responding, you should get something that looks like:

$ telnet localhost 443
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.

(if telnet is not installed, then install it; you can exit the telnet session by hitting control-] and then typing "q" to quit)

If you're able to connect to the web server on the local interface (and the web server is running, given your logs), then there is a firewall issue (I know you said you haven't set the firewall, but this will confirm). In that case, run:

iptables -L -n

and post the results.

Update

From comments, this is an EC2 instance, so look at the Security Groups associated with this instance. Make sure you're allowing tcp/443 in your Security Groups.

Something like this might help:

http://cloud-computing.learningtree.com/2010/09/24/understanding-amazon-ec2-security-groups-and-firewalls/

edited Jan 24 '12 at 20:03

answered Jan 24 '12 at 19:49

cjc

24,916
3
51
70

`TELNET` connects fine. `iptables -L -n` gives:| Chain INPUT (policy ACCEPT)| target| prot opt source| destination| Chain FORWARD (policy ACCEPT)| target| prot opt source| destination| Chain OUTPUT (policy ACCEPT)| target| prot opt source| destination| – ThinkingMonkey Jan 24 '12 at 19:55
Is there another firewall that's managed by your provider? Since everything you've shown in this post and the previous one shows that Apache is running correctly and listening on 443, and that there's no local firewall. – cjc Jan 24 '12 at 19:57
I am using Amazon's ec2 instance. I don't think another firewall is installed. – ThinkingMonkey Jan 24 '12 at 20:00
1

Oh, you're using EC2. In that case, check the Security Group. Yes, there's another firewall; Amazon calls it Security Groups. make sure the assigned Security Groups for that instance allows traffic on 443. – cjc Jan 24 '12 at 20:01
looking into `AWS Management Console` – ThinkingMonkey Jan 24 '12 at 20:06
Yes, you are right! I had not added `HTTPS` into the security group I was using for the instance. Thanks! Its working fine now. – ThinkingMonkey Jan 24 '12 at 20:19
Yes, I have been working on this for about 3 hours now. Thanks ThiningMonkey, thanks cjc. – Adam Waite Oct 28 '12 at 14:53
@ThinkingMonkeyI have the same issue. TELNET works fine and ec2 security groups are all set for ports 80 and 443 but I still can't reach my IP address through https. Any suggestion for me? – Fariman Kashani May 01 '21 at 12:44

score 2 · Answer 2 · answered Jan 24 '12 at 19:54

On dual-stack hosts, listening to ::443 means you're listening both on IPv4 and IPv6. Test the TLS negotiation yourself:

openssl s_client -connect localhost:443
[lots of negotiation output, to ensure the basics are there]

Then you'll be able to test if HTTP replies:

GET / HTTP/1.0

Here's how I'd redirect:

<VirtualHost *:80>
    ServerName mail.example.com

    RewriteEngine On
    RewriteLog /var/log/apache2/rewrite.log
    RewriteLogLevel 4
    RewriteRule ^(.*)$ https://secure.example.com/mail$1 [R,L]
</VirtualHost>

Please remove RewriteLog and RewriteLogLevel in production, or risk getting a disk filled senselessly.

`RewriteLog` and `RewriteLogLevel` are just for my debugging. It will be removed when site goes live. `openssl s_client -connect localhost:443` said `CONNECTED(00000003)` ... `SSL handshake has read 5857 bytes and written 311 bytes` under `New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA` at the end: `Verify return code: 0 (ok)` — ThinkingMonkey, Jan 24 '12 at 20:04

score 2 · Answer 3 · edited Jul 20 '16 at 23:53

Similar issue, apache2 was responding to 443, nothing in the logs

/etc/apache2# openssl s_client -connect localhost:443 -state -debug

gave me the following

SSL_connect:unknown state
read from 0x1182fe0 [0x1189010] (7 bytes => 7 (0x7))
0000 - 48 54 54 50 2f 31 2e                              HTTP/1.
SSL_connect:error in unknown state
139790287365792:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:795:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 295 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE

the issue was that my.domain.com is a different ip than was configured in the virtual hosts. As server uses 2 IPs. so apache was answering on 443, but could not connect a website to the connection. matched the IP all is good

score 1 · Answer 4 · edited Aug 30 '12 at 05:46

1

Open httpd.conf and see if the line below is present:

LoadModule ssl_module modules/mod_ssl.so

If not then update the httpd.conf with this and restart Apache.

edited Aug 30 '12 at 05:46

Kenny Rasschaert

9,045
3
42
58

answered Aug 29 '12 at 23:57

navin

31
1

1

I solved my problem with `sudo a2enmod ssl`. Thank you. – Jin Kwon Dec 30 '15 at 16:44

score 0 · Answer 5 · answered Jul 29 '16 at 10:14

It's worth double checking what sort of SSL policy your provider is offering. After tons of debugging, I found my problem to be caused by my hosting provider locking down port 443 externally until I paid them for an SSL cert. I had been planning to use LetsEncrypt, but I'll have to switch hosts before I can do that. Anyway, if none of the other solutions help and you're in a VPS environment (or any environment where you might have less control over your network), it might be worth double checking this.

score 0 · Answer 6 · answered Dec 04 '18 at 16:29

0

If the SSL keys are not set (or were inexplicably commented out by gremlins), Apache 2.2 SSL will silently fail. There will be no error in the log, and it will not be listening to 443. The http:80 sites will work.

answered Dec 04 '18 at 16:29

user3062014

1

Why is https not working?

6 Answers6

Linked