Apache: Client sent an HTTP request to an HTTPS server

Troubleshooting
1

Summary

I’ve had Mattermost configured with an Apache reverse proxy for a few weeks, so visiting https://mattermost.domain.tld resolved just fine. Mattermost is listening on port 9065. It seems that after enabling the API option in the Mattermost console somehow tripped up Mattermost. Even after disabling this option for a few days going to mattermost.domain.tld with https results in this message:

Client sent an HTTP request to an HTTPS server.

I cannot for the life of me figure out why this keeps happening. I have several other Apache VirtualHosts defined for other services using a reverse proxy without trouble, so I’m not sure anymore why Mattermost just won’t cooperate. I can visit mattermost.domain:9065 specifying the port with https, this does resolve fine. Up until the point it began giving the above client message my Apache config was not changed. I didn’t make any changes in Mattermost except for enabling then disabling an option related to the Mattermost API, but I don’t see how this would be causing this.

Steps to reproduce

Mattermost version 5.12.2
Apache version 2.4.39

Expected behavior

This is the original Apache config I have been using just fine with Mattermost by visiting only mattermost.domain.tld (https) without specifying port 9065, but now gives the client https message.

<VirtualHost *:80>
  ServerAdmin webmaster@domain
  ServerName mattermost.domain.tld
  ServerAlias mm.domain.tld
  Redirect permanent / mattermost.domain.tld <--https
</VirtualHost>

<VirtualHost *:443>
  ServerName mattermost.domain.tld
  ServerAlias mm.domain.tld
  ServerAdmin webmaster@domain
  ProxyPreserveHost On

  # Set web sockets
  RewriteEngine On
  RewriteCond %{REQUEST_URI} /api/v[0-9]+/(users/)?websocket [NC,OR]
  RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC,OR]
  RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
  RewriteRule .* ws://127.0.0.1:9065%{REQUEST_URI} [P,QSA,L]

  Redirect permanent / mm.domain.tld <---https://

  <Location />
        Require all granted
        ProxyPass 127.0.0.1:9065/  <--http
        ProxyPassReverse 127.0.0.1:9065/ <--http
        ProxyPassReverseCookieDomain 127.0.0.1 mm.domain.tld
  </Location>

  SSLEngine on
  SSLProtocol all -SSLv2 -SSLv3
  SSLCertificateFile "/etc/letsencrypt/live/domain.tld/cert.pem"
  SSLCertificateKeyFile "/etc/letsencrypt/live/domain.tld/privkey.pem"
  SSLCACertificateFile "/etc/letsencrypt/live/domain.tld/fullchain.pem"

</VirtualHost>

I have scrounged the Mattermost forums, GitHub and other similar Apache reverse proxy problems, but no matter how I configure Apache loading https://mattermost.domain.tld still results in the dreadful

Client sent an HTTP request to an HTTPS server.

Observed behavior

Checking the Mattermost logs doesn’t show any errors or messages that would indicate a problem with Mattermost. The Apache error logs don’t show any problem.

Since I am using an Apache reverse proxy I have also ensured UseLetsEncrypt and Forward80To443 are false.

Note that I have https before the domain below, but I can’t post more than 2 links.

"SiteURL": "mattermost.domain.tld",
"WebsocketURL": "",
"LicenseFileLocation": "",
"ListenAddress": ":9065",

The Mattermost directory /usr/share/webapps/mattermost is also owned by the mattermost user and group. Considering I didn’t change anything in Apache or Mattermost related to SSL/TLS options I am at a complete loss on how to fix this. I’ve tried restarting Mattermost and Apache for good measure and following the logs, but still nothing makes sense to me why I’m getting the Client sent an HTTP request to an HTTPS server message.

2

It looks like this is now resolved. So it seems that if you’re using a reverse proxy - the Mattermost console option for Connection Security within Web Server settings must be set to None. Even though Use Let's Encrypt is set to false, somehow it seems Mattermost still thinks this option is enabled if Connection Security is set to TLS instead of None.

1 Like
3

Thanks @mmfan for following up with the resolution! Would you be open to submitting a pull request that updates the documentation with the above?

4

I will definitely submit a PR for this. Thanks!

1 Like
5

Awesome, thanks so much @mmfan!