Too many failed authorizations

I am trying to get rocketchat-server (chat server) up and running on RPi3. I have many SD cards with rocketchat-server on them. Some fail to connect to my URL and others succeed. The ones that fail have the error I show below.

I am often rebuilding new SD cards with fresh ubuntu core and rocketchat-service snap as I work on my own chatbot snap. But for the last two weeks I can’t get any of my new rocketchat-server installs to connect to my URL.

I have been working with the rocketchat people, but ultimately they say I am trying to get too many certs…

Please advise.

My domain is: https://rocketreese.club

I ran this command: I’m not sure what specific command rocketchat-server runs, but here is the caddy file log output.

It produced this output: ‘’‘Feb 01 19:26:46 localhost.localdomain rocketchat-server.rocketchat-caddy[6528]: Activating privacy features…2018/02/01 19:26:46 [rocketreese.club] failed to get certificate: acme: Error 429 - urn:acme:error:rateLimited - Error creating new authz :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/’’’

My web server is (include version): chat server: rocketchat-server 0.60.30

The operating system my web server runs on is (include version): Ubuntu core 16.04 on RaspberryPi-3 (armf).

My hosting provider, if applicable, is: FastWeb (I’m living in Italy)

I can login to a root shell on my machine (yes or no, or I don’t know): Yes. I can login to my username and then “sudo su -” to get a root shell. However, this is a snap environment, so some things even root can write to.

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No.

@mholt, could you suggest anything to look into to diagnose Caddy cert issuance failures?

1 Like

Are you persisting the certificates? Caddy always writes them to disk immediately and reuses them, but it sounds like what you’re doing with SD cards is the equivalent of throwing away containers without persisting Caddy’s storage ($CADDYPATH; the default is ~/.caddy).

Short answer is “I don’t know”. In some cases it must be, in others, like when I reformat the SD card and start from scratch, it isn’t, obviously. And it’s these new versions that have been failing for the last two weeks. I only run one version at a time, so there’s no clashing issue.

I have forwarded your question and comments to the rocketchat-server developers that have been helping me. I know where the Caddyfile is for setting up the port forwarding, but I don’t know where Caddy’s storage is. I don’t see ~/.caddy in my home directory and I don’t know how to see rocketchat-servers environment variables (but I will check the docs and try to figure it out).

@mholt
When I check crt.sh, it shows that the last cert I was given was Dec 21st, so I’m not running out of certs. I have tried many new SD cards over the last couple weeks with fresh ubuntu core 16.04 and rocketchat-server snap installs. Shouldn’t each one request a new cert, or at least a duplicate (Duplicate Certificate limit of 5 certificates per week.)? But what I am getting is a authorization failure…


https://crt.sh/?q=rocketreese.club

crt.sh ID Logged At ⇧ Not Before Issuer Name
284118852 2017-12-21 2017-12-21 C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
281344489 2017-12-18 2017-12-18 C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
281278184 2017-12-18 2017-12-18 C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
281011450 2017-12-17 2017-12-17 C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
279067920 2017-12-15 2017-12-15 C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
278160576 2017-12-14 2017-12-14 C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
269791228 2017-12-03 2017-12-03 C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
266839222 2017-11-29 2017-11-29 C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
248798970 2017-11-06 2017-11-06 C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
147107151 2017-06-01 2017-06-01 C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
139901812 2017-05-17 2017-05-17 C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
139711893 2017-05-17 2017-05-17 C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
139084692 2017-05-16 2017-05-16 C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3

Here is the error that rocketchat-server caddy has:

Feb 02 17:05:01 localhost.localdomain rocketchat-server.rocketchat-caddy[5843]: Activating privacy features…2018/02/02 17:05:01 [rocketreese.club] failed to get certificate: acme: Error 429 - urn:acme:error:rateLimited - Error creating new authz :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/

Well, I am not quite sure. I don’t think this is something that Caddy (or lego) can fix. At least, not with the information we have. It would be helpful if we knew about your ISP, since you are running this from home (it seems), and whether you have a static or dynamic IP address. It’s quite possible there is something about a combination of that and/or how Caddy is being run inside the snap you’re using.

I am often rebuilding new SD cards with fresh ubuntu core and rocketchat-service snap as I work on my own chatbot snap.

It sounds like you should be using Let’s Encrypt’s staging endpoint, rather than the live one. The staging endpoint has much higher rate limits for this, and is designed for development.

Yes, running from home. I’m in Italy. Fastweb is my ISP. I have a static IP, which I requested. Again, I am not a rocketchat-server (RC) developer, so I don’t have control over how it handles the certifications. Or, I don’t possess the knowledge yet. I’m waiting for more input from the RC developers. I included this thread, which I’m hoping they will read and comment.

Okay. Well, I still maintain that you need to use Let’s Encrypt’s staging endpoint for development.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.