Hello. I’m having a little trouble, so please help me.
(Translated from Japanese using DeepL.)
After testing the setup and operation of Rocket.Chat, I installed the server in the production environment, but the message “Workspace in read-only mode. Admins can restore full functionality by connecting it to the internet or upgrading to a premium plan.” appeared and I was unable to chat.
This is because, for security reasons, a proxy server must be set up with a whitelist to access external sites from within the organization’s local network. It is likely that the whitelist has not yet been registered, preventing access to Rocket.Chat’s authentication server and causing it to appear as an air-gapped environment.
Currently, connections to the “rocket.chat” domain are rejected as they are classified as belonging to the “chat app” category.
Is this correct? I would like to seek your expertise before submitting an incorrect whitelist addition request.
Additionally, could you please let me know which server I need to access in order to update Rocket.Chat in the future?
For now, I am considering adding *.snapcraft.io to the whitelist.
If anyone has experience setting up Rocket.Chat in a similar environment, could you please share how you are managing it?
Additional information.
All domains listed on this page that should be allowed to connect (*.rocket.chat) are allowed to connect.
I confirmed the connection with both Firefox and cURL.
Further analysis of the logs revealed that although access to each domain was possible through the proxy, SSL connections were failing due to a “self-signed certificate” error.
The necessary certificates have been installed in the certificate store at the OS level.
We have confirmed that both Firefox and cURL can load the content of each domain.
(The error page is returned correctly, etc.)
How can we get Rocket.Chat to recognize the SSL certificate?
So you have opened ports to those domains. Fine. But that is only part of the issue.
Rocket.Chat is NOT a web server. It knows nothing about SSL certificates. I cannot handle SSL certificates. It serves html code on port 3000 but that does NOT make it a web server.
You need a properly configured web server setup to use SSL certificates as a reverse proxy to Rocket.Chat eg nginx, apache, traefik etc
So your proxy reverses calls from https port 443 to http localhost:3000
Please read the documentation on this and understand what you are trying to do.
First, our Rocket.Chat is located on our organization’s internal network.
Since Rocket.Chat is only used within the organization, we decided that HTTPS was not necessary, so a reverse proxy was not required. All we needed was for Caddy to listen on port 80.
However, when connecting to various Rocket.Chat servers outside the organization, we want to communicate from the internal Rocket.Chat through the organization’s firewall.
Yes, Rocket.Chat is not a web server. Rather, we are having trouble figuring out how to connect to the official Rocket.Chat server cluster, which has subdomains such as “collector” and “cloud,” as a client.
Rocket.Chat is the only client that cannot connect to the server cluster described at Firewall Configuration.
As a result, it is treated as air-gapped, and Rocket.Chat is in read-only mode.
This is likely because it cannot properly reference the CA certificate imported into the local certificate store.
Tools like cURL can access each server, but Rocket.Chat is the only one that can’t.
It worked.
In conclusion, it was necessary to place the SSL server certificate in a directory that snap could recognize and then tell it about the environment variable.
By following the steps below, Rocket.Chat on snap was able to successfully perform a TLS handshake using the server certificate.
It really doesn’t matter. Https is good practice. With your company policies as strict as they are, it is at odds with wanting to use http… some local user sitting their reading all the company comms in plain text.
I bet you probably enforce 2FA though…
As above.
With free certificates etc it is trivial in 2025 and just generally good security practice both externally AND internally. http is not. Before long most browsers will refuse to use http at all. The world has moved on. You should too.
Note also that Rocket mobile clients will not work with http, at all.
And if you are allowing external access https is a necessity, and allowing both 80 and 443 will get your site URL in a muddle and cause issues (experience tells me this).
As far as adding your own certs to caddy then this is probably the basis for that:
Glad you have got it fixed and thanks for posting how you achieved it for others.
Ideally, we should close HTTP (port 80) and only use HTTPS (port 443).
However, we took a shortcut because of the limited conditions.
Not disclosed outside the organization.
Only allow connections from a limited network within the organization.
This is a limited-time measure.
This is a proof of concept to obtain funding.
Once funding and approval are secured, we will begin full-scale operation within the organization.
At that time, the server certificate will be added to Caddy.
If we proceed with full-scale operation, we must implement robust security measures.
