https://securityheaders.com/

And some information about, who, why and how...
https://securityheaders.com/about/
https://securityheaders.com/faq/

@girish Had this issue too. Will drop a mail later today.

@AgentM which dns provider are you using? If you go to Domains -> Renew all certs, can you check the logs as to why it is it not getting the certs?

@andreasb said in cloudron ssl behind fritz!box:

Only when trying to access the cloudron UI through "my.xxx.yyy", all browsers I tested (firefox, edge, opera, brave) throw "insecure connection", and the certificate presented is the self-signed one of the fritzbox.

That's because your fritzbox is answering on port 443 instead of passing it on to Cloudron.

Disable web/management access to the fritzbox from the internet side (or change the port), so that 443 is available to be forwarded to the internal Cloudron IP.

@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

Problem solved. I deleted ALL config files and restarted the server.

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