SSL Certificates for Exchange Server 2013

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 may 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”

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

  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
About Paul Cunningham

Paul is a Microsoft Exchange Server MVP and publisher of Exchange Server Pro. He also holds several Microsoft certifications including for Exchange Server 2007, 2010 and 2013. Find Paul on Twitter, LinkedIn or Google+, or get in touch for consulting/support engagements.

Comments

  1. SSL SAN Certs in about 2 more years are going to be a bit challenging!

    http://www.digicert.com/internal-names.htm

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

    • Which Technet articles are you looking at?

      • Kyle Kennedy says:

        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.

  3. 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,

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

  5. Gediminas says:

    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:)

    • 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:
        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.

        • Gediminas says:

          Good reason, but this does not answer the question: why we need FQDN name of the CAS servers:)

        • Kyle Kennedy says:

          @Gediminas
          You do not need the internal FQDN so long as you set the autodiscoverinternaluri correctly.
          http://www.shudnow.net/?s=autodiscoverinternaluri

        • 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:
          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

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

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

  7. Hi

    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?

    • You can configure the URLs for a namespace that you do own instead.

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

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

    Thanks,
    Rajith.

  9. 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!

    Ed

    • Good question. I’m not sure of the answer though since I don’t do a lot with UM. I’ll try and look into that…

      • 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

  10. 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?

    Appreciation.

    Prudence

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

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

  12. Hi,

    what about the WildCard Certificate, is it supported in Exchange 2013 ?

    Thx

    • 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).

  13. George Lacerda says:

    What about the SAN Certicate with an empty subject common name, is it supported?

    Thanks

    George

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

    Regards,
    Rendy

  15. 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?

  16. 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,

    http://technet.microsoft.com/en-us/library/jj655399(v=office.15).aspx

    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:\Users\sp_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.

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

  18. Thanks Paul

  19. 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 Cas\Hub and 2 Mailbox servers
    AD Site 2 has 1x Cas\Hub\Mailbox
    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 ?

    Thanks
    Jim

  20. Rovert.Natsud says:

    Hi,

    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

    Clients
    –> Win 7 Pro
    –> Outlook 2010

    SSL
    –> 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.
        Thanks

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

  21. 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?

    Thanks
    Rovert

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

Leave a Comment

*

We are an Authorized DigiCert™ SSL Partner.