The install has actually gone fine - no issues at all.
I am running it as a VM on one of our servers. At the moment our router forwards port 443 to the passbolt server and that works fine.
We would like to allocate port 443 to a different server and access passbolt something like https://mydomain.com:33443 and let our router forward that to port 443 of the passbolt server.
However, when we use that format, if we use 443 as the specific port (which is obviously not necessary) then the browser connects, but any other port, even when forwarded as 443 by the router just times out.
We do lots of port forwarding to port 80 of different web servers, but this is not working for passbolt and port 443.
Is there a way of achieving this or is there something special going on with port 443?
Hi @LesD your question is clear, but many details of your setup are still unknown.
80 and 443 are known web traffic ports, but other ports are not. Which web server are you using? Can you provide your “routing” configuration?
It sounds like you desire a reverse proxy arrangement…which means that the traffic from passbolt would come back out through your https://mydomain.com:33443 server. This is typically the case when no public access is granted to the “backend” passbolt server.
If passbolt is on a separate server (or VM) behind a reverse proxy, it will need to also have it’s web server configured to function as such.
Provide more info - I’m confident someone here can help you.
Thank you for your notes. I think I am beginning to understand the issues. I will turn this round into a ‘how do I’ question rather than presenting a solution that is not working.
We have an internal network behind a Draytek router. The Passbolt server is running as a standard CentOS 7 VM on a Windows server.
We only have a single public IP. Port 80 we forward to out http Server and 443 to the Passbolt server - both work fine.
What can we do if we still have only a single IP but want our regular web server to go over to HTTPS?
Clearly, our regular server would have to run on port 443 but I was thinking that Passbolt might be able to work somehow using a different port. Iit is going to be used only by our own group who would happily connect using an explicit alternative port.
I thought this would simply work by connecting like https://mydomain.com:33443 with the router forwarding that directly to the Passbolt server, but this is clearly not working.
Is such an arrangement possible in some relatively simple way?
@LesD I see, you are portforwarding router port 33443 to the passbolt server ip address, port 443. This should work fine, although it only affects traffic coming into your public ip address. It does not affect any other internal traffic. For example, the passbolt server needs to know how to find itself. There may be DNS settings that are missing.
But you say it’s not working - what is actually happening to lead you to conclude this? What response are you getting at https://mydomain.com:33443? What are the passbolt logs showing?
You also say that you want the other web server behind the router to be able to provide https connections. You could take router port 443 and direct it to the other web server along with port 80.
But if you cannot resolve portforwarding from 33443, and only 443 portforwarding is working for whatever reason, you need a reverse proxy to listen to domain requests all coming in on router port 443. Don’t know which model router you are using, or whether it comes with a reverse proxy feature built-in. But if it doesn’t, then you would need to create a reverse proxy (on a new VM or existing VM) that sits behind the router, receiving all ports 443 and 80 traffic from the router. It will act like a “front desk switchboard” for incoming traffic, and redirect as needed to the different backend servers. It can also conveniently be configured to take all port 80 traffic and make it secure with https.
Each backend server would need to be configured to report responding traffic back to the reverse proxy. Depends on which web server you are using on each VM/server. i.e Apache, Nginx, or something else.
Thank you. Based on your comments I have been doing some more reading and can now see that what I thought would be achieved by simple port forwarding is not going to work.
It seems quite a ‘deep’ topic and not directly relevant to Passbolt. As I don’t actually need this facility at the moment it is time to shelve it and spend some more time following up the suggest you have made.
I have done a lot more reading on reverse proxies. It seems to be quite simple to create a proxy for http sites using Apache throughout.
I have found one site here that demonstrates a setup of a reverse proxy receiving both http and https traffic (using a letsencrypt certificate) but with the back end servers being all http.
That is a nice idea if the back end network is secure. But it will not work with Passbolt which comes as an https server.
This is where I am no longer clear how to proceed for https client > reverse proxy > https passbolt.
Does the reverse proxy need a letsencrypt certificate? If yes, then how does this match up with the https passbolt server and its certificate?
I have seen quite a few https/ssl examples and there seems to be no consistent method being used. Some make no mention of a certificate on the reverse proxy (but show 443 being forwarded) while others include certificates.
Ideally, to my mind, the proxy should just pass through whatever it receives. I think I saw somewhere (can’t find it at the moment) mention of Apache 2.4+ having the ability to do this without any need for a certificate (or many certificates if many servers are in the back-end).
Hi @LesD, I’ve always used Nginx for a reverse proxy, and you can search for previous discussions/templates in the forum.
If a “proxy” is used with outgoing requests from an internal network in order to hide the source of the requests, then a “reverse proxy” is used for incoming requests from an external network in order to hide the source of the response.
It is possible (and many times secure “enough”) to use Let’s Encrypt certs on the reverse proxy which handles traffic coming in from the world, while at the same time the reverse proxy connects via http to a backend server at a different IP, or a service on the same IP, etc. Sort of depends on how your network is setup. Passbolt could be configured to run via http, but reverse proxies can send to https. When it comes to whether the backend is http or https, the general difference is in how you direct the reverse proxy to send all received incoming requests. If you direct all traffic to http://mypassboltbackend.com it will go to port 80. Of course, your backend could then be set up to redirect all traffic on 80 to port 443. To keep it simpler, you could just send to https://mypassboltbackend.com and it would go to 443. My backend server has certs and it’s set up just like a normal server.
The backend server can be configured generally “as if” there were no reverse proxy, but I know in the case of Nginx there are some additional directives in the configuration on the backend that will improve the recognition of the incoming IP address (you wouldn’t want the reverse proxy IP, but the IP of the external user, for example).