How can I change the HTTPS port from 443?
-
On my server, Apache2 listens on port 443 and I have a number of sites and applications behind that accessed via a reverse proxy (which also provides my LetsEncrypt layer).
However, from what little I've found in the Cloudron documentation, its use of port 443 seems to be fixed. Is that the case? Or can I change the HTTPS port to avoid this clash?
-
On my server, Apache2 listens on port 443 and I have a number of sites and applications behind that accessed via a reverse proxy (which also provides my LetsEncrypt layer).
However, from what little I've found in the Cloudron documentation, its use of port 443 seems to be fixed. Is that the case? Or can I change the HTTPS port to avoid this clash?
@John_Waters It is fixed, Cloudron is not designed to be run on a different port. If you want to reverse proxy cloudron, you'll have to set it up in whatever you're using, SNI grabbing etc... It gets complex very quickly and doesn't work well, but it can be done. What proxy software are you using? I'll try to help.
-
@John_Waters It is fixed, Cloudron is not designed to be run on a different port. If you want to reverse proxy cloudron, you'll have to set it up in whatever you're using, SNI grabbing etc... It gets complex very quickly and doesn't work well, but it can be done. What proxy software are you using? I'll try to help.
@will Thanks for the reply. I use Apache2 for the reverse proxies.
If I can't change the Cloudron HTTPS port easily, that makes it unusable for me. (Fixing the port at 443 seems like a very strange design decision. I can't think of any other service where I can't change the listening port.)
-
Cloudron has a built-in reverse proxy (which providers certs for the apps it uses) and each app is installed on a subdomain of it's own. This reverse proxy is hard coded to use port 443.
Generally, this is not a problem though. Is there a reason why you cannot reverse proxy to port 443? For example, @smilebasti succeeded in doing so, I made a fix for websockets as well last release - https://forum.cloudron.io/topic/2288/mastodon-terminal-not-starting/12
-
@John_Waters Are you just going to install Cloudron in an internal network (or do you have it already installed?). I can help accordingly.
-
Cloudron has a built-in reverse proxy (which providers certs for the apps it uses) and each app is installed on a subdomain of it's own. This reverse proxy is hard coded to use port 443.
Generally, this is not a problem though. Is there a reason why you cannot reverse proxy to port 443? For example, @smilebasti succeeded in doing so, I made a fix for websockets as well last release - https://forum.cloudron.io/topic/2288/mastodon-terminal-not-starting/12
@girish I don't see how I can have more than one process at the same IP address listening on the same port.
What am I missing?
-
@John_Waters Ah, the idea is that the Cloudron will be in a separate VM from the reverse proxy. The reverse proxy can have the public IP (and possibly your other apps). The Cloudron can be an internal VM with a private IP.
(Cloudron has to be a separate VM because we do not support installing other things in the VM).
-
@John_Waters Are you just going to install Cloudron in an internal network (or do you have it already installed?). I can help accordingly.
@girish I don't understand what you mean by "internal network".
However, not being able to see any other option, I have just installed Cloudron in a VM. Only when I ran the installation script (a few minutes ago) did I realize that it would be downloading a Docker image. That suggested a way out, but ...
When I ran
sudo docker ps
I could see nothing running.sudo netstat -tuplenshows me
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 111 16941 1115/mysqld
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 0 16376 1127/nginx.conf
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 0 16157 973/unbound
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 16490 1131/sshd
tcp 0 0 127.0.0.1:3000 0.0.0.0:* LISTEN 1001 18138 1283/node
tcp 0 0 127.0.0.1:8953 0.0.0.0:* LISTEN 0 16158 973/unbound
tcp 0 0 0.0.0.0:3002 0.0.0.0:* LISTEN 1001 18149 1283/node
tcp 0 0 172.18.0.1:3003 0.0.0.0:* LISTEN 1001 18150 1283/node
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 0 16378 1127/nginx.conf
tcp6 0 0 :::80 :::* LISTEN 0 16377 1127/nginx.conf
tcp6 0 0 :::22 :::* LISTEN 0 16499 1131/sshd
tcp6 0 0 :::443 :::* LISTEN 0 16379 1127/nginx.conf
udp 0 0 0.0.0.0:2514 0.0.0.0:* 1001 17132 961/node
udp 0 0 0.0.0.0:53 0.0.0.0:* 0 16156 973/unbound
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 12443 747/dhclient -
@John_Waters Ah, the idea is that the Cloudron will be in a separate VM from the reverse proxy. The reverse proxy can have the public IP (and possibly your other apps). The Cloudron can be an internal VM with a private IP.
(Cloudron has to be a separate VM because we do not support installing other things in the VM).
@girish Thanks. I'd already started down that route (reluctantly) because I could see no other option. I'll see how that goes ...
I'll have to get back to that tomorrow.
Thanks again for the clarification. (Some more detailed documentation on the main site would have been helpful.)
