3

I need to order a SSL certificate for an Exchange 2013 server.

I am going to order an UC Certificate from Comodo Group Inc.

I understand that I need to specify the below subdomains whilst ordering:

  1. autodiscover.
  2. mail.

Are there any other subdomains that I need to specify for an Exchange 2013 server? I ask because an UC Certificate allows 3 subdomains so this leads me to think that I am missing one.

SMW
  • 129
  • 2
  • 4
  • 10
  • The server FQDN. (aka exchange.domain.com) – yagmoth555 Apr 29 '15 at 19:32
  • @yagmoth555 AFAIK that is `mail.` (the same as our Outlook Web App subdomain which is 2. in the question), or am I missing something? The address that Outlook Anywhere uses, right? – SMW Apr 29 '15 at 19:33

3 Answers3

2

Yes, typically mail and autodiscover will be all you need if mail.yourdomain.com is your Exchange FQDN.

See the Exchange 2013 Digital Certificates and SSL documentation which states:

Best practice: Use the Exchange certificate wizard to request certificates*

There are many services in Exchange that use certificates. A common error when requesting certificates is to make the request without including the correct set of service names. The certificate wizard in the Exchange Administration Center will help you include the correct list of names in the certificate request. The wizard lets you specify which services the certificate has to work with and, based on the services selected, includes the names that you must have in the certificate so that it can be used with those services. Run the certificate wizard when you've deployed your initial set of Exchange 2013 servers and determined which host names to use for the different services for your deployment. Ideally you'll only have to run the certificate wizard one time for each Active Directory site where you deploy Exchange.

Instead of worrying about forgetting a host name in the SAN list of the certificate that you purchase, you can use a certification authority that offers, at no charge, a grace period during which you can return a certificate and request the same new certificate with a few additional host names.

It further goes on to state:

Best practice: Use as few host names as possible

In addition to using as few certificates as possible, you should also use as few host names as possible. This practice can save money. Many certificate providers charge a fee based on the number of host names you add to your certificate.

The most important step you can take to reduce the number of host names that you must have and, therefore, the complexity of your certificate management, is not to include individual server host names in your certificate's subject alternative names.

The host names you must include in your Exchange certificates are the host names used by client applications to connect to Exchange. The following is a list of typical host names that would be required for a company named Contoso:

Mail.contoso.com This host name covers most connections to Exchange, including Microsoft Outlook, Outlook Web App, Outlook Anywhere, the Offline Address Book, Exchange Web Services, POP3, IMAP4, SMTP, Exchange Control Panel, and ActiveSync.

Autodiscover.contoso.com This host name is used by clients that support Autodiscover, including Microsoft Office Outlook 2007 and later versions, Exchange ActiveSync, and Exchange Web Services clients.

Legacy.contoso.com This host name is required in a coexistence scenario with Exchange 2007 and Exchange 2013. If you'll have clients with mailboxes on Exchange 2007 and Exchange 2013, configuring a legacy host name prevents your users from having to learn a second URL during the upgrade process.

drew010
  • 226
  • 6
  • 16
  • Thanks for your answer. I've always been confused about `.local` addresses. Does the `.local` also need a SSL certificate? I remember when we ran an older version of Exchange server we always used to get warnings about SSL certificates when a new user on LAN would add an e-mail account as it would use a `.local` address. – SMW Apr 29 '15 at 19:47
  • No public CA will issue a certificate for `.local` so no. If there is a need for internal clients to connect using a hostname like `mail.domain.local` then use the CA Server on your domain controller to issue certificates for your local domain. Best would be to have internal and external DNS zones so you can resolve mail.yourdomain.com correctly with both internal and public IP addresses. – drew010 Apr 29 '15 at 20:04
1

A word of advice. CAs are phasing out issuing UC Certs for .local so ideally you should move over your domain.com. Multi domain SSL certs are generally cheaper than a UC Cert also and will soon serve the same purpose. The standard ones for SBS are mail.contoso.com, remote.contoso.com and autodiscover.contoso.com.

For a regular Exchange environment mail.contoso.com and autodiscover.contoso.com are what's required. Don't forget to add autodiscover.contoso.com to your external domain DNS records here. I have seen owa.contoso.com but honestly it isn't needed.

Meh
  • 11
  • 1
0

To install the UC certificate on Exchange Server 2013, you need to mull over autodiscover, mail and OWA sub domains.

  • owa.yourdomain.com requires for outlook web access
  • mail.yourdomain.com require for a mail server’s hostname
  • autodiscover.yourdomain.com for auto-configuration of the email clients respectively.

You should evaluate your requirements before generate CSR and configure SSL on Exchange Server 2013.

Jason Parms
  • 272
  • 2
  • 5