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?

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!

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. [immagine]Need help with dual container. Issue with LetsEncrypt for a few days now What I’d probably recommend is to add www to the hostname so you get certs for both (but maybe you already did that, so you could add a third name, just to get a new cert). Set up Let’s Encrypt with multiple domains / redirects is supposed to help.

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:

[immagine] agemo: I re-ran wizard setup to add www to get new cert. I don’t think the wizard supports multiple domain names, but I’ve not used it in a long time. [immagine] agemo: I had to follow @pfaffman suggestion to disable connection check bypassing the 443 inaccessible error 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: [immagine] Error for logged in users and Git hang Support Without me changing anything, my Discourse forum https://lilypond.community suddenly started returning an error page for any request with login cookies: Oops The software powering this discussion forum encountered an unexpected problem. We apologize for the inconvenience. Detailed information about the error was logged, and an automatic notification generated. We’ll take a look at it. No further action is necessary. However, if the error condition persists, you can provide additional detail…

For anyone finding this topic later because of the YR1 / YE2 issuer errors in the logs: I reproduced that specific certificate-verification failure while investigating a separate Let’s Encrypt issue. cert_exists() currently keeps only the first certificate from ca.cer, which can discard a certificate required to build the chain. Using: openssl verify -untrusted ca.cer fullchain.cer fixes the verification in the cases I tested. I verified actual RSA and ECDSA chains and completed a rebuild that reused both existing certificates without triggering forced reissuance. I documented the issue and proposed a fix here: Report: Let’s Encrypt cert_exists() truncates the CA chain, causing forced reissuance and rate-limit failures PR: FIX: preserve the Let’s Encrypt issuer chain in cert_exists - Pull Request #1136 This only concerns the certificate issuer-verification errors shown above; it is not intended to explain the separate application issue that was ultimately resolved in this topic.

L’errore «troppi certificati»

Assistenza prodotto Installazione

agemo (agemo) 23 Settembre 2026, 11:05am 8

Oh no

Argomento		Risposte	Visualizzazioni
Need help with dual container. Issue with LetsEncrypt for a few days now Self-hosting unsupported-install , two-container , letsencrypt	7	379	Ottobre 12, 2026
Workaround for the 1 week Let's Encrypt limit Self-hosting	2	1367	Giugno 16, 2023
Lets Encrypt Certificate - Issuing Problem Self-hosting	2	787	Novembre 6, 2023
Let's Encrypt: "unable to get issuer certificate" (error 2), forced reissuance and rate limits Bug letsencrypt	5	260	Ottobre 13, 2026
Installation produced broken, zero byte certificate Self-hosting letsencrypt	8	2332	Maggio 11, 2019

L’errore «troppi certificati»

Argomenti correlati