0

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.

2 Answers 2

1

Neither one is specifically configured to handle ssl requests.

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.

One site https:/sub.example1.com, handles a secure request to port 443 successfully by treating is as an http request.

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.

logs a "\x16\x03\x01" error in hte apache log.

"\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 normal https://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 URL https://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.

1
  • I just realized why it was doing the translation. We have a load balancer set up on Amazon which contains the wildcard certificate from the "example1" domain. There is no such certificate for the example2 domain. However, now that you mention it, there is still one application set up in httpd which has port 443 configured. At the time it was set up, we didn't have the wildcard certs. If I reconfigure that to no longer listen on 443, then perhaps that will fix the problem. Apr 8, 2016 at 4:59
0

you can add a .htaccess file to example 1

RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

The example 2 looks like wordpress, there are wordpress plugins for http redirects - perhaps it's using that

You must log in to answer this question.

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