It’ll run for a few seconds and then crash with the following output:
May 31 03:26:09 ns544081 systemd[1]: snap.rocketchat-server.rocketchat-caddy.service: Failed with result ‘exit-code’.
May 31 03:26:09 ns544081 systemd[1]: snap.rocketchat-server.rocketchat-caddy.service: Service hold-off time over, scheduling restart.
May 31 03:26:09 ns544081 systemd[1]: Stopped Service for snap application rocketchat-server.rocketchat-caddy.
May 31 03:26:09 ns544081 systemd[1]: snap.rocketchat-server.rocketchat-caddy.service: Start request repeated too quickly.
May 31 03:26:09 ns544081 systemd[1]: Failed to start Service for snap application rocketchat-server.rocketchat-caddy.
May 31 03:26:09 ns544081 systemd[1]: snap.rocketchat-server.rocketchat-caddy.service: Unit entered failed state.
May 31 03:26:09 ns544081 systemd[1]: snap.rocketchat-server.rocketchat-caddy.service: Failed with result ‘exit-code’.
However if you add the self_signed tag behind it it works without problems. So does anyone maybe have any clue what should I do differently? Or what am I doing wrong exactly…
The A records point to the servers IP correctly. I’ve opened most of the ports by now.
I’ll add the caddy log as well.
snap.rocketchat-server.rocketchat-caddy.service: Main process exited, code=exited, status=1/FAILURE
May 30 13:59:15 ns544081 systemd[1]: snap.rocketchat-server.rocketchat-caddy.service: Unit entered failed state.
May 30 13:59:15 ns544081 systemd[1]: snap.rocketchat-server.rocketchat-caddy.service: Failed with result ‘exit-code’.
May 30 13:59:16 ns544081 systemd[1]: snap.rocketchat-server.rocketchat-caddy.service: Service hold-off time over, scheduling restart.
May 30 13:59:16 ns544081 systemd[1]: Stopped Service for snap application rocketchat-server.rocketchat-caddy.
May 30 13:59:16 ns544081 systemd[1]: Started Service for snap application rocketchat-server.rocketchat-caddy.
Do you have access to the Caddy logs? The service status logs don’t tell us much useful information, only that it exited with an exit code. The actual Caddy logs should elaborate more on why it closed.
Hi, thank you for the response. Sadly I’m away from the server currently but I saw an 403 error in there . Which makes no sense cause the A records are set directly to the server IP.
Also, if I add an http before the domain it also gives me this:
Jun 01 04:11:09 ns544081 rocketchat-server.rocketchat-caddy[16457]: Activating privacy features… done.
Jun 01 04:11:09 ns544081 rocketchat-server.rocketchat-caddy[16457]: http://investors.chat
Jun 01 04:11:09 ns544081 rocketchat-server.rocketchat-caddy[16457]: WARNING: File descriptor limit 1024 is too low for production servers. At least 8192 is recommended. Fix with “ulimit -n 8192”.
But it never actually enables https and when I take off the http it crashes again with the before mentioned errors
Unfortunately the lines are truncated and we can’t see the exact error from LetsEncrypt, but I’m going to guess, based on the fact that it’s been auto-restarting, that you’ve been blocked by the LetsEncrypt ACME server for abusing the rate limits.
The Rocket.Chat documentation touches on this:
First, be sure that your DNS has finished resolving before before attempting to enable SSL. If your DNS is not working yet, you could be instantly throttled by Let’s Encrypt for up to a week.
There’s a few issues that could have caused this issue initially, but unless you can review your logs back to the first few times you tried to launch it with HTTPS, it’s tough to say what caused it or how to fix it. It may even have been fixed already, but you’ll probably have to wait a week (or use a different domain name) in the mean time.
We can’t recommend enough using the staging environment (using the Caddy flag -ca https://acme-staging-v02.api.letsencrypt.org/directory) when initially testing and deploying Caddy’s automatic HTTPS.
