This article outlines typical SSL IP address scenarios and provides suggestions for configuring SSL host bindings.
It also provides recommendations for configuring SSL host/alternate subjects for web and email services.
MailEnable can use a variety of certificate types, and can serve different certificates for connections. It can do this by using SNI where the mail services are told by the connecting client what domain the connection needs a certificate for. The services can then use the appropriate one, or fall back to a default certificate.
The following SSL certificates are able to be used for web and messaging implementations:
The cost of acquiring certificates can be expensive, particularly
if you are hosting multiple domains.
A certificate allowing multiple hosts/alternate subjects for a single domain will cost hundreds per year (i.e. a certificate for www.example.com, mail.example.com, etc.)
Assuming you host 20 domains, and you want them all configured with SSL hosts for web and mail services, a Multi-Domain (UCC) SSL Certificate (also known as a SAN certificate) from virtually any provider will costs thousands of dollars per year. The advantage of such a certificate is that a single IP address can be used to service a large number of domains.
The process for applying for these certificates needs to be carried out in
conjunction with the actual owner of the domain (since they typically
require validation directly by the SSL certificate
The following recommendations apply to configuring SSL for mail and web services (under the presumption you have a SAN/wildcard certificate for the domain).
If you are configuring a limited wildcard certificate (a certificate allowing a number of alternate subjects/host names), you will need to consider the following:
That being the case, a common SSL environment for a domain will require a certificate that services:
Based on the above, the minimum number of host subjects required for a domain servicing common web and mail services is 2 (assuming that you can use virtual directories under IIS for web, ActiveSync, autodiscover, etc. services). It is recommended that you configure such services as host headers and avoid using virtual directories of web sites for services like webmail/autodiscover/webadmin/ActiveSync because they may be impacted by the permissions and configuration of the parent web site.
If you configure these each of these services as host headers, each would operate under IIS with their own host name and associated SSL certificate subject.
With respect to core mail services, you may also wish to expand on identifying SMTP, POP, IMAP etc. as separate hosts (if your certificate has the ability to add additional alternate subjects/hosts).
Some certificate providers have low renewal thresholds. As an example, Let's Encrypt currently requires that the certs are regenerated every 90 days. MailEnable will load these newly added certificates when they are renewed, but you need to make sure that the Windows account the mail services are running under have permissions to access the certificate.
Wildcard Certificates: https://en.wikipedia.org/wiki/Wildcard_certificate
|Product:||MailEnable (Pro-Any Ent-Any)|
|Class:||INT: Product Integration|
|Revised:||Thursday, January 9, 2020|