Changing from wildcard (*) cert (using DigitalOcean DNS API) to subdomain-specific certs (using the Wildcard DNS provider option). How will this impact the main my.<domain>.<.tld> for mail connections?

[d19dotca]

Hello,

For a few different reasons, I am moving away from the DigitalOcean integration for Cloudron DNS and to a Wildcard DNS option. I have successfully migrated most of the 16+ domains, but have left my own to last. Unfortunately I just thought of something and would like some input before I make the change...

Right now my primary domain for Cloudron is using the DigitalOcean API for DNS so it's getting a wildcard certificate. All the clients who use the Cloudron mail server are currently pointing to mail.<domain>.<tld> which has worked well via the CNAME record (since mail. is the standard practice for mail server names rather than "my"). However, I suspect this only works because of the wildcard (*) certificate on the primary domain? Is that a fair understanding, or am I incorrect?

I am just worried I may need to reach out to all of my clients if I made this change to have them update from mail.<domain>.<tld> to my.<domain>.<tld>. Do you think this will be necessary too? Worried if they don't, they may get SSL certificate errors since they're trying to connect to mail.<domain>.<tld> but it's actually resoling to my.<domain>.<tld>. What do you think? Or does the CNAME DNS record somehow resolve this? I think it'll be an issue, but just want to see if I'm overthinking this.

[nebulon]

As far as my understanding goes for that setup, the CNAME indeed works here due to the wildcard SSL cert served up by the Cloudron reverse proxy.
Moving to a different DNS provider integration then does bring up the question you are raising then, since only a programmable DNS provider will be able to perform the Acme2 challenge for a wildcard cert. So using the wildcard DNS provider will only allow your Cloudron to get non-wildcard certs and thus the CNAME trick will fail.
Maybe other DNS providers would be an option for you instead of DigitalOcean?

[girish]

Yes, mail clients will check for the mail.domain.tld cert and it will fail now once the wildcard cert goes away. The mail container has the same cert as the dashboard (this is the reason why it also has the my.domain.tld for mail setup).

(You didn't bring it up, but maybe we should rename this mail server name to mail properly in a coming release. I opened https://git.cloudron.io/cloudron/box/-/issues/721)

[girish]

Also, any reason to to move away from a programmatic API? Some limitation in Cloudron or something else? Maybe you fear that the token in DO controls everything in DO (this is one of the major downsides of DO) ? I can recommend Cloudflare or Route 53 for this because both these have tokens that can be restricted to domains. I think Namecheap has an IP based restriction as well.

Not ideal, but how we solved it in the past with DO is to create two separate DO accounts One for DNS stuff and other for the servers. You can create as many DO accounts as you want to split the DNS. Again, not idea but it's what it is.

[d19dotca]

@girish That would be ideal! In fact if that can come in the next couple of months, I'll hold off my own DNS change until that's there. Because the whole "my." doesn't really conform to the standards that people expect when they need to enter in their server names for a mail server. I'd definitely love if Cloudron could use it's own "mail" subdomain and it's own certificate for the mail server portion so that I can still have clients connect to mail.<domain>.<tld> without impact since that's what I have told a dozen or so to do already over the last 1.5 years.

---

And no, the decision wasn't anything to do with Cloudron or DigitalOcean really. My main reason for the move away from DigitalOcean isn't anything to do with Cloudron or DigitalOcean. If you're curious... the decision was mostly for two reasons:

1. A movement from both myself and my clients to keep everything (as much as possible) in Canada. And my current DNS provider (LunaNode) has their infrastructure in Canada only (well France too, I believe). It's one of those "shop local" sort of things.

2. The DNS provider I currently use has a great feature that I can take advantage of in the future when running a secondary Cloudron server as a mirror image of the first one (waiting for that clustering capabilities in the future, hint hint haha). The advantage is that they have monitoring tools I can use, and based on those monitoring tools they can automatically update DNS records to the other IP address if monitoring detects one of the servers as "down" for whatever reason. To me this is like the health checks in load balancing, but I don't have to pay for load balancing with this solution. I see this as a further advantage to using LunaNode for the DNS management.

So yeah, nothing to do with Cloudron or DigitalOcean really, so no worries there. Just a decision made for various reasons (the biggest two above, but also a bit of my own OCD and others haha).

---

I will keep my primary domain on DigitalOcean then for now if you think the SSL cert for the mail subdomain would arrive in the next couple of months. Because I think that's a fantastic idea, and I think that was something I mentioned or questioned back when I started using Cloudron because I was so surprised that it had to be "my." as that's not something that conforms to the standards of mail server hostnames, and I wanted to keep things more standard for my clients to avoid having to explain non-standard implementations. I say standard loosely here as I realize there's no official standard, but it's more a de-facto one that mail. is the subdomain to use, or imap., etc.

Hope that helps.