Home » Exchange Server » Exchange Server 2013 SSL Certificates

Exchange Server 2013 SSL Certificates

Exchange Server 2013 provides secure client-server and server-server network communications by using SSL 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 SSL certificates that are enabled for those protocols.

Exchange 2013 SSL Certificates

Here is an example of the self-signed certificates installed on a new Exchange 2013 server.

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 SSL certificates in Exchange Server 2013 is only intended to be temporary while the administrator acquires and installs 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://mail.exchangeserverpro.net/owa to connect to Outlook Web App, then the SSL certificate on the Exchange server must include the name “mail.exchangeserverpro.net”.

Depending on the role and configuration of the server it may need several names to be included on the SSL certificate. The minimum recommended names are the Client Access namespace (when a single, unified namespace is used) and the Autodiscover namespace.

For example, an Exchange 2013 server in the “exchangeserverpro.net” domain may need:

  • the OWA, Outlook Anywhere, Activesync external URL names, eg “mail.exchangeserverpro.net”
  • the Autodiscover name for the primary SMTP namespace, eg “autodiscover.exchangeserverpro.net”

Microsoft’s published best practices on SSL certificates for Exchange recommend not including the server FQDN in the certificate. For more information on how to configure Exchange servers so that the server FQDN is not required on the certificate please refer to this article.

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.

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 Exchange Server 2013 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 for Exchange 2013 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 Exchange Server 2013 SSL certificate requirements the next steps are:

  1. Generate a Certificate Request for Exchange 2013
  2. 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.
  3. Complete the pending certificate request
  4. Export/import an SSL certificate to multiple Exchange 2013 servers (optional)
  5. Assign the SSL certificate to services in Exchange 2013
Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server


  1. Kyle Kennedy says:

    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.

      • Kyle Kennedy says:

        One of them is this, where it says you have to edit the OWA webconfig file:

        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.

        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.

        And to wrap it all up, all articles say that if you are not connecting to IM, just check the “C:Program FilesMicrosoftExchange ServerV15LoggingOWAInstantMessaging 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.

  2. cuocdoi says:

    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 ?


  3. Mick says:

    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.

  4. Gediminas says:

    Hello, If I am correct Exchange 2013 certificate best practices differs from Exchange 2010.
    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:)

    • Kyle Kennedy says:

      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. 😉

      • Gediminas says:

        It’s not so easy to setup Autodiscover in Exchange 2013:

        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…

        • Gediminas says:

          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.

        • Kyle Kennedy says:

          @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/

        • Gediminas says:

          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:

          because we setup autodiscover uri using the “Set-ClientAccessServer” cmdlet with the “AutoDiscoverServiceInternalUri” parameter instead of Set-AutodiscoverVirtualDirectory

        • Gediminas says:

          By the way you can configure to not expose internal host names in headers by using header firewall or transport rule to remove some info from outbound messages.

  5. Andres Canello says:

    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.

  6. Michael says:


    Adding the CAS server name to the SSL certificate is not an option for me as we don’t own the internal domain namespace.

    What should I do then?

    • Kyle Kennedy says:

      You’ll also want to add a forward looup zone internally for your paid for external namespace, and configure your autodiscoverinternaluri with the external namespace as well. You don’t need any of your internal only names listed on the cert.

  7. Rajith says:

    Hi Paul,

    You don’t need server fqdn in the certificate provided that you have configured Exchange properly, by re-pointing all urls to a VIP, NLB etc. It is not about exposing the server names in the cert, just because it is exposed in the message headers anyway!

    You can remove server names from the headers using Header Firewall. http://howexchangeworks.com/2012/02/header-firewall-in-exchange-2010.html

    It is about keeping the entries in the cert to a minimum, therby reducing the cost and keeping things simple. I work in a very large org with 100s of Exchange servers and if we were to add server names in the cert, we will need a full time person to refresh the cert on all servers, as more number of servers get added/removed on a weekly basis in large corps.

    If you have any reasoning to have the server names, let us know.


    • Mahesh says:


      I have two exchange 2010 and two exchange 2013 2010 is our existing environment and we are upgrading to 2013 now . i just want to know one we want to run both the environments paralally we have separate certificates for 2010 with the entries of server 1 and server 2 with owa and all other things now we have to create a server for exchange 2013 what are the things we are supposed to add in that certificate FYI we have 2 servers of 2013 is that required to add all four servers in the certificates if yes we have a constrain here only five entries can be keyed in a certificate could you please advise on this.

  8. Ed osckar says:

    I have a question regarding SAN cert name requirement for Unified Messaging (UM).

    Since UM is now hosted on mailbox servers, will we need to have all of the mailbox servers with UM roles enable (started) as part of the SAN cert names?

    I am asking the question in consideration of multiple DAG mailbox servers, and lync integration in the exchange Org.

    Thanks all!


      • Paul,

        I have just completed the deployment of UM servers on two of my DAG Mailbox servers.
        I have also deployed 2 CAS servers that runs UM routing services.

        When I don’t have the servers hostname on the SAN certificate, my UM will not work. Voice calls will be directed to the UM servers but will immediately be dropped. I then tested generating new SAN certificate that includes only the CAS server with UM routing services, still no go.

        (note: yes my old exchange 2010 cas/hub/mailbox/um is still working in co-existence mode. However mailboxes migrated to exchange 2013 were the one having the UM issues).

        When I included the hostnames on all of my CAS and DAG servers, UM started working.
        I may have made a few configuration a long the way that caused UM to work, but I was able to get UM working with those addtl hostnames in the SAN.

        I hope this post will help others with similar scenario.

        Cheers, Ed Osckar

  9. Prudence says:

    Hi Paul,

    Thanks for your sharing. Your article did help me a lot while I set up Exchanger 2013.

    May I seek your suggestion on the below scenario? Thanks in advance.

    AD Schema: Windows Server 2008 R2
    OS of Exchange server: Windows Server 2013
    Version of Exchange Server: 2013
    SSl Certificate: generated by DC
    External DNS setup: Yes
    Accessibility of external OWA: Yes

    Currently my company want to let users access company mail by Outlook 2007/ 2010 on non domain-joined computers. The only way for the user to do it is to import root CA to the machine. May I seek your advice if there is another way to do it without manually importing root CA?



    • The solution is to buy an SSL certificate from a provider such as Digicert. The process is almost identical, except after generating the certificate request you upload it to Digicert instead of to your own CA.

      The price of an SSL cert is quite reasonable and will avoid problems with non-domain members not trusting certificates issued by your own CA, as well as avoiding the administrative burden of importing root certificates on all the non-domain members.

  10. sunil says:

    Getting below error on HT server though the TLS is enable and receive 250 StartTLS response.

    Receive connector “XYZ” requires Transport Layer Security (TLS) before the MailFrom command can be run, but the server can’t achieve it. Check this connector’s authentication setting.

    • Gediminas says:

      Yes, it works. You can save money on using wildcard cert, I deployed it with full Exchange 2013 functionality (except UM) and also it works on reverse proxy based on IIS ARR.

    • Peter Yuen says:

      Yes, wildcard SSL certificates are supported and work without annoying error messages.

      You could also have a look on multi-domain SSL certificates (UCC/SAN) – they protect up to 100 host names with one certificate and might be cheaper than wildcard SSL certs (up to five host names are usually included in the standard package of the differents certificate authorities).

  11. Rendy Budhy says:

    I have issue after we change the IP Public for our Exchange Server.
    We can access our email by outlook in computer that join domain
    But it is not working when i tried to connect outlook in computer that is not join domain.
    the outlook always asking password and not let me login.

    Then In outlook anywhere at outlook, I tick connect using SSL only and proxy authentication setting is NTLM
    it gave me error code 8 when i opened the outlook.
    “There is a problem with the proxy server’s security certificate. The security certificate is not from a trusted certifying authority.

    Outlook is unable to connect to the proxy server mydomain.com. (Error Code 8).”

    is there any missconfiguration ?
    before migrate to new IP Public, it worked find.


  12. Choulho Shin says:

    Hi Paul,

    I am wondering what you recommend with requirements below?

    > Exchange 2013 will provide services for both intranet and internet access.
    > FQDN for intranet is xxx.com. FQDN only exists in internal DNS, but not in external DNS.
    > FQDN for internet is xxx.com.au.
    > Since internet access is allowed, public certificate will be used.

    As I understand, public SAN certificate will not be allowed to have intranet FQDN soon for security concern. http://support.godaddy.com/help/article/6935/phasing-out-intranet-names-and-ip-addresses-in-ssls

    With this reason, public SAN certificate will only include FQDN for internet.

    So, feasible solution here is to put CAS dedicated to intranet access and CAS dedicated to internet separately?

  13. Gordon Harwood says:

    Hello, informative artical, but i am having a few issues trying to sync my sharepoint 2013 and my exchange 2013 for task sycronisation, following a guide on technet.

    my exhcange 2013 has no issues and has working certs and the users are happy.

    Hello, been stuck on the same issue for around 8hours +, tried different methods and guides to resolve it, prior to this I have installed EWSMangaedApi on the sharepoint server and am trying to follow this guide,


    When I run the command on the exchange server I get this error

    Creating Partner Application using metadata with linked account .

    Cannot acquire auth metadata document from ‘https://sharepointserver/_layouts/15/metadata/json/1’. Error: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel..
    + CategoryInfo : ResourceUnavailable: (:) [New-PartnerApplication], AuthMetadataClientException
    + FullyQualifiedErrorId : [Server=exchange2013,RequestId=db3e1621-3811-4897-887e-1fcdd9c6ebf5,TimeStamp=11/03/2014 16:51:09] 3E70882,Microsoft.Exchange.Management.SystemConfigurationTasks.NewPartnerApplication
    + PSComputerName : exchange2013.domain.co.uk

    When I run the command on the SharePoint server I get this error
    PS C:Userssp_install> New-SPTrustedSecurityTokenIssuer -MetadataEndpoint “http
    s://sharepointserver/autodiscover/metadata/json/1” -Name “exchange2013”

    New-SPTrustedSecurityTokenIssuer : The underlying connection was closed: Could
    not establish trust relationship for the SSL/TLS secure channel.
    So look at this there obviously a SSL/TLS error.

    I am wanting to configure task synchronisation between the exchange server and SharePoint 2013 servers, the SharePoint is going to be internal and access provided to outside users via a VPN.

    I created self-signed certificate on the SharePoint server (this is still a development environment).

    I then used bindings in IIS to add to the SharePoint site adding https over port 443 and added the self-signed cert to the SSL certificate, then in SharePoint central admin I managed the trusts and added it to the trusts list and also configures a new alternate access mapping to HTTPS.

    When I now navigate to the website it comes up with a certificate warning, if I install the certificate the error still appears even if I add it to trusted root certificates, (is this normal???)

    I have even installed the certificate on the exchange server in the trusted root certs and it still complains about the SSL TLS connection.

    Any suggestions are welcome,

    Many Thanks – BpdZenith Admin

    • Can’t help you with SharePoint I’m afraid, but I suspect what you’re seeing is a problem due to certificate trust issues. That can be caused by the root CA not being trusted, by the URL not matching a name on the certificate, or by the certificate being expired.

  14. AKhil says:

    Hi Paul,

    I know with 2013 co-exiting 2007 we required new SAN certificate.

    Do we required new certificate for 2013 in co-exiting of 2010? I believe no the reason why because there is no legacy name is required for 2010.

    Please confirm the same.

  15. Jim says:

    Hi Paul
    Can I ask your advice regarding my current 2010 environment and upgrading to 2013 please?

    The environment is 2010 SP3 ru5 and is set up as follows

    AD Site 1 has 2x CasHub and 2 Mailbox servers
    AD Site 2 has 1x CasHubMailbox
    These have a 3 node DAG

    For whatever reason the VDs on the servers in site 1 are set to autodiscover.domain.com for both internal and external URLs
    The VDs in site 2 are set to legacy.domain.com for both internal and external URLs

    Certificate is issued by Digicert and contains Mail. Autodiscover. Legacy. & Webmail. SAN names

    The mailbox servers in both sites serve mailboxes and cross site silent redirection is configured

    Even though everything works perfectly I’m pretty sure the virtual directory names aren’t configured to follow the best practices.

    I’m having a bit of trouble getting my head around how to name the virtual directories in 2013 to support a coexistence scenario bearing in mind the server in AD site 2 needs to stay in the 2010 DAG (we can’t remove it to make migration easier)

    I’m just wondering how you recommend configuring this going forward to support a 2010/2013 coexistence scenario ?


  16. Rovert.Natsud says:


    My Setup:-
    Server 2012 r2 AD/DC using domain.local
    Server 2012 r2 and Exchange 2013 with Godaddy UCC Cert (mail.domain.co.uk) as primary record

    Internal DNS (default setup as with AD/DC)
    –> domain.local
    –> added mail.domain.local –> Internal Exchange IP
    –> added autodiscover.domain.local –> Internal Exchange IP

    External DNS MX
    –> mail.domain.co.uk –> Public IP
    –> autodiscover.domain.co.uk –> Public IP

    –> Win 7 Pro
    –> Outlook 2010

    –> Public records only (i.e. mail.doamin.co.uk) as domain.local is no longer an option on Godaddy certs.

    My Issue:
    When either I setup a new client (Autodetect on setup) or when a client open’s Outlook they are presented with a certificate error (example: http://1.bp.blogspot.com/-NxXZoCeZUZ0/UrRHz9AFmQI/AAAAAAAAAJg/D-kEGuKJGHw/s1600/SSLError.png). The certificate is from a trusted authority and the certificate date is valid but the error is “The name on the security certificate is invalid or does not match the name of the site.

    After searching round I found this (http://www.digicert.com/ssl-support/redirect-internal-exchange-san-names.htm) but im not sure of its effects as it states “this method will not allow access to mail using the Outlook Anywhere service so users connecting over a VPN would have connection problems” so personally I don’t think this is a good option.

    I have also found this (http://www.digicert.com/internal-names.htm) which I think maybe a better option but i’m misunderstanding what exactly I have to do.

    Please can someone give me a bit of a step by step on what I have to do?

    Thanks in Advanced

    • Why not stop using .local for your internal Exchange namespaces?

      Exchange doesn’t need to use the same namespace as AD. It can be anything you like. In fact it is quite common to use the same internal and external namespaces in Exchange 2013.

      • Rovert.Natsud says:

        Hi Paul

        Thanks for taking the time to reply, sounds a good idea, although now I have the network built with .local I can see why you wouldn’t use .local using Server 2012 r2 and Exchange 2013 with Outlook.

        What options do I have to fix this issue and how would I go about it? ive seen a number of sites suggesting a fix but I don’t want to cause further issues or connection problems like not being able to get to OWA or ECP.

        Any help would be grateful.

        • Well your situation is never going to get better now that CAs won’t issue certs for .local domains and other similar restrictions these days. So going through the pain of a transition to new URLs is worth it, in my opinion.

          If it is done right the only real impact to end users is possibly learning a new “webmail” URL for internal use (if that is even a use case for them). And you can soften that blow with HTTP redirects and other tricks anyway.

          So my recommendation is you build up a simple test lab using .local internal names, connect up some test Outlook clients, and then test the process of changing your internal namespaces over to the new URL. It isn’t actually very difficult at all.

  17. Rovert.Natsud says:

    Hey Paul

    Thanks, sounds promising and that you speak from experience, I don’t suppose you have any step by step instructions or URL’s you point us to?


  18. Fred says:

    I’m in the same situation as Rovert.Natsud. I have a need to create an internal cert for the mail.server.its. mail.domain.com. Trying to convince management to change now would not work. We have limited staff to do the work, easier to have a cert for internal and the external.

  19. Mike says:

    I have a quick question regarding the renewal of our GoDaddy certificate that is about to expire.

    Will I create a new certificate request and follow the same guide as the first one installed? I don’t see a “renew” option within EAC. Then once it’s imported delete the one that is expiring?


  20. Derrick says:

    Hi Paul,

    I am in a similar situation where my internal and external domain names are different (domain.prv and domain.com).

    I am planning on moving from Exchange 2010 to Exchange 2013. I am also planning on getting a SSL UC Cert from DigiCert. I see you mentioned that the internal url’s do not have to match the AD domain (domain.prv). The current Exchange 2010 server has different internal and external URL’s.

    So if I used domain.com for my internal and external url’s on the new deployment how would the DNS work? When internal clients go to resolve mail.domain.com it would resolve to the external/public IP? I guess this would still work but would result in a bit more traffic/hops to reach the internal mail server.

    Any ideas?

  21. Jesus says:

    My certificate will expire in two months. I already got the new one. Can I add the new one and leave the old one until the expiration date without issue?

    • Did you get the new one as a renewal or as a whole new cert?

      If it’s a renewal I think there is no “old one” left behind. If it’s a completely new cert with the same names then yes you’ll have an “old one” left behind. There’s no specific harm in having expired certs on the server as long as they aren’t enabled for any Exchange services. Removing expired certs is good if you like neat and tidy servers 🙂

  22. Fred says:

    When I do the following I don’t have the “Microsoft Exchange Server Auth Certificate” On the CAS or mailbox servers. Do I need to add that cert? Our domain internally is domain.local and external domain.com.

    Get-ExchangeCertificate | Select Subject,IsSelfSigned,Services | ft -auto

    Subject IsSelfSigned Services
    ——- ———— ——–
    CN=WMSvc-EXMB1 True None

    Subject IsSelfSigned Services
    ——- ———— ——–
    CN=mail.domain.com, OU=Domain Control Validated False IMAP, POP, IIS, SMTP
    CN=WMSvc-EXCAS1 True None

  23. ASP says:

    I have an Exchange 2013 environment, and the 3rd part Cert is about to expire. I have already got the new cert and installed it all all 4 exchange servers, however 1 server still keeps logging a Transport Service and Front End Transport Service StartTLS error saying that the Thumbprint XXXXX of the old cert is going to expire.

    The new cert is installed and working fine, only this one server keeps giving this error.

    Any Advise?

    Many Thanks

  24. ASP says:

    Thanks Paul,
    I have followed your instructions and all looks well, except for one thing.
    For some reason ECP Login Page intermittently loops. Sometimes it will log you in with no problem, other times after you put your password and hit login, you just loop back to the login page without any errors. OWA seems fine for now just ECP problem after changing that Cert.

    Thanks again for the great assistance

  25. John says:


    Following your 2007-2013 blog I found the 2007 Exchange Certificate issued by godaddy has all the names required to import into Exchange 2013. When export from 2007 I get the PFX. When I import either in MMC or ECP it shows invalid. Is there anything you recommend to resolve this issue? We still have 8 months left on the certificate expiration.

  26. Hendra says:

    Hi Paul,
    After we have assigned a public certificate to services, would you recommend that we remove the self-signed certificate as it is linked to SMTP?

    My issue is that I am trying to our users to start using SMTP:587 for legacy customers who uses Imap/SMTP via Thunderbird.
    Thunderbird keeps complaining about the certificate has name which does not match the load balance fqdn to the Exchange 2013 servers.

    I want to remove those Self Signed Certificates bound to SMTP – but I am concern that they are used by Exchange for Internal Transport or something like that…

    Thanks in advance!

  27. Matt says:

    Hello Paul, I am securing a single server with Exchange 2013 CU11, FQDN is ES2013.mydomain.com, I followed your guides to mask the server FQDN and instead use mail.mydomain.com however I have users who will still use POP mail. When I generate the request in ECP it says ES2013 for POP and IMAP, all others say mail.mydomain.com. I tried changing to mail.mydomain.com but it just changes back to ES2013 – I guess this is because they aren’t virtual directories? If this is the case do I need to leave the server name and the request and use a SAN? Also, autodiscover Internal URL is es2013.mydomain.com — I guess this alone will make it a SAN? I have tried changing that URL also and it doesn’t ever update.

    • The wizard is just auto-populating based on your current namespace configurations on virtual directories, on Outlook Anywhere, and on AutoDiscover. On one of the last steps of the wizard you can add/edit/remove any of those entries and just cut it down to the namespaces you want.

      If it’s auto-populating an AutoDiscover namespace that you don’t want to use then I’d suspect your namespaces aren’t configured correctly. Here’s an article that should help you with that:


      Also bear in mind that even though one SSL cert can do it all for you, POP and IMAP are capable of being bound to separate SSL certs than the HTTPS (IIS) services. So you can have a separate cert entirely for POP and IMAP, but it’s simpler to put it all on one cert.

  28. Darius Hey says:

    Thanks Paul,
    Excellent reading. I have spent some time figuring out a problem with a purchased certificate and Exchange 2016. Kept on getting SSL Protocol errors when trying to access OWA en ECP from the internet. It turned out to be a enabled hidden port in my router (443 used for VPN over SSL) which had a self-signed certificate. Since the error is a bit vague I spent some time searching. So for anyone reading this comment and having SSL trouble: *check your router for 443 ports*. Often 443 is enabled as maintenance port but it good also be very well hidden in the router’s VPN settings.

  29. HybridDude says:

    I am using a wildcard certificate for the IIS service. When I attempt to log into ECP or OWA, it loops back to the login prompt page. If I switch the certificate to the self-signed one, I am able to login without any issues. Why would it not work with the wildcard cert?

  30. Karen says:

    I’m stuck with 3 SSL certificates for mail.domain.com, autodiscover.domain.com, and legacy.domain.com. Is there any way I can incorporate those three certificates into Exchange 2013 (with coexisting Exchange 2007 for limited time) without having to buy another SSL SAN certificate? My certificates are from Network Solutions, and they don’t support SAN. I’m getting lots of certificate errors for legacy.domain.com and autodiscover isn’t working properly, so external access using Outlook Anywhere isn’t working either. Everything was great on Exchange 2007 with Outlook Anywhere with my old SSL certificate. I just need some ideas on if and how I can get these three certificates to work with Exchange 2013 while I still have legacy clients, and even after everything is migrated, how to get autodiscover working on Exchange 2013. I appreciate your help.

    • Certificates can’t be combined or merged, and only one certificate can be bound to IIS for all of the HTTPS services in Exchange.

      I suggest you buy a cert from a vendor that can provide the correct type. I recommend Digicert.

  31. ITGuy says:

    I have a weird situation. I am trying to setup a phone for email. I am getting “The name of the site does not match the name on the certificate.” when I try to configure externally or internally. To make things even weirder, when I view the certificate externally, I get support.contoso.com and when I view the certificate internally I get *.contoso.com. We did purchase a wildcard certificate for all of our web services. I just do not understand what would cause this.

  32. Sharif says:

    our SSL Cert. exceed the number of SAN – it’s up to 5 SANs –

    The Support service advice me to buy new SSL Cert. so I’ll have 2 Certs. so I can add new SAN
    I this case .. can Exchange work with more than one SSL Certificates in same time ?

    or shall I purchase SSL Cert. up to 10 SAN then transfer all domains in one Cert. ?

    • Only one cert can be bound to IIS at a time, so I would recommend you increase the number of names on the certificate. I believe up to 50 names is supported before it becomes a performance problem.

  33. Mina says:

    Hello Paul,

    I have question please
    I am using a public certificate from godaddy, and I see that WMSVC certificate will be expired in few months
    Is it mandatory to renew it?


    • Mina says:

      Hello Paul,

      I have question please
      I am using a public certificate from godaddy, and I see that WMSVC certificate will be expired in few months
      Is it mandatory to renew it?


  34. Manfred says:

    I am using a wildcard certificate for the IIS service. When I attempt to log into ECP or OWA, it loops back to the login prompt page. If I switch the certificate to the self-signed one, I am able to login without any issues. Why would it not work with the wildcard cert?

    Same as mentioned by HybridDude
    Its a single 2013 server with CU15. Cert is issued by COMODO RSA Certification Authority

Leave a Reply

Your email address will not be published. Required fields are marked *