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.
Your options for configuring SSL are significantly restricted according to the number of IP addresses you have available. It is also affected by whether or not your services run on the same server (i.e.: perhaps your web site is hosted externally to your messaging services).
This article assumes that all services are running on the same server (since it is a more complicated use-case).
The following SSL certificates are typically appropriate for web and messaging implementations:
In order to service mail.example.com and www.example.com with SSL (on the same port number), you will need to have either:
It is also possible to bind different certificates to the same IP address using different port numbers. For example, you can use bind a certificate to a given IP address resolve via www.example.com for port 993 and bind a different certificate to a host as webmail.example.com for port 8993 mapping to the same IP address.
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).
If you are intending to provide secure web and messaging services for a domain you will need an SSL certificate that services your root domain as well as your www host. This could either be achieved as a wildcard certificate or by purchasing separate certificates.
Some certificate providers have low renewal thresholds. As an example, Let's Encrypt currently requires that the certs are regenerated every 90 days.
If you use such certificates, it will require removing all the old certificates from your server, adding the new ones and then restarting MailEnable services every 90 days.
Wildcard Certificates: https://en.wikipedia.org/wiki/Wildcard_certificate
|Product:||MailEnable (Pro-Any Ent-Any)|
|Class:||INT: Product Integration|
|Revised:||Tuesday, October 30, 2018|