I’m getting to that point of desperation, because trying to have the Discourse Bot or Claude to fix this issue, seems impossible. I can’t really explain the issue, because I’m not that knowledgable, and I believe that’s what is really bothering me. I will try to explain what happened, from my point of view. When I was converting from single container to dual container, the file in samples/ used web-only and I left it by mistake instead of using web_only. Then, because of that (I believe), my images weren’t loading, because one “thing” was expected to point to web_only, but it was set to web-only. Made some changes and the images were fixed. not the issue is the LetsEncrypt certificates. I asked the bot to help me fix it, it told me to wait for the next day, because the issue was the certificates rate-limit. The issue was gonna get fixed. It didn’t. Then asked it again, then asked Claude, then Claude again… and we’ve been in this “wait until tomorrow at X hours and it WILL get fixed” for the past week. It never gets fixed, they both say “oh, I’m sorry, I shouldn’t have assumed it would get fixed, let’s try this instead, because now it will really get fixed”. It never does. The website itself is up and running, but I feel that every time I want to rebuild, something will happen, and to be honest I don’t want to rely on bandaids all the time. Claude told me to add something to the hooks in web_only.yml but since nothing like that is mentioned in the instructions provided here on the forum, I was expecting something other solution, such as… solving the actual problem. Can someone please help me figure out what the issue is, and where things are breaking? I would really appreciate it, because it’s exhausting at this point. Not the work, but not understanding what’s happening and why the “wait until tomorrow” never seems to fix anything. Thanks! I asked Claude to explain what the issue seems to be, maybe that helps? Here’s what it said: Title: Two-container setup: ECC cert folder missing after split, --force loop hitting rate limit every boot Setup: Two containers (data + web_only), migrated from standalone. Templates: web, ratelimited, ssl, letsencrypt, cloudflare. Hostname alltiago.com, no aliases. Symptom: Every web_only start hits the Let’s Encrypt rate limit and nginx fails to serve, returning connection errors until the ECC lines are manually removed from /etc/nginx/conf.d/outlets/server/20-https.conf. What I found: /shared/letsencrypt/alltiago.com_ecc/ does not exist on my install. /shared/letsencrypt/alltiago.com/ (RSA) exists and works fine, renewing normally. In web.letsencrypt.ssl.template.yml: cert_exists() { [[ "$(cd ${LETSENCRYPT_DIR}/${DISCOURSE_HOSTNAME}$1 && openssl verify -CAfile <(openssl x509 -in ca.cer) fullchain.cer | grep "OK")" ]] } issue_cert "ec-256" if ! cert_exists "_ecc"; then issue_cert "ec-256" "--force" fi Because the directory is missing, cert_exists "_ecc" fails on every boot, so --force runs and requests a brand new ECC cert regardless of what’s on disk. This is via the after_ssl hook that patches /etc/runit/1.d/install-ssl, so it runs on every container start, not just bootstrap. Result: 429 too many certificates (5) already issued for this exact set of identifiers in the last 168h. Then --installcert runs anyway against the empty directory and writes an unusable /shared/ssl/alltiago.com_ecc.cer. nginx is configured with both certs, can’t load the ECC one, and won’t serve. Confirmed working: ACME HTTP-01 validation succeeds (tested via staging, ECC cert issued fine against letsencrypt_test, correct directory structure created). RSA cert renewed successfully today. So this is not DNS, firewall, or validation. Questions: Is there a supported way to recreate alltiago.com_ecc/ without waiting out the rate limit? Should cert_exists returning false really trigger --force rather than a normal issue? --force bypasses the “existing valid cert” check and guarantees rate-limit exhaustion when the directory is absent. Is there a documented way to run RSA-only? Two factual notes so the thread doesn’t go sideways: the retry date moved from Aug 27 to Aug 29 because the RSA renewal today consumed a slot in the rolling 168-hour window. And the reason nobody else reports this is that on a normal install both directories are created at first boot and the --force branch never runs.

Wait. https://alltiago.com/ seems to be working just fine. But here’s what I was going to recommend [图片] alltiagocom: Is there a supported way to recreate alltiago.com_ecc/ without waiting out the rate limit? Yes, but it’s tricky. If you request a DIFFERENT cert, you get to start your count all over again. 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.

[图片] pfaffman: https://alltiago.com/ seems to be working just fine Yes, it is, because I was told to use a “bandaid” related to nginx. I can’t really explain what it is, because I don’t understand it. But the issue is that if I then want to do a normal rebuild, I will have issues (at least, from what I was told now, if I do it before Aug 29 when, hopefully, the certificate will be reissued. At this point, I can’t truly trust any of that. [图片] pfaffman: 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). Yes, www is already there from when I first installed Discourse last year. Now, after I pushed Claude to the limit to help me understand what’s happening, here’s what I got, and feel free to challenge that, because I’m here to learn when possible: ECC, which seems to be the issue now, isn’t truly necessary, because RSA is the default and everyone will still access my website without issues, if I drop ECC completely. As I said, hopefully, on Aug 29, this whole issue will be gone, once the 168h resets and the 5 cert limit is also reset: sudo docker exec web_only grep -i "retry after" /shared/letsencrypt/acme.sh.log | tail -1 "detail": "too many certificates (5) already issued for this exact set of identifiers in the last 168h0m0s, retry after 2026-08-29 03:43:15 UTC: see https://letsencrypt.org/docs/rate-limits/#new-certificates-per-exact-set-of-identifiers", If on Aug 29 things don’t go back to normal, Claude is recommending dropping ECC. This is what it said when I asked which file would be modified and which section: File: the copy we’re about to make, web.letsencrypt.rsa-only.template.yml (leaving your original stock file untouched as a fallback). What gets removed inside it: this whole block, found in the /usr/local/bin/letsencrypt section of the file: ######################################################## # ECDSA cert ######################################################## issue_cert "ec-256" if ! cert_exists "_ecc"; then # Try to issue the cert again if something goes wrong issue_cert "ec-256" "--force" fi LE_WORKING_DIR="${LETSENCRYPT_DIR}" ${LETSENCRYPT_DIR}/acme.sh \ --installcert --ecc \ -d ${DISCOURSE_HOSTNAME} \ --fullchainpath /shared/ssl/${DISCOURSE_HOSTNAME}_ecc.cer \ --keypath /shared/ssl/${DISCOURSE_HOSTNAME}_ecc.key \ --reloadcmd "sv reload nginx" That’s the entire ECC section, nothing else in the file changes. The RSA section right above it stays exactly as-is. One more file gets touched after that: containers/web_only.yml, to point at this new copy instead of the stock template. We’ll do that as a separate, later step.

Yeah. No. I would not change any templates. I guess the easiest way is to wait and then rebuild with the stock templates. Unless you want to get support from the AI instead of anyone else who knows how to use discourse forevermore.

I asked Claude to follow your advice by adding www as a new certificate request (if that’s what it’s called?) It seems to be working now. When I asked which files are leftovers from this whole process, I got this: Here’s what’s actually there, split by what’s from tonight vs. older leftovers from before this conversation: From tonight (this session): /tmp/acme.sh.txt — the script copy you asked to download, safe to delete now that you have it on your Mac /tmp/crtsh.json — empty 150-byte file from the crt.sh 502 error, junk, safe to delete /root/discourse-backup-20260827-1857.tar.gz — the real backup from earlier tonight (SSL/letsencrypt configs), this one’s actually worth keeping, not junk Older, from before this conversation (Aug 23 and Aug 25), not something I put there: /tmp/app.yml /tmp/check.png, /tmp/check162.png, /tmp/after.png, /tmp/rendered_avatar.png I don’t know what those older ones are for, they predate anything we did tonight, likely leftovers from an earlier troubleshooting session (yours, the bot’s, or a previous Claude chat). Do you recognize them, or want me to help figure out what they’re from before deciding whether to delete? Nothing suspicious showed up outside /tmp and /root, the broader system scan came back clean, just normal log files. Can I go ahead and delete all of those? [图片] pfaffman: I guess the easiest way is to wait and then rebuild with the stock templates Should I then revert what I just did? [图片] pfaffman: Unless you want to get support from the AI instead of anyone else who knows how to use discourse forevermore. I don’t mind talking to real humans at all, but I just don’t want to ask all the questions here and flood the forum with the whole process (output/logs from Terminal), and instead I rather just come up with something that’s already “kinda” working to make the conversation a bit shorter. We all have our own lives and limited time, and I don’t want to jump to the forum right away, unless I really hit a wall, you know? I appreciate your help! So, right now, should I revert what I did? Do you see any issue with that approach compared to just waiting for the 29th?

My advice remains to wait until you think you can get a new cert and switch back to stock everything

I recently ran into a related issue in cert_exists() while investigating Let’s Encrypt certificate reuse. In my case the certificate files and both RSA/ECDSA directories were present, but the current check was still returning false because openssl x509 -in ca.cer only keeps the first certificate from the issuer bundle. Using: openssl verify -untrusted ca.cer fullchain.cer fixed the verification. I also tested it with actual RSA and ECDSA certificates and completed a rebuild that reused both existing certificates without triggering forced reissuance. This may not be the same root cause as the missing _ecc directory described in this topic, but it affects the same cert_exists() path, so I’m linking it here in case it’s useful for anyone hitting similar symptoms. Report: Let's Encrypt: "unable to get issuer certificate" (error 2), forced reissuance and rate limits PR: FIX: preserve the Let's Encrypt issuer chain in cert_exists - Pull Request #1136 - discourse/discourse_docker - GitHub

this may help server_migration_diagnosing_standard_ssl.md main > These are diagnostic/recovery notes for a specific failure mode during a supported standalone Discourse Docker migration. They are not a replacement for the official migration or HTTPS documentation. On the new VPS, running: ``` ./launcher logs app | tail -n 200 ``` and see ``` [emerg] cannot load certificate "/shared/ssl/domain.tld.cer": PEM_read_bio_X509_AUX() failed (SSL: error:0480006C routines::no start line:Expecting: TRUSTED CERTIFICATE)nginx: ``` This indicates that nginx is failing because the certificate file does not contain valid PEM certificate data. In this migration, Docker was listening on ports 80 and 443, but nginx inside app could not start. - - - then if i run `ls -lah /var/discourse/shared/standalone/ssl/` and see This file has been truncated. show original or [图片] Caddy in front of app’s Nginx via Docker Compose Self-hosting I’ve upgraded one of my Discourse forum servers, so to open UDP 443 rather than only TCP in the IONOS Cloud Panel firewall (i’m from GB). I don’t use CDN because this particular forum isn’t big user number, but has lots of categories. I had some difficulty in ensuring the IP geos through nginx correctly, and the forum performs well now with no issues in /logs. I have rotating proxy logs set up with Docker Compose and appreciate that Caddy does some automatic redaction of sensitive field in th…

双容器配置求助：LetsEncrypt 已故障数日

产品支持安装

pfaffman (Jay Pfaffman) 2026 年8 月 28 日 11:33 6

我的建议仍然是等待，直到你认为自己能够获取新证书，并将所有设备恢复为官方原版系统。

话题		回复	浏览量
Fresh installation with Let’s Encrypt errors Self-hosting	18	4485	2019 年12 月 26 日
Hit Let's encrypt renewal limit Self-hosting	6	2344	2020 年7 月 1 日
Bootstrap error during Discourse install: ENOENT - /etc/runit/1.d/letsencrypt Self-hosting	24	822	2025 年11 月 21 日
Let's Encrypt renewal errors Self-hosting	9	2005	2020 年2 月 22 日
Let's Encrypt cert renewals (suddenly) failing Self-hosting	26	3559	2021 年12 月 28 日

双容器配置求助：LetsEncrypt 已故障数日

相关话题