@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.

I have also added Service events in the event log for the next release. So, this way, we can know if the service was automatically restarted after cert update.

@nebulon indeed, thank you!

For the sake of future users, I guess it could make sense to add information about where to take token and full command line for cURL into the documentation, but it's not directly related to the case.

@girish Perhaps take a look at it from the pull perspective vs push.

Maybe even originating the refresh from the mail container side, triggering the others.

@humptydumpty That's right. No way to get wildcard certs with wildcard DNS.

To get a wildcard certificate, one needs to be able to program/automate the DNS. Let's Encrypt (acme) protocol requires one to programmatically setup TXT entries as part of getting the certificate. With a wildcard DNS, we have to now way to automatically setup those entries.

The protocol for normal certificates has a "http" based flow which allows it to work with a single wildcard entry.

@nj yes with the folder in place there adding the -r to solve this makes sense, however the initial issue is that this folder should not be there in the first place. As the name already suggests, I guess this was just some intermediate manual action to stash certs. Essentially if you don't actively use files in that folder then just delete it to solve this for future releases.

@scooke Interesting. The certificate and the PTR record check shouldn't have anything to do with each other. The PTR record check is really just dig -x IPADDRESS . Can you try that say 10 times over the course of an hour with your VPS server IP and see if it's consistent?

As for old certs, they are indeed preserved forever even if you remove the domain from Cloudron itself but the latest release will now clean up obsolete certs which are 6 months old.

@americankulak Ah! thanks for the update.

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

@humptydumpty Yes, correct. Server restart won't fix the issue, have to restart the service explicitly (since it copies over certs).

@humptydumpty haha! whoops - on it - great find!!!

how embarrassing. You're absolutely right. I was searching after ghosts.

@girish thanks a lot for your answer.i appreciate.

@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.

@girish Already solved this problem myself thanks

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

@girish Gotchya, ok. Makes sense, thank you

@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.

@nebulon said in Managing SSL certs via Cloudron CLI:

you have to "forget" the page in your browser

yes, or visit the site in an incognito session. Clearing these entries from the profile in Chrome is slightly more complicated, but doable as well.

https://msutexas.edu/library/clearhsts.php

@mastadamus If you use namecheap API, you don't need port 80. This is because Cloudron will use Let's encrypt DNS automation to get certs. Note that this will require you to sometimes type "https://" explicitly in some browsers because some browsers will default to connecting on port 80 and then the redirect will take it to the https site. In addition, Cloudron has HSTS, so future connects will directly be to 443 and no redirect dance.

@eivlil01 said in Using my own certificates:

@girish I'm using the DNS based challenge, but for a wildcard entry.

Cloudron only supports http based challenge for wildcards, or DNS based challenge but then it creates one entry per app.

Ah, I see what you are saying now. So you have a wildcard DNS entry pointing to the server but also use DNS automation to get wildcard certs. Indeed, Cloudron does not support that.

@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

@niko You have to convert the app into a Cloudron app for all this to reliably work. We don't support running/installing other things other than Cloudron on the same server. This is because Cloudron will overwrite nginx configuration etc from time to time (for example, updates bring in new configuration).

If your app has a Dockerfile, you can make it a custom app with not too much work - https://docs.cloudron.io/custom-apps/tutorial/ . Custom app will automatically get certs, backups, restore, clone features etc with no extra work. What framework/language does your app use?

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?