search

mail-in-a-box / mailinabox

Mail-in-a-Box helps individuals take back control of their email by defining a one-click, easy-to-deploy SMTP+everything else server: a mail server in a box.
https://mailinabox.email/
Creative Commons Zero v1.0 Universal
14.04k stars 1.44k forks source link

Certificates on multiple subdomains #1559

Open jmoudy opened 5 years ago

jmoudy commented 5 years ago

I have a box running my primary domain with a good TLS certificate. (call it box.domain.com)

I've incrementally added subdomains to it, and they've been 'automatically' getting TLS certs when they were setup. (meaning I've got different subdomains in various certs). Call them subdomain1.com and subdomain2.com, each in a different certificate).

The problem I have is email on iphone for the subdomains. My email on the client is set to my subdomain1.com as the hostname. But the iphone is picking up the certificate for box.domain.com ... and subdomain1.com isn't on that certificate).

I'd like to be able to reissue the box.domain.com certificate with the subdomains, but I don't see anything in management/sssl_certificates.py that would facilitate that.

New domains should cause a new certificate to be issues with all the domains in it, IMHO.

alento-group commented 5 years ago

The problem I have is email on iphone for the subdomains. My email on the client is set to my subdomain1.com as the hostname. But the iphone is picking up the certificate for box.domain.com

Which historically is correct ... the imap server is box.domain.com so the client should be connecting to box.domain.com NOT subdomain1.domain.com. Now, if you are using a CNAME for subdomain1.domain.com, then yes, you will have this issue. Why not simply use the actual hostname?

What you are proposing is for Let's Encrypt to replace the original certificate for box.domain.com and replace it with one for SAN's including box.domain.com and subdomain1.domain.com. et al. I am not so sure that this is practical as doing such would require the subdomain's A record to be pointed to the MiaB, so if you are hosting anything on those subdomains elsewhere (which is typically the case) then you are going to introduce other issues. For most people this "fix" would cause more issues than it would solve, IMHO.

jmoudy commented 5 years ago

The imap server is on the hardware, correct. Let me use a made-up example. If my server was set up as the MIAB server for burgerking.com and if for some reason I was hosting email for (stick with me here) mcdonalds.com on the same box ... the mcdonalds folks wouldn't feel good about putting in burgerking.com for their email host's domain.

Even though the client is set to use mcdonalds.com as the email server, iphone/ipad (37% of the email client market) is apparently looking up the IP address and asking the server for its certificate and getting back the original certificate for burgerking.com and finding that its not listed as a valid cert for mcdonalds.com .

All of the domains are setup by MIAB, so this should work without any other intervention, right? There is nothing exotic or atypical about my use case.

alento-group commented 5 years ago

If my server was set up as the MIAB server for burgerking.com and if for some reason I was hosting email for (stick with me here) mcdonalds.com on the same box ... the mcdonalds folks wouldn't feel good about putting in burgerking.com for their email host's domain.

Of course, which is why anyone setting up a mail server for competing businesses would use a generic (whitelisted) domain ... such as mail-servers.org or something equally generic. So just a little bit over 1/3 of users are using a client which does things in an atypical manner? As it stands now, the project does not support using CNAME's for the IMAP/POP hostnames ... however, let me offer you a workaround... You would need to add a mail user for the new subdomain (mail.mcdonalds.com) and add an A record for mail pointing to your box's IP address, then delete the ssl certificate for your box hostname (box.burgerking.com) and reissue certificates - at reissuance, the new cert will pick up the SAN's, so you will have a certificate for box.burgerking,com and mail.mcdonalds.com ... but be aware that anyone looking at the certificate will see this!!! So again, you are best to my original statement. Use a whitelisted (generic) domain name for the mail server. As there really is no easy fix.

jvolkenant commented 5 years ago

Did you add an A record for subdomain1.com to box.domain.com? If so, the SSL issue is expected. In order to provision a ssl cert for subdomain1.com, create any email@subdomain1.com and you can then use the SSL Certificates tab to get a cert.

the-nurk commented 1 year ago

Just want to say that this appears to be a completely valid desire/use case.

After a domain migration from domain1 to domain2 on the same box, where domain1 is kept alive with a domain alias to forward its mail, some clients/services might be still be pointing to the legacy domain and changing those configurations may be a lot of work. CNAME only appears to work for http related traffic.

The certs (just one .pem file though) provisioned by MIAB have all the appropriate SANs after deleting and re-provisioning through the admin GUI. However, the certs served are still broken up by 'zone' due to the way management/utils.py builds the sorts the domains and how management/ssl_certificates.py unpacks that data structure.

More granular control over the provisioning would be needed, but asking MIAB to provide that is essentially asking for certbot GUI wrapper at this point. Sometimes you just gotta get your hands dirty.

Suggestion?

  1. figure out the certbot command(s) to do this yourself through the cli
  2. run command(s) and check renewal works
  3. edit management/daily_tasks.py to run your own renewal script instead
  4. cronjob a script or just make a note to ensure daily_tasks.py is always pointing to your renewal script (even after miab upgrades)