Cloudron Forum

Have you checked the logs already? Go to Domains -> Renew Certs . That will show the logs for the renewal . Which DNS scheme/provider are you using? Manual/Wildcard or one of the programmatic ones?

@girish IPv6 is enabled on the server but not "in use", since some domains that are added manually don't have v6 and I don't want to run into troubles. Those are mostly Hetzner Cloud servers.

this issue has been resolved and the certificates have been renewed and access to the site has been restored. there was an issue with the server dns settings which was causing the certificates to not renew.

Hi @fbartels You're right, double checked and it always defaults to smtp. instead of .my When manually changing on both PC and Mobile, the SMTP accounts can be added without the certificate error! Thanks Everyone!

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

Apologies and correction. Cloudron's functionality works just as intended. The problem is in docs in major sites and hence chatGPT as well (which I used to troubleshoot that). All of the docs, except for NameCheap (thanks, guys!) says that the correct way to combine crt files - is just do cat .. > final.crt which lead to one problem: -----END CERTIFICATE----------BEGIN CERTIFICATE----- On the line 37, which, absolutely reasonably, brakes any SSL parser. Correct way to join CRT files is: cat STAR.*.crt > ssl-complete-bundle.crt && echo >> ssl-complete-bundle.crt && cat STAR.*.ca-bundle >> ssl-complete-bundle.crt And you can check if it is valid than with openssl x509 -noout -in ssl-complete-bundle.crt -checkhost test.`basename STAR.*.crt | sed -E 's/^STAR\.([^.]+(\.[^.]+)?)\.crt$/\1/'` Guess, it might make sense to document it.

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!

Closed due to inactivity

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