Cloudron Forum

Just wanted to say I've also hit just this issue. Cleaning up the nginx app config files did the trick but I wonder if this can be avoided in the future? Or may be it has already be addressed and I'm only hitting it because of some legacy stuff from previous Cloudron version? (this instance is currently running 7.5.0 but hasn't had a fresh install in a long while).

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.

@nebulon Many thanks, @nebulon and @girish . The concern wasn't so much that I could not figure out what the status of my certs were external to Cloudron, but more that it would be nice if the area of the dashboard regarding certs would, as a matter of course, just say "You have 47 days remaining, and Cloudron should automatically update your certs in 17 days."

And, if I do mash the button to manually run a cert update, it would be nice to get a response in the dash that says "Success! New certs will expire in 90 days!" (Or, whatever it would say.)

I was mostly surprised that I got a certbot email saying I only had one day left, making me wonder what was up. (I did do a domain registration move at some point, and possibly other things that could have somehow upset the automatic update process. So, this isn't a bug report.) Not having a simple UI response to the act of hitting "update certs" (and instead being dumped into the log) is all I'm poking at.

I don't know how long my personal instance has been running (a month or two now), but it has been a joy. Thank you.

@robi yes, select Custom Wildcard Certificate. That will generate a self-signed certificate automatically.

@girish thank you, the output is different now, so I hope that will work.

I took that API call from my forum request earlier, but I guess there was a misunderstanding the API call example was for the specific domain, not to update them all.

Thanks for your assistance!

@girish Magic, that seems to have worked - thanks!

Maybe worth considering adding this advice to the email notifications?

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

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.

This should hopefully be fixed in Cloudron v7.3

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