Solved web/mail certificate problems

[rockets]

I am trying to sustain a system with multiple domains using the LAMP app and also running mail for one of the domains.

Before moving to Cloudron, I had acquired certificates via Let's Encrypt. Now there are different certificates being used by Cloudron on my server. When I access the website by http://www.domain1.com, I now get back this message in one browser:

This Connection Is Not Private
This website may be impersonating "domain1.com" to steal
your personal or financial information. You should go back 
to the previous page.

Another has a similar page, but adds

NET::ERR_CERT_AUTHORITY_INVALID

Clicking on that message shows the following and more:

Subject: cloudron-2018-06-16T20:05:40.732Z
Issuer: cloudron-2018-06-16T20:05:40.732Z
Expires on: Jun 13, 2028
Current date: Jul 10, 2018
PEM encoded chain:
-----BEGIN CERTIFICATE-----
MIIDKzCCAhOgAwIBAgIJAJdNp4k9UOMIMA0GCSqGSIb3DQEBCwUAMCwxKjAoBgNV

For now, I've removed ".htaccess" to eliminate any redirect issues.

I am concerned that there is a conflict between the certificate that I originally obtained for two domains, and the new one obtained automagically by Cloudron, hence the ominous messages. To complicate matters, I now have SMTP+IMAP running, presumably with authentication, and a related if not identical Cloudron certificate; I'd like not to kill that now.

Is there a way I can use either my original or new Cloudron certificate so that I can have both usable mail and websites??

I assume after I get this resolved, I can go back to redirecting bare domain to www.domain or vice versa.

If anyone is suspicious, yes this is related to my earlier query at
https://forum.cloudron.io/topic/1389/hosting-many-domains
and this is why that one is not marked as resolved.

[nebulon]

Hi there,

Cloudron supports LetsEncrypt automatically for all apps and provides certificates for the mail server. You should not need to do anything regarding those on your own. In Cloudron there is a nginx reverse proxy setup, which is the SSL termination point, so apps itself operate locally without SSL.

For the redirect, we will release a proper way to handle redirects like the common www.domain.com in the next release, see https://forum.cloudron.io/topic/1392/what-s-coming-in-3-0 Then this will also have the certificates correctly setup out of the box.

[rockets]

A point of clarification. Unfortunately, I had the certificates before going to Cloudron because I was trying to do Postfix and Dovecot on my own, which of course proved problematic. The websites were already alive and stable. I dismantled this so that I could let Cloudron take over. I did not add new certificates after install Cloudron.

So now I have mail running, but the websites are now advertising themselves as untrusted. I am not going to send mail to new contacts from the working mail address because they are going to check out the websites and conclude the business entity is a fraud.

Apparently, there is a way to revoke my original certificates. ("certbot revoke --cert-path path-to-old.pem") Would that help, or should Cloudron have already overridden the prior certificates?

[nebulon]

Hm, I was not aware that, unless the rate limit for a domain is exceeded, one cannot get new certificates from LetsEncrypt. If you reconfigure an app, which has the certificate issue and then look at the app logs, do you see any errors regarding certificates? (Please download the whole logs from the logs viewer in the Cloudron dashboard, there is a button for that on the top)

[rockets]

Affected app is a LAMP instance. I did a reconfigure just prior to taking log. (In this case, unchecked the box "Enable automatic daily backups".)

I uploaded same log file twice; was unclear how to confirm that the upload successfully completed. I don't feed any feedback; I'll assume upload succeeded.

[nebulon]

Unfortunately it does not seem to have uploaded. Can you send the logs to support@cloudron.io ?

[rockets]

Okay. I've sent the log in mail to support, and provided additional background and specifics.