SUMMARY

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.

OVERVIEW

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.

SSL CERTIFICATE TYPES

The following SSL certificates are able to be used for web and messaging implementations:

• Single Name Certificate: This certificate protects a single host name (naked subdomain) e.g.: www.example.com. Most certificate providers will also additionally protect the root domain (example.com), but it is up to the certificate authority as to whether they do this.
• Wildcard Certificate: This will protect multiple subdomains of a domain such as www.example.com, mail.example.com, autodiscover.example.com, etc. It may be cheaper than purchasing multiple single certificates.
• 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. 

CERTIFICATE COSTS

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 provider/authority).

HOST NAMING CONVENTIONS

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 (www.example.com) to be serviced by the cert - since this is a browser entry-point.
2. You will need the root domain (example.com) 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 (example.com) for the DNS A record associated with the MX to preserve the number of Certificate Subject Alternates you use.
4. You will need autodiscover.example.com 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: webmail.example.com).
6. You may also want to provide secure access to your customer portal at admin.example.com. 
7. If you are using ActiveSync, then you will can also service it from autodiscover.example.com (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.: example.com 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).

ADDITIONAL CONSIDERATIONS

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.

REFERENCES

Wildcard Certificates: https://en.wikipedia.org/wiki/Wildcard_certificate