Problems configuring SSL with snaps (caddy fails with result 'start-limit-hit')

Hi there. I’ve installed Rocket.Chat server, working mostly fine. The major trouble encountered is that files cannot be uploaded (stuck at 0%). Diggin’ and googlin’, I’ve found that this might be due to SSL errors. Indeed, if we put tls self_signed into the Caddyfile and restart the Caddy, file uploading works.

But our server is visible both from within the local network and from the Internet, and we intend to use RC clients from both sides. So, I believe, we need Let’s Encrypt working. Following the AutoSSL documentation, we get the caddy service running… only to learn that a minute later it fails with result 'start-limit-hit'. Here are some of the last lines from journalctl -u snap.rocketchat-server.rocketchat-caddy (I’ve replaced my domain and server names):

Apr 23 18:50:21 my.server.lan rocketchat-server.rocketchat-caddy[61857]: Activating privacy features… 2019/04/23 18:50:21 [my.domain.me] failed to get certificate: [my.domain.me] error presenting token: presenting with standard HTTP provider server: Could not start HTTP server for challenge -> listen tcp :80: listen: address already in use
Apr 23 18:50:21 my.server.lan systemd[1]: snap.rocketchat-server.rocketchat-caddy.service: Main process exited, code=exited, status=1/FAILURE
Apr 23 18:50:21 my.server.lan systemd[1]: snap.rocketchat-server.rocketchat-caddy.service: Unit entered failed state.
Apr 23 18:50:21 my.server.lan systemd[1]: snap.rocketchat-server.rocketchat-caddy.service: Failed with result ‘exit-code’.
Apr 23 18:50:21 my.server.lan systemd[1]: snap.rocketchat-server.rocketchat-caddy.service: Service hold-off time over, scheduling restart.
Apr 23 18:50:21 my.server.lan systemd[1]: Stopped Service for snap application rocketchat-server.rocketchat-caddy.
Apr 23 18:50:21 my.server.lan systemd[1]: snap.rocketchat-server.rocketchat-caddy.service: Start request repeated too quickly.
Apr 23 18:50:21 my.server.lan systemd[1]: Failed to start Service for snap application rocketchat-server.rocketchat-caddy.
Apr 23 18:50:21 my.server.lan systemd[1]: snap.rocketchat-server.rocketchat-caddy.service: Unit entered failed state.
Apr 23 18:50:21 my.server.lan systemd[1]: snap.rocketchat-server.rocketchat-caddy.service: Failed with result ‘start-limit-hit’.

There is absolutely no reason not to use SSL when you have Letsencrypt.

Read your logs… I think your issue is here

error presenting token: presenting with standard HTTP provider server: Could not start HTTP server for challenge -> listen tcp :80: listen: address already in use

So what else runs on port 80??

Thanks for the reply. Sure, we have apache2 on the same server, and the port 80 is taken up by it. But no matter which port I choose for Caddy, following this guide, nothing changes. Currently, my Caddyfile looks like this:

https://example-domain.com:3001 {
proxy / localhost:3000 {
websocket
transparent
}
}

i.e., I chose port 3001. Then I restart both the RC server and the caddy. Yet, caddy then fails again, with the same error that port 80 is already in use. It obviously ignores my port settings somehow.

However, if in the Caddyfile I change https://example-domain.com:3001 to http://example-domain.com:3001, and restart the caddy, it starts fine without failing and listens to port 3001. But I need SSL to be enabled. What could be the problem here?

Why are you using apache AND caddy?

The page says:

“Configure Caddy yourself or use another http proxy”

Note “OR”. One or the other. Not both.

Just do all your proxing with apache. There is no need for caddy. It is there for those who don’t already run apache or nginx.

Just let apache handle the SSL and proxing. There are examples on how to do that.

Why are you using apache AND caddy?

Because apache was there for several years already for other services, and when installing Rocket.Chat via snaps, I just followed the docs which never mentioned to check (neither before nor during installation) if apache is there :). In fact, I had no idea what caddy is until yesterday when I installed RC.

Thanks for your replies. For now, I just changed apache’s port to 8080 and caddy works fine now. I’m not sure if it’s as easy to configure apache for Let’s encrypt as it is easy for caddy, so I’ll leave it as is for now.

Hmmm. So a clear lesson in why you should not install stuff unless you know what it does.

And as you still haven’t learned, you now have two http web server/proxies when you only need one.

That is a waste of resources, and a great way to cause yourself more issues.

So you’ll end up somewhere/sometime with connection issues and some poor soul will try to help you, not for one moment thinking you would be mad enough to run two web servers/proxies.

And now you seem to have used Caddy to handle Letsencrypt as well? Not using SSL on Apache?

Set Apache as a proper reverse proxy for Rocket and use Letsencrypt with it. Easy enough with the dehydrated script or various others.

Yes, Everything mentioned above is correct.

It is super important to understand what you’re doing when deploying software. That means reading ALL documentation BEFORE you install.

1 Like

If you can’t move away from apache look at certbot for auto SSL with letsencrypt: https://certbot.eff.org/all-instructions

I have long used dehydrated from here.

It was one of the first ‘simplified’ methods that didn’t need a pile of bloatware & dependencies. Just bash.

Still, it doesn’t fix the OPs double webserver issue :slight_smile:

Never seen dehydrated before. That’s interesting.

Yes for sure ditch the double proxy. Pick one and use it for all on the server. Don’t double complicate your life. It will cause you head aches for ever

Dehydrated - was called letsencypt.sh I think but he got leaned on to change the name.

I think it was the first, or one of the first, simple implementations that didn’t need loads of other junk installed, some of which couldn’t be due to dependencies or versioning or whatever.

The hook scripting part makes it pretty powerful too.

Only thing I have ever used for letsencrypt certs !!

1 Like