Exchange Server 2013 provides a high level of security for client-server and server-server communications by using certificates to secure protocols such as HTTP, SMTP, POP and IMAP.
Because of the “secure by default” requirements, when an Exchange 2013 server is installed it is configured with self-signed certificates that are enabled for those protocols.
Here is an example of the self-signed certificates installed on a new Exchange 2013 server.
[PS] C:\>Get-ExchangeCertificate | Select Subject,IsSelfSigned,Services | ft -auto Subject IsSelfSigned Services ------- ------------ -------- CN=Microsoft Exchange Server Auth Certificate True SMTP CN=E15MB1 True IMAP, POP, IIS, SMTP CN=WMSvc-E15MB1 True None
Although this means that services such as Outlook Web App, Outlook Anywhere, and Activesync are secure right from the moment the Exchange server is installed, the use of self-signed certificates is only intended to be temporary while the administrator acquired the correct SSL certificates for the server.
SAN/UC Certificates for Exchange Server 2013
Exchange 2013 uses a type of SSL certificate that is known as a “Subject Alternate Name” (SAN) certificate. In some cases this will be called a “Unified Communications” (UC) certificate by providers such as Digicert.
A SAN certificate is an SSL certificate that has multiple server or domain names on the one certificate. This means that you can use a single certificate to secure one or more Exchange 2013 servers, and it can include all of the server names and other external URLs you plan to use for your Exchange environment, instead of having to provision a single-named SSL certificate for each of the different names.
Planning for Exchange 2013 SSL Certificates
There are three requirements for an SSL certificate to work correctly in your Exchange 2013 environment.
Certificate Validity Period
The certificate validity period is the period of time between when the certificate was issued and when it expires. Every SSL certificate will have an expiry date, and this will vary depending on how the certificate has been provisioned.
The default, self-signed certificate that Exchange 2013 creates during setup is valid for 5 years. A certificate issued from a private certificate authority may be valid for several years as well.
A certificate that has been acquired from a commercial certificate authority such as Digicert will usually be valid for one year.
Trusted Certificate Authority
For a client to trust the SSL certificate that a server is using the certificate must be issued by a certificate authority that the client already trusts.
If you’re using a private certificate authority to issue SSL certificates to your Exchange 2013 servers, and that CA is an enterprise CA in your AD forest, then that CA will already be trusted by clients that are members of domains in that AD forest. Non-domain members will not trust the CA unless the root certificate is imported into their trusted CA list.
The major commercial certificate authorities are already trusted by the operating systems running on most computers or mobile devices, so when you acquire your certificate from one of those CAs it will be trusted by connecting clients as well.
These trust issues mean that although you can use a private CA to issue your SSL certificates, it tends to be easier and less administrative effort to use a commercial CA.
Note: this trust issue only applies to the certificates installed on a dedicated Client Access server. The Mailbox server can use self-signed certificates because it does not accept direct client connections. In a multi-role server the trust issue still applies.
Correct Server/Domain Names
The final requirement is that the server or domain name that the client is connecting to must match one of the names on the SSL certificate.
For example, if the clients use the URL https://webmail.exchangeserverpro.net/owa to connect to Outlook Web App, then the SSL certificate on the Exchange server must include the name “webmail.exchangeserverpro.net”.
At minimum the SSL certificate should include the fully qualified domain name (FQDN) of the Exchange server itself. Then, depending on the role and configuration of the server, it may also need several other names for external access methods.
For example, an internet-facing Client Access server named “excas1″ in the “exchangeserverpro.net” domain would need:
- the server FQDN of “excas1.exchangeserverpro.net”
- the OWA, OA, Activesync external URL names, eg “mail.exchangeserverpro.net”
- the Autodiscover name for the primary SMTP namespace, eg “autodiscover.exchangeserverpro.net”
In an Exchange 2007 to 2013 upgrade/co-existence scenario the certificate may also need to include a legacy name, such as “legacy.exchangeserverpro.net”.
If you’re using an internal DNS namespace that you don’t own or is not valid (eg, .local) you may also need to read How to Deal with SSL Requirements for Exchange when Certificate Authorities Won’t Issue You a Certificate
How Many SSL Certificates to Configure?
For ease of administration, as well as for lower costs, it is recommended to provision as few certificates as possible. Consider that the Exchange servers in a given site will likely have the same configurations such as external URLs, so the only variation in their certificate requirements is the server FQDN itself.
Because the SSL certificate can include as many names as you need (up to about 50 before it may begin to cause performance issues), and with the way SAN/UC certificates are priced, it is often less costly to use a single SAN certificate for multiple servers than to acquire a unique certificate for each server.
Also consider that the trust issues when using a private CA to issue the SSL certificates generally only apply to the internet-facing servers that will be accepting connections from non-domain members such as mobile devices. It may be possible in your environment to use a private CA to issue the SSL certificates for the non-internet-facing servers, as they may only be seeing direct connections from domain members.
The best number of certificates to configure is something for you to determine in the planning for your unique environment, but generally speaking fewer certificates is less costly and more manageable.
Next Steps
After planning your certificate requirements the next steps are:
- Generate a Certificate Request for Exchange 2013
- Submit the certificate request to your chosen CA to acquire the SSL certificate. I recommend Digicert for their competitive pricing, good support, flexible licensing, and free re-issues if you happen to make an error. Or if you’re using a private CA refer to these steps.
- Complete the pending certificate request
- Export/import an SSL certificate to multiple Exchange 2013 servers (optional)
- Assign the SSL certificate to services in Exchange 2013
About Paul Cunningham
SSL SAN Certs in about 2 more years are going to be a bit challenging!
http://www.digicert.com/internal-names.htm
Can you please explain how certificates are used when Exchange 2013 UM is combined with Lync 2013 as a trusted app for OWA IM integration? Since there are two different worker processes and services, one on the front end and one on the backend, I’m not sure where this cert needs to go and what names it needs to have on it. And Technet does a horrible job of explaining this, and describes it differently depending on the link you are looking at.
Which Technet articles are you looking at?
One of them is this, where it says you have to edit the OWA webconfig file:
http://technet.microsoft.com/en-us/library/jj688055(v=ocs.15).aspx
Another one is this, where it makes no mention of this, but has some other Exchange commands not listed in the first one. It also makes mention of needing the server FQDN in the certificate, as you do. However, they reference the CAS name as the name of the app pool and the name that needs to be included in the cert…but OWA is actually in a backend IIS directory on the MB role when it’s split.
http://technet.microsoft.com/en-us/library/jj204857(v=ocs.15).aspx
And in yet another article (can’t find the technet one right now, but have listed another), it specifically points out the backend IIS directories with still more confusing certificate info.
http://memphistech.net/?p=280
And to wrap it all up, all articles say that if you are not connecting to IM, just check the “C:\Program Files\Microsoft\Exchange Server\V15\Logging\OWA\InstantMessaging on the MBX server” but I can’t find that directory anywhere, much less find the log files to reference for troubleshooting. And there is nothing in the event logs either.
Am I going crazy?
There is an OWA vdir on the back end but client connections hit the CAS and are proxied through from there. So that would include Lync as well, according to that Technet article (its asking for the CAS FQDN).
I wish I could say for sure one way or the other but I haven’t looked into your scenario enough to know.
Hi all,
After requested certificate for Exchange server 2013 (client access+mailbox role are same as PC), does I need to import this certificate for non-domain PC for using Outlook to connect to Exchange 2013 ?
Thanks,
If the cert comes from a CA that the PC already trusts (eg a commercial CA such as Digicert or Verisign) then you shouldn’t need to do anything.
If you’ve issued the cert from a private CA then you’ll need to import the CA’s root certificate into the trusted root cert store on the PC.
Could you give steps about how to import the CA’s root certificate into the trusted root cert store on the PC?
Via Technet:
http://technet.microsoft.com/en-us/library/cc754841.aspx
I follow you guide and configure certificate successfully and can be access owa without certification error message. Now I want to use Outlook 2013 to connect mailbox. Could you give steps how to do it? thanks.
Open Outlook and follow the prompts. Autodiscover should take care of the configuration for you automatically.
Hello, If I am correct Exchange 2013 certificate best practices differs from Exchange 2010.
http://technet.microsoft.com/en-us/library/dd351044(v=exchg.141).aspx
It’s written:
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.
So example would be:
Mail.contoso.com This host name covers most connections to Exchange, including Microsoft Office 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 Server 2003 or Exchange 2007. If you’ll have clients with mailboxes on both a legacy version of Exchange and Exchange 2010, configuring a legacy host name prevents your users from having to learn a second URL during the upgrade process. For more information about upgrade and coexistence, see Upgrade from Exchange 2003 Client Access and Upgrade from Exchange 2007 Client Access.
In your example of SAN’s you include FQDN of the server hostname. Is it really must have? If we include it then external users can see internal server names and domain name. Maybe there are some hard changes that need hostnames? I remember Exchange 2007 times when I setup all names including NetBIOS hostnames:)
All you HAVE to have on 2013 is mail dot and autodiscover dot. Legacy is not needed for 2010. It proxies the connection to the backend 2010 through the 2013 frontend. NetBIOS is not needed either if you change all of the autodiscoverinternaluri and other settings to match the external namespace. As a side note, there is no security risk with people on the internet knowing your internal server names. Security by obscurity is no security at all.
It’s not so easy to setup Autodiscover in Exchange 2013:
http://social.technet.microsoft.com/Forums/en-US/exchangeserverpreview/thread/921dc266-419a-4093-a918-84816168b4d4/
legacy is needed for Exchange 2007 coexistence.
I have one installation where Outlook 2007 prompts (Outlook 2010 goes without error) an error about the certificate name mismatch due to the fact that Exchange appier as hostname of the server (even all was setup to use another name). So Paul written that FQDN of the server hostname is needed, so if you have eg 4 CAS servers you need more SAN names…
I am sometimes amused by people trying to avoid putting server names in an SSL certificate all the while exposing them in message headers anyway.
Good reason, but this does not answer the question: why we need FQDN name of the CAS servers:)
@Gediminas
You do not need the internal FQDN so long as you set the autodiscoverinternaluri correctly.
http://www.shudnow.net/?s=autodiscoverinternaluri
Yes, Kyle, thank you for the link. It was indeed all correct for Exchange 2007/2010. But 2013 autodiscover configuration needs to be done using low level utility eg adsiedit. By default autodiscover internal and external URL are empty. I hope this config is still supported by Microsoft.
@Gediminas incorrect. I’ve done multiple production deployments, both greenfield and in 2010 coexistence, and I can assure you that both the internal/external urls are not needed and can be left blank. The only thing you need to change is all of your regular web urls (ews, oab, eas, owa, oa, etc) and the autodiscoverinternaluri. Once you’ve changed all of those to something like mail.company.com, that and autodiscover.company.com (the built in url that outlook uses when NOT inside the network) is all you need to have on the cert. In fact, you will NOT physically even be allowed to add internal FQDNs to all new certs as it is no longer allowed. See the changes here: http://www.networking4all.com/en/ssl+certificates/faq/change+san+issue/
Thank You Kyle, you answered my question fully. It’s very clear that there is no need and is even not recommended to put FQDN of server in certificate. I was indeed wrong with configuration and this post also is misleading:
http://social.technet.microsoft.com/Forums/en-US/exchangeserverpreview/thread/921dc266-419a-4093-a918-84816168b4d4/
because we setup autodiscover uri using the “Set-ClientAccessServer” cmdlet with the “AutoDiscoverServiceInternalUri” parameter instead of Set-AutodiscoverVirtualDirectory
The ExternalURL and InternalURL parameters on the autodiscover virtual directory are not used at all. They only exist because they are inherited from a base class used for all virtual directories.