Cloudron Forum

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

@d19dotca Ah, I see this on our server as well. It seems that this is printed for all incoming mails because Haraka tries to transfer mail to Dovecot via TLS (via LMTP). Disabling SSL removes the message. Since the message transfer is internal, it's fine. I have pushed the fix for next release but the message is safe to ignore.

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

This has helped me in version Cloudron v7.3.2

@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

So, it seems like giving the app a "relocation" by pressing the save button under the Location config tab & a quick Cloudflare proxy off-on, and then some time is the fix.

EDIT
So it is Cloudflare that is the problem and not Cloudron. Specifically their proxy

@girish Will do. It's actually not the first time I've run into the problem and a re-fresh of the API credentials solved the problem, although this is the first time I specifically observed that it was a 500 error vs. a 401.

Thanks for the reply, @girish.

Doing a

host -t NS

lead me to find that the NS records were not added in DigitalOcean.
Adding them in fixed the problem.

@girish thanks for the info! 😊

@bangden07 Ah, that's a smart work around! I just noticed that you had SSL issues on the root domain. The wildcard cert only covers subdomains i.e *.foo.com but not foo.com. Cloudron still has to get normal certs for foo.com. I guess after a week, you can remove the cloudflare proxy.

@girish I'm always amazed at how quick you guys on these things, thanks for fixing that so soon! 🙂

Thanks for the thorough reply @girish , I've updated my DNS accordingly and the certificates renewed! I'll figure something out with the Github Pages (or self host on Cloudron!)

@iJoel You can do this by simply concatenating the intermediate and CA cert files into a single cert file.

So, in the '.crt' file which you upload to Cloudron, it will have:

-----BEGIN CERTIFICATE----- the *.foo.com certificate -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- intermediate cert -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- root cert if any -----END CERTIFICATE-----

The ordering of the certs is important above.