Cloudron Forum

Hi @james
now switched to Hetzner Cloud DNS, and the renewal worked. Thanks!

Having used the manual wildcard config forever, I however still don't understand, how the first set of certs had been issued, that expired back in February.

@james said:

Please don't post pictures of copy-pasteable text.

ok

Hi @james

• 'cloudron-support --troubleshoot' did not throw any error
  
• DNS is not automated for this Cloudron, all entries are set manually at the registrar's web UI
  Does that help?

ps all other app certs seem to be renewed correctly, I haven't observed any issues here

sorry for replying late:
there's no cron job involved, maybe that's the issue?
Everything needs to be done manually:

• nginx-config whenever Cloudron box is updated, in an SSH session
• running the script to start notify_push whenever NC app is restarted, using a terminal from Cloudron UI to access the docker container

after running the start script, and using your ps-check command, I see a corresponding process. Additionally, running <occ notify_push:metrics> in a Cloudron terminal shows it works, all indicated stats are up-to-date and change over time.

• I'm running Adguard Home to support DoT/DoH for Clients
• limiting DNS to allowed clients is setup via Cloud Firewall, not within Adguard, ports 53 + 853 there are open for selected source IPs
• adding a new alias for a dedicated client ('client1.gate') works and a valid cert is deployed in /etc/certs within AdGuard docker container
• after some configuration changes and tests, I've been (again) adding the alias *.gate.mydomain.tld, which has been existing before and been removed again
  => creating the alias in Cloudron UI does not throw any error
  => however, an expired cert is used: when now accessing the AdGuard UI, an error message is visible on top saying
  
  =>I then renewed all certs via Cloudron Domain Mgmt, and regarding *.gate.mydomain.tld, the corresponding renewal log shows

2026-04-30T12:04:23.234Z reverseproxy: ensureCertificate: error: no http challenges

Am I facing the issue @girish described here?
Any idea how to fix this?

Thx in advance!

I've been following the instructions in threads cited below, and it looks like notify_push is up and running

1. configure nginx https://forum.cloudron.io/post/48343
2. run notify_push via script https://forum.cloudron.io/post/48298

Dear all
just to confirm: the update broke my installation, and the documented recovery procedures (https://docs.cloudron.io/packages/nextcloud/#fixing-a-broken-install) didn't work. The logs indeed showed issues with groupfolders. I restored backup and will be waiting for a second try

cleaning up the docker images as mentioned above basically works.
On my instance, there however are two app docker images that are much larger than the others:
rallly (almost 6GB), loomio (>6GB)
Is this size "normal"?
Is the "normal" size of the apps' docker images documented anywhere?

thx, @girish, this made the difference, I'm in now
I've been trying admin with pw changeme, not admin@cloudron.local

I installed documize and try to login using the credentials from the "first time using" doc, as well as a cloudron user - login however is not possible, the trace shows a 401 "Unauthorized" on this target URL: https://documize.mycloudron.domain/api/public/authenticate/ldap

Ideas, anyone?

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

thx for everybody's inputs and sorry for my delay - took some time testing, and here's my wrap-up.

on the Fritzbox

• external access is deactivated in two places: remote administration, FB "Fritz!Box-Dienste", application access ("Heimnetz, Netzwerkeinstellungen")
• the Cloudron is configured as an "exposed host"
• DynDNS is configured and working correctly, the provider is DynV6.com
• DNS rebind protection: exemptions configured for the Cloudron ("my.*"), as well as for the apps running on the Cloudron

as a result, access from internet IPs works and the Cloudron as well as all apps are reachable.

Still, if accessed from a computer within Fritzbox-Network (192.168.x.y), neither app, nor the Cloudron respond. Instead, the already mentioned Fritzbox access page shows.

So it's not perfect, but usable and my question is answered.

@subven said in cloudron ssl behind fritz!box:

You said you do not use a DNS provider

not one of the "automated" ones like Cloudflare but Cloudron's "custom" way. but of course, the domain is registered

@subven

• no, I'm not using myfritz,
• I tested both configurations regarding the remote maintenance function, make fritzbox accessible from outside and not - this did not change anything.
• yes, the cloudron is on a fixed IP
  

@nebulon yes, had read that in another thread before, and still it doesn't work in my case - no idea why not.

• The cloudron is the one and only exposed host on the fritzbox
• the dyndns-service seems to work properly: the ip there is regularly updated, and the ip is correct.
• connection through SSH using the external IP as well works.

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.

I had been wondering if naming plays a role. @nebulon, you did not by chance change the fritzbox's name from the default "fritz.box" to sth else?

@subven

@subven said in cloudron ssl behind fritz!box:

As a german, I know what a FritzBox is I think you're still at the wrong path since the exposed host exactly does what it should and the webserver of the Fritzbox does not interfer there.
There is enough information within this thread to fix your problem.

1. there were others asking, please excuse if I am wasting your valuable time with text that you deem not appropriate
2. is it visible/ does it matter you're German?
3. apparently, the webserver of the Fritzbox does interfere, as the fritzbox certificate is presented when accessing the page through a browser. This precisely does not make much sense to me either, but I don't understand how and why this happens.

@subven said in cloudron ssl behind fritz!box:

Cloudron does not work without a domain you own or at least can controle.

As said before, the domain is registered and I do control the DNS

@nebulon and one more question: when accessing the cloudron using the internal ip (https://192.168.xxx.yyy), it says "you are seeing this page ... no apps configured for this domain." This is normal, isn't it? the certificate presented here is the self signed one (default.cert). I thought this as well is expected behaviour and does not mean that Let's Encrypt cert renewal doesn't work. Is that right?

@nebulon (and @girish, @subven): fritzbox is a dsl modem that can be accessed from "outside". as @nebulon mentioned, machines from the internal network can be exposed (which is what I did). if the machine is accessed through https however, the first certificate presented seems to be that of the modem, which by standard is a self-signed one, and not accepted by browsers. It however is possible to manually upload other certs to the modem (see this doc). I don't use any DNS provider, a custom setup, the domain is registered and forwarding works properly through dynv6.com. looking at the nginx certs within /yellowtent/platformdata, their timestamp seems to be update each day - and I assume that this is a sign that cert renewal from the cloudron works, right?

Dear all

one of my cloudrons is behind a fritzbox in a personal (sub-) domain. Although dyndns is set and working correctly, the cloudron isn't accessible:

• connection through ip from inside (192.168.x.y) is possible, but the cloudron obviously has no apps installed in this domain.
• connection through the domain name fails, because the fritzbox cert presented is self signed and does not include the domain name. Then, I found the (Let's Encrypt?) certificates for the cloudron platform in /home/yellowtent/platformdata/nginx/cert, intending to manually upload it to the fritzbox. This didn't work. The reason, I assume, is that fritzbox is expecting RSA private keys and does not accept EC keys. Am I missing out anything?

How can I make available the cloudron domain certificate to the fritzbox?
Any other ideas?

Best
Andreas

@girish thx for your support, rebuilding the containers did the job: after restarting, both Redis + NC are up and running again!

@ApplegateR didn't read that anywhere. Let me know if you'd like some information from that machine. If not, I will go back to the snapshot in that case later today.