@girish That did the trick, I appreciate it.

@lcd_official thanks for the kind words 🙂

yeah, I am not sure what changed on Cloudflare side, but we had to do this on our servers as well.

@omen OK, I figured out how configure Fastly now...
Please configure it like below:

Enable TLS - Yes Verify Certificate - Yes Certificate hostname - In my case, it is wildcard. But since you use the 'manual' provider, the hostname is subdomain.example.com. SNI hostname - this is subdomain.example.com.

With the above settings, fastly serves up pages fine on http.

c787fbfb-57bb-4793-a100-3da1015ba6a5-image.png

One thing to remember is, because you are using "manual" DNS provider, Cloudron requires "http" callbacks for Let's Encrypt to work. I am not sure how this works in fastly, does it allow you to have some URLs that are not "cached" ? I guess one way is to call the Cloudron app subdomain as "website.domain.com" but the domain in fastly should be something else like "realwebsite.domain.com" (meaning, name it different). This way, manual setting on Cloudron can continue to use HTTP reliably to get certificates.

If you want the domain names to be same, you have to use one of the automated DNS providers in Cloudron.

@cdolson thanks for reporting. I have replied in the LE forum. Looks like we introduced a bug in our DO 1-click image. I am working on a fix. Apologies for the mails you have been getting!

@aziz So, certificate for *.devz.cloud is already there, so if you install apps on subdomain it will work. Cert for devz.cloud (it is not a subdomain, so we have to get a separate cert from the wildcard cert) is getting rate limited.

You can just wait for 2-3 days to install an app on the bare domain and that should work. You should be able to install apps in subdomains in the meantime.

@girish Oh sorry about that, I don't seem to have looked that closely for the topic so that I would have noticed it.

I already thought that it has to do with the Let's Encrypt exchange. Thanks for that.

My nextcloud has no error, only my banking app, but I would say it is the same reason and I must wait for an update.

@murgero I suspect the exception is coming from https://git.cloudron.io/cloudron/cloudron-cli/-/blob/master/src/actions.js#L255 . That function is called from https://git.cloudron.io/cloudron/cloudron-cli/-/blob/master/src/actions.js#L309 (you can see the error message in the line after). If you know some nodejs, maybe you can debug that to see why it thinks options is undefined.

@d19dotca I fixed this now. It cleans up certs which expired 6 months ago.

@girish
Many thanks.

My mistake, I was so convinced auto-update was running that I didn't notice.

After updating to latest Cloudron version, all problems have resolved 👍

Thanks again
T.

@mehdi
This my friend is a good point, thank you for pulling me out of the tunnel. lol

Those are sent from Let's Encrypt for information mostly. You can safely unsubscribe, as your Cloudron will also notify you if renewal does not work.

@privsec said in Let’s encrypt certificates expiring?:

Like can there be a memory within cloudron of all subdomains used and when it comes time to renew, just renew it on all of those subdomains?

That's the current behavior. It only renews domains that are in use in Cloudron. AFAIK, there is no way to tell Let's Encrypt to "forget a subdomain" that we had gotten a certificate before. This is the reason why you get the reminder emails from Let's Encrypt about old domains.

@svallory Accept self-signed certs and login to dashboard. Once logged in, I would first go to settings and check for updates/update all the way to Cloudron 6. This is because LE made a change in the last few months which makes cert renewal fail on Cloudron side. Once updated, Domains -> Renew all certs.

@girish no changes - will monitor to see if it crops back up.

@girish so I created a new WP install on a different cloudron for the domain, https://slappersonly.co -- everything seems in order now, even for people who had errors before. Meanwhile I switched the older WP install to a new domain on the original cloudron https://slaps.vip .. there do not seem to be any issues for either domain now.

Not too terribly inconvenient as the 2 sites serve different purposes for the same brand, but bizarre nonetheless.

@jdaviescoates nope, just regular domains, not sure why but will just wait and see I guess

Since, we got so many support tickets about this already 🙂 I will paste what I said in the other thread.

Let's Encrypt have started using R3 as the intermediary cert - https://scotthelme.co.uk/lets-encrypts-new-root-and-intermediate-certificates/ . This cert has issuer text slightly different. Since the text has changed, Cloudron tries to renew the certs too early and this results in the above notification. The notification can be ignored since it's a false alarm, the certs and sites will be fine.

There are two ways to fix this:

Update to Cloudron 6 - you can go to Settings -> Check For Updates and then Update. It will give a notification that it is unstable. It's reasonably safe to update, the notification exists because we roll out updates very slowly to keep support manageable for us. Please expect some downtime (like 10 mins) since the update re-configures all the docker containers.

Alternately, you can make this one line change in your current Cloudron version - https://git.cloudron.io/cloudron/box/-/commit/3e62f1913ab05750a343c197c519d38bf17d5b3b . The file is /home/yellowtent/box/src/reverseproxy.js and then systemctl restart box.

@girish feeling lazy, will wait for the official update 🙂

So I'm pretty convinced the issue was the way I wrote the CAA records. I think my DNS provider didn't need the double-quotes in there and it caused issues. Reason I say that is because after introducing the CAA records, I suddenly had the certificate renewal errors.

Then when using a DNS check tool and I looked up CAA records for Google and Mozilla and more, none of them had the double-quote in there, but mine did. So I am sure that was the issue, as everything worked fine again after I removed the double-quotes.

I suspect the double-quotes was being taken literally as a string and so letsencrypt.org is not the same as "letsencrypt.org" in the DNS CAA record. I was able to later find the logs I had seen in the early morning which shows the following which confirms my conclusion: CAA record for <domain> prevents issuance.

So for anyone who comes across this later, make sure you're not using double-quotes I guess. haha.

@wu-lee do you know why it had failed to renew previously?

@andrewj720 Looks like DNS is not working on your server. You can also try host cloudron.io etc, I guess none of it working?

Can you check if your cloud firewall allows outbound port 53 UDP ? I think there was a post on this forum some time ago that someone had it blocked in AWS security group by mistake, for example.

@marcusquinn said in Lets Encrypt renewal time:

Without looking at that screen again, maybe it wasn't clear it should recommend using the root domain for that input?

I think many people start out just like you did and then move it to the main domain. We don't put the recommendation as such because I think it can be scary to throw your root domain and API credentials into a product you are just first trying out.

@marcusquinn said in Is there a way to set the LetsEncrypt email separately?:

So Superadmin's are Owners then? In that case I have about 20

Indeed! You can downgrade everyone to be an admin. The main difference between superadmin and admin are that superadmins is meant to be the person who has access to the server (and the one who set things up initially). Superadmin also manages the subscription and has acess to mail server logs. Admins don't have access to these two things.

Ideally, there is only one superadmin. We wanted to enforce this but migration from previous setups proved to be a bit problematic.

@murgero Thank you bro! I learned how to create and manage SSH keys via terminal today. I'm going to start learning how to do basic Linux Terminal Commands now. So when installing Cloudron, I should select Let's Encrypt - Wildcard and turn that to yes. Anything else that you recommend?

@Mightymoose There are two flavors of the WordPress app - managed and unmanaged (the former has blue icon and the latter has a grayish icon). Which one did you install? Can you try re-installing the app?

@girish This is an interesting observation. I was just looking to see if this was a real security threat or not, and I suppose it isn't but can offer a bit more privacy using the wildcard approach. Any particular reason why the Let's Encrypt wildcard support can't be done through the actual Cloudron wildcard DNS approach? Is there a way to support this? I'd really like to take advantage of a smaller DNS provider which has some great monitoring features included, but it isn't supported via any API by Cloudron yet, so if I go that route I can only use the Wildcard option, but those don't actually allow for the wildcard certificates.

Edit: Nevermind, I see why in the docs: "Let's Encrypt only allows obtaining wildcard certificates using DNS automation. Cloudron will default to obtaining wildcard certificates when using one of the programmatic DNS API providers."

So, it seems like giving the app a "relocation" by pressing the save button under the Location config tab & a quick Cloudflare proxy off-on, and then some time is the fix.

EDIT
So it is Cloudflare that is the problem and not Cloudron. Specifically their proxy

Hello! Sorry - yes inbound 80 is open. results of journalctl:

No journal files were found.