Cloudron Forum

@Mamouti if you need (smallish) changes to the packages, feel free to submit MRs . All the packages are at https://git.cloudron.io/packages/

Thank you. I will try cloudron-support --troubleshoot next time.

Turns out the certificate seller emailed the wrong private key. @joseph thanks for the heads up.

Can you check if basic DNS resolution works ? See https://docs.cloudron.io/troubleshooting/#dns-resolution . Also, are you hosting at home or some private network (these have complications with loopback checks).

Thank you @nebulon ... it's awesome timing , thanks for the share! I guess that should be considered a solved problem for the future then.

Thank you for taking the time to investigate. It seems like there are several tools that have successfully implemented DNS-based Let's Encrypt challenges and DNS-based automation for deSEC. If the higher TTLs really are a problem, could it be possible to just restrict the usage of deSEC to wildcard DNS + Certificate usage (wildcard A/AAAA record + DNS challenge for Let's Encrypt)? These records only need to be updated very infrequently if at all. I personally run my cloudron instance behind a VPN, which is why I am unable to use the HTTP based verification. deSEC is a very special provider that I think is worth putting the effort into supporting. AFAIK It's the only donation-run/free, European provider with DNSSEC support currently included in Cloudron. Hetzner doesn't support DNSSEC. It's also (likely) one of the most privacy respecting providers available. I have also made a post on their forum. Maybe some creative ideas will come about.

@timconsidine said in Domain cert renewal - when ?: I don’t even remember my own name. Your name is Timcon S'idine, just in case.

Glad it worked out in the end

Thanks for sharing that and glad it worked out in the end.

Disabling Cloudflare seemed to work. Thanks.

So wildcard is only for subdomains of a domain. The domain.com record is not covered by wildcard. But yes the instructions probably sound like both *.domain.com and domain.com are in fact managed by Coudron, but all I can tell you that unless an app is using a domain, the certs will not be renewed. Maybe we can be smarter about this in the future, but to solve your problem this is what is required. Note a redirect to an existing app will also work.

@msbt yes, exactly. It will also get into error state only after some time (because it will retry a lot)...

@girish Thank you, Cloudron team, once again for the great work. After updating Cloudron, the problem is resolved. Thank you very much.

@girish Confirming that the issue was unrelated. It was very helpful to be able to manually refresh certificates and then view the log files. Thanks!

@dreamingofadmin I think first step is to get access to your dashboard. In Cloudflare, do you have an entry for my.domain.com to your server IP (DNS A record) ? If not, add this manually. Wait a bit. Access https://my.domain.com . If it's asking to accept self signed certs, accept them. Once in dashboard, Domains -> Sync DNS . This will add all the DNS entries. Then, Domains -> Renew all certs. Please let us know what is failing and where.

@girish Thanks! I hadn't thought of checking the certificate in the browser - yes, all is good.

@THI_Staff it's not too uncommon an oversight. I made an internal note for dev. Maybe we can notify Cloudron admins if the Domain API keys are not working anymore. We do this check when adding the domain, but maybe we can do this check periodically. This will also catch API key change etc.

@luckow yes. See this comment - https://forum.cloudron.io/post/83868 https://git.cloudron.io/cloudron/box/-/commit/0dfadc59228978f82ae3aa2ba4be2b421e785e02 was the fix . You can always apply it locally in /home/yellowtent/box/src/dns/digitalocean.js . Then, systemctl restart box and renew all certs.

@girish said in Cert renewing failing: @visuex are you the same as @cpa ? Nope, not me!

Yes this is done.