# Problems Running emonCMS Behind Reverse Proxy with SSL on Separate Raspberry Pi

**URL:** <https://community.openenergymonitor.org/t/problems-running-emoncms-behind-reverse-proxy-with-ssl-on-separate-raspberry-pi/7680>\
**Category:** Emoncms\
**Tags:** ssl, reverse-proxy, proxypass\
**Created:** [18 June 2018 17:59 UTC](https://community.openenergymonitor.org/t/problems-running-emoncms-behind-reverse-proxy-with-ssl-on-separate-raspberry-pi/7680 "2018-06-18T17:59:10Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![brandock](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/b/5e9695/32.png) [@brandock](https://community.openenergymonitor.org/u/brandock)\
**Post date:** [18 June 2018 17:59 UTC](https://community.openenergymonitor.org/t/problems-running-emoncms-behind-reverse-proxy-with-ssl-on-separate-raspberry-pi/7680/1 "2018-06-18T17:59:10Z")

</div>

I have several Raspberry Pi web servers running various things, including one that runs emonCMS (emonSD-26Oct17 version). I’d like to set up a reverse proxy behind my home router, running on a dedicated Raspberry Pi that can route traffic to the correct Pi based on domain. Thus I’d like to be able to run emonCMS behind a reverse proxy running on a different machine.

I have had success doing this with both NGINX and Apache2 running the reverse proxy, as long as I stick with http. As soon as I try to enable SSL I get results that suggest to me that emonCMS can no longer parse the inbound URL to find which script it should run.

Here is what I see:

 ![Untitled](https://community.openenergymonitor.org/uploads/default/original/2X/5/5879c7462272727362174efeea03b6d927e090d3.jpg)

Here is the VirtualHost I am running. Can anyone help?

```
<IfModule mod_ssl.c>
    <VirtualHost _default_:443>
            ServerAdmin webmaster@localhost

            DocumentRoot /var/www/html

            ErrorLog ${APACHE_LOG_DIR}/error.log
            CustomLog ${APACHE_LOG_DIR}/access.log combined

            SSLEngine on

            SSLCertificateFile /etc/letsencrypt/live/baldockery.net/fullchain.pem
            SSLCertificateKeyFile /etc/letsencrypt/live/baldockery.net/privkey.pem

            ProxyPass / http://192.168.0.100/
            ProxyPassReverse / http://192.168.0.100/
            ServerName baldockery.net

    </VirtualHost>

```

---

<div class="post-metadata">

**Author:** ![peter](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/peter/32/2749_2.png) [@peter](https://community.openenergymonitor.org/u/peter)\
**Post date:** [19 June 2018 08:34 UTC](https://community.openenergymonitor.org/t/problems-running-emoncms-behind-reverse-proxy-with-ssl-on-separate-raspberry-pi/7680/2 "2018-06-19T08:34:33Z")

</div>

In addition to your normal settings I use:

> ```
> ServerName abc.xyz.org
> UseCanonicalName On
> 
> SSLProxyEngine On
> 
> ProxyPreserveHost On
> ProxyRequests Off
> RequestHeader set X-Forwarded-Proto "https" env=HTTPS
> 
> ProxyPass /emoncms http://emonpi/emoncms
> ProxyPassReverse /emoncms http://emonpi/emoncms
> 
> ```

Some of the above may be for the other sites behind my proxy, like node-red, the mqtt relay etc.

I don’t recall changing anything on the emonpi, but…

---

<div class="post-metadata">

**Author:** ![brandock](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/b/5e9695/32.png) [@brandock](https://community.openenergymonitor.org/u/brandock)\
**Post date:** [26 June 2018 06:08 UTC](https://community.openenergymonitor.org/t/problems-running-emoncms-behind-reverse-proxy-with-ssl-on-separate-raspberry-pi/7680/3 "2018-06-26T06:08:17Z")

</div>

That worked. Thank you!

---

<div class="post-metadata">

**Author:** ![brandock](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/b/5e9695/32.png) [@brandock](https://community.openenergymonitor.org/u/brandock)\
**Post date:** [3 July 2018 01:55 UTC](https://community.openenergymonitor.org/t/problems-running-emoncms-behind-reverse-proxy-with-ssl-on-separate-raspberry-pi/7680/4 "2018-07-03T01:55:45Z")

</div>

Another question. Did you have any luck putting node-red behind a reverse proxy with SSL? I haven’t been able to. It seems like the socket connection gets lost.

---

<div class="post-metadata">

**Author:** ![peter](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/peter/32/2749_2.png) [@peter](https://community.openenergymonitor.org/u/peter)\
**Post date:** [3 July 2018 08:41 UTC](https://community.openenergymonitor.org/t/problems-running-emoncms-behind-reverse-proxy-with-ssl-on-separate-raspberry-pi/7680/5 "2018-07-03T08:41:52Z")

</div>

You need to forward the web socket, ala:

> ```
> ProxyPass /nodered/comms wss://emonpi:1880/comms
> ProxyPassReverse /nodered/comms wss://emonpi:1880/comms
> ProxyPass /nodered https://emonpi:1880
> ProxyPassReverse /nodered https://emonpi:1880
> 
> ```

---

<div class="post-metadata">

**Author:** ![Pukka](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/p/d07c76/32.png) [@Pukka](https://community.openenergymonitor.org/u/Pukka)\
**Post date:** [4 July 2018 05:37 UTC](https://community.openenergymonitor.org/t/problems-running-emoncms-behind-reverse-proxy-with-ssl-on-separate-raspberry-pi/7680/6 "2018-07-04T05:37:48Z")

</div>

if you want an easier setup than NGINX, have a look at caddy [https://caddyserver.com/](https://caddyserver.com/) uses letsencrypt automatically and the config files are much simpler

---

<div class="post-metadata">

**Author:** ![peter](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/peter/32/2749_2.png) [@peter](https://community.openenergymonitor.org/u/peter)\
**Post date:** [4 July 2018 08:05 UTC](https://community.openenergymonitor.org/t/problems-running-emoncms-behind-reverse-proxy-with-ssl-on-separate-raspberry-pi/7680/7 "2018-07-04T08:05:34Z")

</div>

Except all the above is Apache…

---

<div class="post-metadata">

**Author:** ![brandock](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/b/5e9695/32.png) [@brandock](https://community.openenergymonitor.org/u/brandock)\
**Post date:** [4 July 2018 13:11 UTC](https://community.openenergymonitor.org/t/problems-running-emoncms-behind-reverse-proxy-with-ssl-on-separate-raspberry-pi/7680/8 "2018-07-04T13:11:58Z")

</div>

Now the reverse proxy works and stays connected, but it never asks for a password. It seems like the socket between the reverse proxy and the node-red server has been authenticated and now it doesn’t ask for it again. Maybe it is better to move authentication to the reverse proxy server? Or I need to forward more information from the reverse proxy to the node-red server?

More detail …

> [@peter](#):
>
> You need to forward the web socket

This worked. I did need to enable ws\_tunnel for it to work.  
`sudo a2enmod proxy_wstunnel`

I also needed to change “wss” to “ws”, since I’m not running SSL on the node-red server itself, so the communication from the reverse proxy to node-red is over ws, not wss.

```
ProxyPass /comms ws://192.168.1.25:1880/
ProxyPassReverse /comms ws://192.168.1.25:1880/	
ProxyPass / http://192.168.1.25:1880/
ProxyPassReverse / http://192.168.1.25:1880/

```

> [@Pukka](#):
>
> have a look at caddy [https://caddyserver.com/](https://caddyserver.com/)

Thanks. I’ll check that out, too.

---

<div class="post-metadata">

**Author:** ![MyForest](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/myforest/32/16336_2.png) [@MyForest](https://community.openenergymonitor.org/u/MyForest)\
**Post date:** [14 February 2020 02:56 UTC](https://community.openenergymonitor.org/t/problems-running-emoncms-behind-reverse-proxy-with-ssl-on-separate-raspberry-pi/7680/9 "2020-02-14T02:56:23Z")

</div>

Hi,

I just thought I’d mention I have a similar set up working.

I’m using emonCMS from a docker container and I want to proxy it from a sub-path in my existing Apache server.

I had a fair amount of trouble but nothing too unusual.

I can confirm that if you want emonCMS to spit out “https” URLs you need the:

> RequestHeader set “X-Forwarded-Proto” “https”

because mod\_proxy doesn’t add that by default. “core.php” will use that header.

I had a problem where emonCMS in the Docker container is running at “/” and many of the generated URLs ended up hitting the root of my web server so that was bad.

I used this hack to fix it.

First of all I stopped mod\_proxy including the host forwarding header using this blunt instrument (because unset didn’t work):

> ProxyAddHeaders Off

Then I added this abomination:

> RequestHeader set “X-Forwarded-Host” “[example.com/some/sub-path](http://example.com/some/sub-path)”

so that when core.php writes the URLs they include the sub-path I’m using on my Apache server. Without this it just appends the simple “script path” to the host name.

Finally, I already has Basic auth on the web server and so that was getting passed down and causing “Invalid Key” because it wasn’t valid in emonCMS.

I was able to stop it passing through like this:

> RequestHeader unset Authorization

and now I have to login to emonCMS and it creates a session cookie which is good.

Hope that helps someone one day.

David Bowen