The "too many certificates" error - ports 80 443 open then close

I think this is killing a discourse instance. It’s not getting past the “Oops…” heavy load message.

Create new order error. Le_OrderFinalize not found. {

  "type": "urn:ietf:params:acme:error:rateLimited",

  "detail": "too many certificates (5) already issued for this exact set of identifiers in the last 168h0m0s, retry after ....

I see others have encountered this for whatever reason, but is there solution?

I think you’d just need to wait a few hours and try again. IIRC the rate limit resets on an hourly basis. You could also request for a www prefix on the domain to get a new cert and reset the count.

Thanks for the pointer. I will try a rebuild now as it has been a few hours.

It turns out it’s a 7 day wait according to @Ed_S here !

Rebuild didn’t work.

I re-ran wizard setup to add www to get new cert. That seemed to work but I had to follow @pfaffman suggestion to disable connection check bypassing the 443 inaccessible error.

Now it is failing to load the cert, from logs:

...PEM_read_bio_X509_AUX() failed (SSL: error:0480006C:PEM routines::no start line:Expecting: TRUSTED CERTIFICATE)

This may be related to 443/80 closed port issue, which is another problem I see is a common problem.

tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      72556/docker-proxy

tcp6       0      0 :::443                  :::*                    LISTEN      72564/docker-proxy

Scan the ports via an external checker they come up closed :man_shrugging:

Ok, I reverted to another server with a restored version of the Db (Ubuntu 24.04.5 LTS), where the ports 80/443 were open. I checked using an external port scanner before I proceeded.

When I ran the ./launcher discourse-setup the 443 port in inaccessible error occurs.

So I re-scanned the server and ports 80 & 443 and now they comeback as closed.

It’s as if the act of running the wizard closes the ports?! :man_shrugging:

I don’t think the wizard supports multiple domain names, but I’ve not used it in a long time.

That’s almost certainly your problem. You probably don’t have dns set up or something is blocking incoming traffic

Hi thanks, yea I managed to solve the PEM_red… error above by reverting “grey clouds”, I found your advice in another topic. Thanks! :wink:

When I ran the wizard I just input the www. domain, maybe it’s wrong to do that? This was to get around the rate limit. Which it seems to have done, and then we get past that error onto this:

fail: nginx: runsv not running

[Wed Sep .... UTC 2026] Reload error for :

C=US, O=Let's Encrypt, CN=YR1

error 2 at 1 depth lookup: unable to get issuer certificate

error fullchain.cer: verification failed

C=US, O=Let's Encrypt, CN=YE2

error 2 at 1 depth lookup: unable to get issuer certificate

error fullchain.cer: verification failed

However that looks like a mild error as there are a run of cert success outputs in the log that simply were not happening before I grey clouded

Also ports 80 & 443 are showing open

AND (Let me add more context), the instance is resolving to the domain and allowing log-in, so the login screen appears (set to login only) and will accept credentials and two factor, then once that is successful it’s back to the “Oops…” screen of “oh not again”, even with this “mild error”

Which means I am back to where I started.

Originalyl nothing on the original server instance had been changed.

Then out of the blue, there were a few days of non performant behaviour, during this metrics were showing a weird cyclic server load beyond normal levels. Like it was reving but going nowhere. Until it finally tanked into a state of permanent “Oops”

So I started working on it. One solution was to backup and restore to a fresh discourse, which is where I have things, i.e. able to log in but back to “Oops”

I thought running latest and the postgres update would lick some bugs and what not.

I’m also seeing this printed multiple times at the end of the logs:

X-Accel-Mapping header missing

Bottom line is a bunch of problems I solved I think had nothing to do with the original issue causing the Oops screen, and I learned all about the letsencrypt rate limit which I’d never encountered 97 days yikes!), and perhaps when the server was having issues it triggered the rate limit, but this is all supposition.

So I dunno what to try next to diagnose the Oops issue.

Oh my :worried:

Ok I can confirm success. Used an older non admin user and I can log in.

Running round in circles when this apparently was the issue all along!