Solved Custom Wildcard Certifiate not applied to email

[Peter Newman]

We're using custom wildcard certificates for all our domains. When we made this switch, email didn't change to using the new certificate, and kept using the Lets Encrypt cert.

This cert has now expired. I've found various issues in the past similar to this, and tries those fixes (add new domain then remove it, restart email service), but the issue persists.

[d19dotca]

This post is deleted!

[girish]

@Peter-Newman Ideally, it should have been automatic, let me investigate why it didn't switch over automatically. But a quick workaround is to go to Email -> Select domain and then Disable Incoming email and wait for 30 seconds or so and then Enable Incoming Email (so we are just turning it off and on). That should copy over the new certs. Can you please try?

[Peter Newman]

@girish OK, I've just tried that (for the main domain), but I'm not seeing any change.

This is affecting both incoming SMTP (so is domain agnostic at that point), as well as IMAP (which I assume also uses STARTTLS or equivalent before using a specific domain login).

If it's helpful, I'm familiar enough with sysadmin to be able to access the docker container command line and such, to get more information/apply changes.

Edit: I also just tried cycling the mail service, in case the change hadn't applied yet.

Edit: I also just tried disabling email across all domains (which did disable the mail service, based on the SSL test), but as soon as I re-enabled it for the main domain, the same error occurred.

[girish]

@Peter-Newman Looks like maybe there is some bug then, let me test and get back.

The mail container essentially uses the files under /home/yellowtent/platformdata/addons/mail. There are two files here tls_cert.pem and tls_key.pem. I guess these files wrong?

For the moment, just to keep your setup working, you can do this:

• Copy the correct certificates into the above files
• Then docker restart mail. Don't use the Cloudron UI to restart mail container because that clearly has some bug of copying the incorrect certs.

Can you tell me if the workaround works? If possible, also please note what certs were there originally in that directory above.

[Peter Newman]

@girish Thank you, the workaround worked.

I grabbed out the certs that were there before. I don't know if it would help to attach them, but they look like standard Lets Encrypt Authority X3 issued certs.

[girish]

@Peter-Newman said in Custom Wildcard Certifiate not applied to email:

I don't know if it would help to attach them, but they look like standard Lets Encrypt Authority X3 issued certs

Thanks, that's what I wanted to know.

[girish]

@Peter-Newman I think i found what the issue is. I guess you were using normal Let's Encrypt certs (i.e not wildcard Let's Encrypt) before switching to your custom Wildcard, correct?

[Peter Newman]

@girish Yes, that was the case.

[girish]

@Peter-Newman I opened https://git.cloudron.io/cloudron/box/-/issues/724 . Hopefully, we can get this fixed in the coming release.

[Peter Newman]

Great, I'm looking forward to it.
So you know, the old certificate got put back into place and I had to re-apply the manual change.
Do you know what circumstances cause the cert to be reevaluated? For example, adding applications? Or is it just something that will happen on a regular schedule?

[girish]

@Peter-Newman said in Custom Wildcard Certifiate not applied to email:

So you know, the old certificate got put back into place and I had to re-apply the manual change.

I will try to make a fix in the coming day or two and maybe you can apply the patch already before we release 5.5. I will keep this post updated.

[girish]

@Peter-Newman This is fixed in 5.5. Can you please update your Cloudron and let me know?

[Peter Newman]

@girish I'm still getting the same behaviour, and having to reapply the manual change whenever a app updates.

[girish]

@Peter-Newman Just to double check, you chose the custom certificate provider in Domains view correct? Are you able to drop me a mail in support@cloudron.io, so I can look into this further?

[Peter Newman]

@girish Actually, I just double-checked and the update didn't install. I'd seen it was in the process of installing, then had finished, so had assumed I was on 5.5, but I'm still using 5.4 . I've retriggered the update process and will test again if it finishes.

Edit: Hmm, it ran and again failed, but I refreshed the page before clicking to get the logs, and the nightly scheduled update had started! The displayed message was something like "failed with signal null".

Edit: Ah, I was able to grab the log (and the log of cloudton-updater) and found the problem. A little while ago, I'd started installing a tool used by my hosting provider, without realizing it was going to trigger an apt update etc, which Cloudron specifically warns against. I broke out of it, but it seems I left dpkg with unconfigured packages. I've fixed that now, and am trying the update again.

[girish]

@Peter-Newman Did you manage to update?

[Peter Newman]

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