@eivlil01 I assume you have certbot running elsewhere (and not on the Cloudron server) and then you copy over certs or something?

In that case, the copy script can put the certs under /home/yellowtent/boxdata/certs. It's important that you name them as <appdomain>.user.cert and <appdomain>.user.key and then systemctl reload nginx.

@jordanurbs said in SSL Certificate by Cloudron not trusted:

One thing that might be an issue, what about users whose browsers all still carry the old cert settings? I can't have everyone reset their hsts settings.

I think most likely this issue is only on your machine and not on others. Atleast, it works for me fine across multiple devices.

@jdaviescoates nope, just regular domains, not sure why but will just wait and see I guess

@niko You have to convert the app into a Cloudron app for all this to reliably work. We don't support running/installing other things other than Cloudron on the same server. This is because Cloudron will overwrite nginx configuration etc from time to time (for example, updates bring in new configuration).

If your app has a Dockerfile, you can make it a custom app with not too much work - https://docs.cloudron.io/custom-apps/tutorial/ . Custom app will automatically get certs, backups, restore, clone features etc with no extra work. What framework/language does your app use?

Since, we got so many support tickets about this already 🙂 I will paste what I said in the other thread.

Let's Encrypt have started using R3 as the intermediary cert - https://scotthelme.co.uk/lets-encrypts-new-root-and-intermediate-certificates/ . This cert has issuer text slightly different. Since the text has changed, Cloudron tries to renew the certs too early and this results in the above notification. The notification can be ignored since it's a false alarm, the certs and sites will be fine.

There are two ways to fix this:

Update to Cloudron 6 - you can go to Settings -> Check For Updates and then Update. It will give a notification that it is unstable. It's reasonably safe to update, the notification exists because we roll out updates very slowly to keep support manageable for us. Please expect some downtime (like 10 mins) since the update re-configures all the docker containers.

Alternately, you can make this one line change in your current Cloudron version - https://git.cloudron.io/cloudron/box/-/commit/3e62f1913ab05750a343c197c519d38bf17d5b3b . The file is /home/yellowtent/box/src/reverseproxy.js and then systemctl restart box.

@girish feeling lazy, will wait for the official update 🙂

So I'm pretty convinced the issue was the way I wrote the CAA records. I think my DNS provider didn't need the double-quotes in there and it caused issues. Reason I say that is because after introducing the CAA records, I suddenly had the certificate renewal errors.

Then when using a DNS check tool and I looked up CAA records for Google and Mozilla and more, none of them had the double-quote in there, but mine did. So I am sure that was the issue, as everything worked fine again after I removed the double-quotes.

I suspect the double-quotes was being taken literally as a string and so letsencrypt.org is not the same as "letsencrypt.org" in the DNS CAA record. I was able to later find the logs I had seen in the early morning which shows the following which confirms my conclusion: CAA record for <domain> prevents issuance.

So for anyone who comes across this later, make sure you're not using double-quotes I guess. haha.

@wu-lee do you know why it had failed to renew previously?

@girish & @nebulon - It looks like it didn't fix it (the steps from the other page), as I still see it in the logs at 2020-10-27T18:06:51.000Z which is UTC and translates to 11:06:51 AM Pacific Time, well after I followed the earlier steps which was as of 10:54 AM Pacific.

@girish Sorry for the late reply, I the default forum settings were to send me email notifications once a week, I have changed that to daily.

I was trying to use the self-signed certificate for all apps.

I have gone ahead and followed the steps in the blog article I linked to and was able to upload the full CA and web server cert chain to Cloudron and after getting the root certificate authority into all the devices accessing Cloudron everything is working well from Windows and iOS based devices.

It looks like Apple is going to be decreasing the certificate lifetime further down to 398 days so you may want to lower the lifetime down to a year to get ahead of that change.

@andrewj720 Looks like DNS is not working on your server. You can also try host cloudron.io etc, I guess none of it working?

Can you check if your cloud firewall allows outbound port 53 UDP ? I think there was a post on this forum some time ago that someone had it blocked in AWS security group by mistake, for example.

Some technical details on the issue. In 5.6, we allow the mail server name to be set and for this we introduced a database field called mail server name. For some reason, if an update only went through half way, the database migration scripts did not complete fully and this mail server name field is not populated in the database. This in turn results in the mail container not getting the correct certificate.

The first command /home/yellowtent/box/setup/start.sh is running the database migrations. The second command is restarting cloudron code. The third command is re-configuring mail container with the correct certificate.

@marcusquinn said in Lets Encrypt renewal time:

Without looking at that screen again, maybe it wasn't clear it should recommend using the root domain for that input?

I think many people start out just like you did and then move it to the main domain. We don't put the recommendation as such because I think it can be scary to throw your root domain and API credentials into a product you are just first trying out.

@marcusquinn said in Is there a way to set the LetsEncrypt email separately?:

So Superadmin's are Owners then? In that case I have about 20

Indeed! You can downgrade everyone to be an admin. The main difference between superadmin and admin are that superadmins is meant to be the person who has access to the server (and the one who set things up initially). Superadmin also manages the subscription and has acess to mail server logs. Admins don't have access to these two things.

Ideally, there is only one superadmin. We wanted to enforce this but migration from previous setups proved to be a bit problematic.

@nebulon Like I said, I thought it would be an issue for a particular client, but it's not!

However, only as long as the config stays as it is; if you ever strengthen it by adding the "includeSubdomains" directive in the HSTS header (as it is advised sometimes in some of the readings I found for better security), you could cut access to subdomains that are not managed by Cloudron and cannot do TLS.

The typical fictional scenario, if the config ever changes, would be:

www.watering-plants-automatically.cloud is a website from a company that offers to manage clients' gardens; the designer of the website hosts it on its Cloudron instance for the client.
The company already has stuff they host on subdomains, and won't relinquish access to the DNS server for security reasons. However www and the root domain both point to the Cloudron server IP, so Let's Encrypt works fine in "Manual" mode in the Domains & Certs tab of the designer's Cloudron; An end-user visits the website, decides to sign up and pay for their new fangled tool, which is hosted at myplants.watering-plants-automatically.cloud. This subdomain points to the IP of the appliance that manages the users' gardens. This is an old, crummy box that won't allow TLS, because it's almost an antic at this point; The user cannot connect to their tool, and throws an HSTS error.

It's not an issue yet, but it might be something to think about if you ever consider changing the configuration (let's say, if you decide all domains with a wildcard cert should have includeSubdomains in their HSTS headers).
Security-wise, it makes a ton of sense: let's say you type http://www.domain.tld in your browser.

The server 302s you to https://www.domain.tld which has the HSTS header and "includeSubdomains" You later type http://mail.domain.tld in your browser: the browser will immediately connect to https instead, avoiding potential MITM attacks.

Pretty powerful, but it might be an issue in this particular case where some subdomains shouldn't be covered.

I initially thought I read in the docs that the HSTS config was such that all subdomains were included, and I remember that before using Cloudron, for this specific client, I set the header to "includeSubdomains", which promptly disallowed access to many tools I do not host because they didn't support TLS on them, if the user visited the main website before.

So yeah, feel free to close that topic, because it's not an issue unless you decide to change the config server-wide 🙂

@girish Yes I did, and the problem with the certificates is now fixed. Thank you!

@murgero Thank you bro! I learned how to create and manage SSH keys via terminal today. I'm going to start learning how to do basic Linux Terminal Commands now. So when installing Cloudron, I should select Let's Encrypt - Wildcard and turn that to yes. Anything else that you recommend?

@Mightymoose There are two flavors of the WordPress app - managed and unmanaged (the former has blue icon and the latter has a grayish icon). Which one did you install? Can you try re-installing the app?

@girish Hi, everything is ok now, after my s3 storage provider fixed their S3 error SSL certificate .
Thanks