Cloudron Forum

@nebulon
as said, there's no real problem right now, still I don't understand the behaviour and am curious.

you're talking about accessing the Cloudron through entering the IP (192.168.x.y) in the browser?

It's clear that this wouldn't work and this is not what I'm doing, it's a little more complicated:

the PC I'm accessing from, is in the same network segment than the cloudron (192.168.x.z). OpenVPN is active, the OpenVPN service is on a second cloudron outside in the internet still, when entering the URL (https://my.domain.*), the fritzbox page shows as soon as I connect the PC to a different network segment (192.168.y.z) everything works!

I don't understand why. Shouldn't the use of external VPN service make the internal source IP invisible?

@subven 🤦

wordwrap!!! the problem was staring me in the face! But I could not see it because i did not scroll to the right...

Thanks for the help!!!!

I took a cert and key file from another server, and renamed the default cert to be whatever the error wanted.
first thedomain.com.cert, then thedomain.com.key. and so-forth until it loaded. It is working now! .

@girish Great.

Yes, thanks for asking, it was a painful several hours during the wee hours of the night figuring out how to generate a set of new certs that would bring the UI back enough to regenerate them all.

I ended up using one of the 3rd party CLI tools for LE called getssl.

Thank you, the same happened with a browser that had never opened the site, I think I will continue checking.

@nebulon Sorry for the late reply, this topic has been resolved with your support. It was a misleading page. I will start a new thread on the backup issue. Please mark this as done or delete. All solved here. Thank you for your help.
https://forum.cloudron.io/topic/6895/the-site-is-deceptive/14?_=1661248303629

Nothing that mentioned the _ (wildcard) cert at least, which is part of why I'm stumped. I don't know what is creating it, or where to look.

@humptydumpty Thank you, that has actually worked!

@girish this was more for Nginx not starting, including 0 byte files.

Happy to mod the FR to be more inclusive. Done.

@girish said in VULTR Let's encrypt renewal error 401:

[401] {"error":"Unauthorized IP address:

Thank you sir. You are legend.

@girish That did the trick, I appreciate it.

You can add custom certificates as mentioned in https://docs.cloudron.io/certificates/#custom-certificates

@BrutalBirdie yes, this was a bug in 7.0.x. certificates of apps are "deleted" after 6 months or so. when this happens, the nginx config is left dangling. This is fixed in 7.1 with https://git.cloudron.io/cloudron/box/-/commit/5382e3d8321ddb96817f50ab94e9da56258b11e9

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?