Per-domain TLS certificates about maddy HOT 16 CLOSED

Implemented in cee8bbd.

tls file certA.pem keyA.pem certB.pem keyB.pem

from maddy.

Use letsencrypt to request multi-cert for all configured domains... use SNI for per-host web (theming/domain on address) .. other protocols just answer on appropriate port(s)

from maddy.

@Avamander, so what you want here is that single maddy instance should be able to serve multiple different domains and provide them with separate storage and etc., right?

auth_perdomain and storage_perdomain introduced in #74 enable this for authentication and storage.
With auth_perdomain, used authentication provider will not strip domain part before checking it with database. Also it will require users to authenticate using full e-mail rather than just mailbox-name.

With configuration like that:

auth_domains example.com example.org
auth_perdomain
storage_perdomain

sql { 
  ...
}
submission ... {
  auth sql
  destination example.org example.com {
    deliver sql
  }
  ...
}
imap ... {
  auth sql
  storage sql
}

[email protected] and [email protected] will be different accounts.

from maddy.

Or perhaps we can take a step forward and also extend TLS directive in general

tls {
  cert <file>
  key <file>

  //other options, such as TLS client certs handling and stuff
}

tls perdomain {
  <domain> {
    cert <file>
    key <file>
    //other options, such as TLS client certs handling and stuff
  }
}

from maddy.

Another way: allow to specify multiple cert/key and do the matching using CN/SAN.

from maddy.

Why wouldn't you specify it in a imap or smtp block?

from maddy.

My friend asked for code me to help him with maddy configuration for multiple domains. I totally forgot how MX records work and the domain in MX record is the one being used for verification. E.g. even if you are working with multiple domains, you can add MX records such that they will point to the same server domain and it will be used for certification verification.

from maddy.

Reopening add there probably a use case for initially proposed idea.

from maddy.

Given that MTA-STS is a thing it would be nice to have support for multi-tenant systems for those cases as well.

Originally posted by @Avamander in #72 (comment).

from maddy.

One possible reason for supporting SNI here is that email client should be able to autodiscover configuration by trying to connect to (imap.)example.org:imaps or (imap.)example.com:imaps.

I think for these cases more sophisticated auto-discovery protocols should be used (see #67).

from maddy.

I think supporting per-domain TLS would be quite beneficial.

I host a few websites for different users and right now they have to put up with having to log in using @kitteh.pw and manually changing their address to @example.com.
They also cant recieve their mail most of the time using TLS either with the way stuff is managed.
People who provide hosting for other users and for people who own multiple domains but don't have the money to buy multiple VPSes would like this feature too.
I own namedkitten.pw and kitteh.pw and a few more domains and only host them off of one server, this just causes way more of a hassle then if we where to support multiple domains and per-domain TLS.

from maddy.

so what you want here is that single maddy instance should be able to serve multiple different domains and provide them with separate storage and etc., right?

Preferably also do MTA-STS with matching domain certificates, if possible.

from maddy.

@NamedKitten

Consider this:
Set MX record for all domains to point to one domain (kitteh.pw, for example). Enable per-domain authentication and storage (note that it requires users to specify the full address in login credentials). Then consider deploying autodiscovery protocols mentioned above or just tell users to use kitteh.pw as IMAP/SMTP server when connecting.

This issue basically boils down to autodiscovery protocols support in clients. Research is needed.
Without it - SNI makes (a lot) sense. I doubt many clients support autodiscovery.

I think we can merge a PR to support it anyway, I'm not sure about config syntax though. Are there better options than one I described (and implemented but removed before merging in #59)? Somebody can just send a patch to revert the commit that removed it.

from maddy.

Webmail is out of scope though. The problem is that clients will try to probe for standard continuations, like imap.domain. So it makes sense to be able to accept connections and provide the TLS certificate valid for that domain.

from maddy.

Added "good first issue" label, it should be easy to implement if somebody thinks it is needed.

from maddy.

Awesome, thanks!

from maddy.