Serving port 443 over http creates 400 Bad Request Error instead of redirect

Question

So for posterity sake, I am trying to configure my server so that even when someone tries to go to go to http:// domain.com:443, they would be correctly redirected to the https version of the site (https:// domain.com).

When testing something like http:// domain.com:443, it does not redirect correctly to https:// domain.com, I instead get hit with a 400 Bad Request page with the following content:

Bad Request

Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please.

Apache/2.4.18 (Ubuntu) Server at sub.domain.com Port 443

I tried including the following lines in my 000-default.conf in the <VirtualHost *:80>:

RewriteEngine On 
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{SERVER_NAME}/$1 [R,L]

But it didn't work.

This issue occurs on all domains, subdomains and the server IP itself.

Possibly related, trying to do a dry run of letsencrypt returns the following:

   Domain: domain.com
   Type:   connection
   Detail: Failed to connect to 123.123.123.123:443 for TLS-SNI-01
   challenge

For each and every domain listed in the sites-enabled folder.

score 14 · Accepted Answer · answered Sep 18 '16 at 03:56

14

TL;TR: you cannot serve both HTTP and HTTPS on the same port (443).

While it would be in theory possible to figure out based on the first data from the client if the client is sending a HTTP request (i.e. GET .. or similar) or is starting a TLS handshake (\x16\x03...) most web servers don't do this. Instead they expect the client to behave properly, that is use plain HTTP on one port (usually 80) and HTTPS on another port (usually 443).

Your URL of http://example.com:443 is causing the browser to make a plain HTTP request to port 443. But the server is expecting TLS there which means that your plain HTTP request is unexpected. Apache is at least nice enough to check if the incoming data for a plain HTTP request in this case so that it can offer you a more useful description:

Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please.

If you try such requests with other servers then they would either close the connection without any error at all or just hang because they are still hoping to get a TLS handshake from the client.

answered Sep 18 '16 at 03:56

Steffen Ullrich

13,227
27
39

3

Thanks for the information. Though- I understand the difference, I'm not trying to server :443 over http, I'm trying to force a redirect when the user tries to invoke 443 on a http url. EDIT: The reason I am even trying to do this is because I've seen other web hosts handle these weird connections properly. – Bitz Sep 18 '16 at 04:58
nginx also returns a 400 Bad Request error, stating: "The plain HTTP request was sent to HTTPS port" – Michael Hampton Sep 18 '16 at 04:58
Is there any way to maybe even throw a 301 up instead of the 400 error? I know it's probably a bit hacky... But I still want to mitigate the issue. – Bitz Sep 18 '16 at 05:04
@Bitz Why do you want to do this?! – Michael Hampton Sep 18 '16 at 05:06
Because it seems pretty standard. Most websites I tested this on worked fine and I want to be able to measure to up that, I guess, haha. (And I'm sure those who come across this page in a year or two would want an answer) – Bitz Sep 18 '16 at 05:13
@Bitz: " I'm not trying to server :443 over http, I'm trying to force a redirect when the user tries to invoke 443 on a http url. " - A redirect is done with HTTP. Sou you want to serve your own HTTP response if the client accesses HTTP on the HTTPS port and that's exactly what the server will not allow you. – Steffen Ullrich Sep 18 '16 at 07:13
@Bitz: "..Because it seems pretty standard. Most websites I tested this on worked fine..": I don't know what you've tried but: google.com and facebook.com just close the connection (don't try with a browser, because of HSTS they will only use https for these sites), arstechnica.com and baidu.com give error 400, microsoft.com and outlook.com hang and yandex.com interestingly returns a 200 response. None of these returns a 301. Thus 301 does not look like a standard behavior at all for me. – Steffen Ullrich Sep 18 '16 at 07:22
@Bitz this is something nginx will let you do, see https://serverfault.com/questions/338700/redirect-http-example-com12345-to-https-example-com12345-in-nginx (they defined an internal response code 497 you can catch to redirect the user) I arrived here trying to know if Apache can do the same, the answer seems to be no according to your exchanges, even though it knows it's this situation. – u91317 Apr 02 '20 at 16:20

score 7 · Answer 2 · answered Feb 08 '19 at 06:52

I had this same error and the culprit was that my config was trying to enable SSL on my non-ssl port. Any website address that starts with http:// will be funneled through port 80 (<VirtualHost *:80>) and that host doesn't want to know anything about SSL. Any sites that start with https:// will be funneled through port 443 (<VirtualHost *:443>)

The more direct issue was that I had the following SSL details under my *:80 host, which was making Apache try to enable SSL for a non-SSL connection.

SSLEngine on
SSLCertificateFile /bla.crt
SSLCertificateKeyFile /bla.key
SSLCertificateChainFile /bla.crt

After removing those lines from *:80 (and making sure they were present under <VirtualHost *:443>) My server popped back up again.

So, here are my <VirtualHost>s (all in /etc/apache2/sites-available/http.conf but might be different depending on your setup):

<VirtualHost *:80>

    -- snip --

    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

</VirtualHost>


<VirtualHost *:443>

    -- snip --

    SSLEngine on
    SSLCertificateFile /var/www/ssl/STAR_iconcierge_net_au.crt
    SSLCertificateKeyFile /var/www/ssl/STAR_iconcierge_net_au.key
    SSLCertificateChainFile /var/www/ssl/STAR_iconcierge_net_au.crt

</VirtualHost>

Notice how *:80 (http) enacts a rewrite to *:443 (https), which then enforces SSL with the SSLEngine on directive.

Removing the first 4 lines worked for me. – Philippe Delteil Sep 10 '19 at 23:00 — Philippe Delteil, Sep 10 '19 at 23:00

score 3 · Answer 3 · answered Sep 21 '16 at 09:36

What you are actually looking after is sending HSTS headers from the webserver back to the users, which tell the browser always to access the site using TLS. There isn't any 301 redirect happening there, as you can see from the development tools in any browser.

This happens with Google for example. Once you have visited Google the first time, it sent you a HSTS header, and your browser saved the header to a list. After, when you try to connect to google.com with http://, the browser changes the connection method automatically to https:// without any communication to the remote webserver.

This is one further security mechanism to prevent attacks on the security layer.

score 2 · Answer 4 · answered Jul 29 '20 at 17:11

I had the same problem and I strugle around the world try to solve it and finally I could make my problem solved by using this way:

<VirtualHost *:443>
    ErrorDocument 400 "https://example.com/?error-bad-request"
</VirtualHost>

This will redirect your request http://example.com:443 to https://example.com/?error-bad-request

Hope this works with you.

score 0 · Answer 5 · answered Jun 15 '23 at 17:54

0

My http/apache configuration was

<VirtualHost *>

I changed it to

<VirtualHost *:80>

And the problem went away....

answered Jun 15 '23 at 17:54

Andrés Chandía

101
3

score 0 · Answer 6 · answered Sep 17 '16 at 23:21

0

Nothing that is inside the <VirtualHost *:80> section will be processed when you access the site using the port 443.

Test enabling the ssl version of the default site that come with apache2 and try that conf there inside <VirtualHost *:443>

answered Sep 17 '16 at 23:21

I tried dropping the Rewrite lines I mentioned before into the `default-ssl.conf` file and ensured the sl in _sites-enabled_ pointed to the conf. Restarted apache and sadly, no changes. – Bitz Sep 17 '16 at 23:26
And you said that worked with named vhosts but not with the default unnamed vhost? Could you show the result of `ls -la site-enabled` – Sep 17 '16 at 23:34
I thought that it was working for domains, but it seems like I was wrong and I tested it incorrectly, so the issue where http:/*:443 traffic isn't being transferred to https:// is universal for apache. Also, here are the results of the command ls -la sites-enabled: http://i.imgur.com/UeFsWOB.png – Bitz Sep 17 '16 at 23:49

score -1 · Answer 7 · answered Feb 15 '19 at 07:57

-1

In my experience i just deleted code in apache2.conf

<IfModule mod_ssl.c>
#Listen 443
</IfModule>

and httpd-vhosts.conf first entry custom settings . restarted and worked

answered Feb 15 '19 at 07:57

KAKHA13

101
1

This just the SSL listener at all. – bjoster Feb 15 '19 at 11:15

Serving port 443 over http creates 400 Bad Request Error instead of redirect

7 Answers7

Linked