How to Configure SSL for Web and Messaging Services


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:

  • Single Name Certificate: This certificate protects a single host name (naked subdomain) e.g.: It is possible for these certificates to additionally protect the root domain (, but it is up to the certificate authority as to whether they include the root domain (most do. eg: Comodo EssentialSSL).
  • Wildcard Certificate: This will protect hosts/subdomains immediately below the associated domain. e.g.:,,, etc.
  • Multi-Domain (UCC) SSL Certificate (also known as a SAN certificate): These certificates protect multiple domains as a single certificate utilizing Subject Alternate names for additional domains. 


In order to service and with SSL (on the same port number), you will need to have either:

  • a separate Single Name Certificate for each host/domain (in this case you will also need a different IP address for each host/domain) or
  • a Wildcard Certificate that has subjects/alternate subjects that services both and or
  • Multi-Domain (UCC) SSL Certificate (also known as a SAN certificate) that allows you to secure all domains and hosts (this will allow you to use a single IP address to service secured host/domains)

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 for port 993 and bind a different certificate to a host as 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,, 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 provider/authority).


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:

  1. You will need the web site ( to be serviced by the cert - since this is a browser entry-point.
  2. You will need the root domain ( to be serviced by the cert - since this is an alternate browser entry-point. You can also use the root domain to provide secure SMTP, POP, and IMAP protocols.
  3. You should also consider using the root domain ( for the DNS A record associated with the MX to preserve the number of Certificate Subject Alternates you use.
  4. You will need as a host name for each domain you host. You should ensure that this is specified as a Subject Alternate.
  5. You will need a host name associated with webmail (example:
  6. You may also want to provide secure access to your customer portal at 
  7. If you are using ActiveSync, then you will can also service it from (via a binding through the MailEnable Protocols Site).

That being the case, a common SSL environment for a domain will require a certificate that services:

  • www (mandatory - required for web site entry point)
  • root domain - (mandatory - e.g.: typically leveraged for alternate www entry point as well as ActiveSync)
  • autodiscover (optional - can also service /autodiscover as a virtual directory off root domain)
  • ActiveSync (optional - unless configured under the site as a virtual directory)
  • webmail (optional - unless configured under the site as a virtual directory)
  • admin (optional - unless configured under the site as a virtual directory)
  • mail (optional - could use root domain as the host name)

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:

Product:MailEnable (Pro-Any Ent-Any)
Class:INT: Product Integration
Revised:Tuesday, October 30, 2018