We have two sites, sub.example1.com and example2.com. Neither one is specifically configured to handle ssl requests. One site https:/sub.example1.com, handles a secure request to port 443 successfully by treating is as an http request. A secure request to the other site, https://example2.com, times out and logs a "\x16\x03\x01" error in hte apache log.
Here's the configuration for example1 in /etc/httpd/sites-enabled/
ServerAdmin webmaster@localhost ServerName sub.example1.com
DocumentRoot /opt/example1/web/
DirectoryIndex index.php index.html
<Directory />
Options FollowSymLinks
AllowOverride All
</Directory>
<Directory /opt/example/web/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
# This directive allows us to have apache2's default start page
# in /apache2-default/, but still have / go to the right place
#RedirectMatch ^/$ /apache2-default/
</Directory>
ErrorLog /var/log/httpd/errorExample1.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/httpd/accessExample1.log combined
ServerSignature On
~
The is no .htaccess file for example1.
Here's the configuration for example2 in /etc/httpd/sites-enabled/
<VirtualHost *:80>
ServerAdmin webmaster@localhost
ServerName www.example2.com
DocumentRoot /opt/example2/web
<Directory />
Options FollowSymLinks
AllowOverride All
</Directory>
<Directory /opt/example2/web/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
# This directive allows us to have apache2's default start page
# in /apache2-default/, but still have / go to the right place
#RedirectMatch ^/$ /apache2-default/
</Directory>
ErrorLog /var/log/httpd/errorExample2.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/httpd/accessExample2.log combined
ServerSignature On
Here's the .htaccess for example2
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
httpd.conf
UseCanonicalName Off
NameVirtualHost *:80
# NameVirtualHost *:443
# Include generic snippets of statements
Include conf.d/*.conf
# Include the virtual host configurations:
Include /etc/httpd/sites-enabled/
conf.d/*.conf entries:
TraceEnable On
serverName.conf
ServerName ec2-xx-xx-xx-xxx.compute-1.amazonaws.com
welcome.conf
<LocationMatch "^/+$">
Options -Indexes
ErrorDocument 403 /error/noindex.html
</LocationMatch>
I can't figure out why one translates an https request to http, and the other one doesn't. Any help appreciated.
In this case neither one should be listen at the port 443 at all, i.e. the browser should not be even able to connect to this port. Since you get responses or error messages the browser is obviously able to connect to this port so something is obviously setup to deal with this port. But it might not be setup properly on the second server.
Unlikely because the client is sending a HTTPS request. If no SSL was there (i.e. plain HTTP) the SSL handshake from the client would fail and it would not be able to do the inner HTTP request. While you don't give full details of the setup it might still be that SSL is globally enabled on this server or that there is some reverse proxy in front doing SSL termination and forwarding the request as simple HTTP.
"\x16\x03\x01" are the first bytes of a SSL/TLS handshake. This means that the client is trying to speak HTTPS to the server, which is expected if you use a
https://
URL. And obviously the server is listening on the port where the clients sends the request too because otherwise the TCP connection would have already failed. With a normalhttps://host/
request the port would be 443 which means that your server would have to be explicitly setup to handle plain HTTP on port 443 (this does not happen by its own or in the default setup). Or you've actually tried the URLhttps://port:80/
and forced the browser to connect with HTTPS to the port reserved for plain HTTP.My guess that the problems are in the part of the server setup which you are not showing here.
you can add a .htaccess file to example 1
The example 2 looks like wordpress, there are wordpress plugins for http redirects - perhaps it's using that