Outlook 2013 SSL Trust Errors When Connecting to Exchange Server

When connecting to an Exchange server using Outlook 2013 you may encounter an SSL trust error.

SSL trust error in Outlook 2013

The security certificate was issued by a company you have not chosen to trust. View the certificate to determine whether you want to trust the certifying authority.

If you choose Yes to proceed you may also encounter this additional error message.

Error: Outlook is unable to connect to the proxy server

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 [servername] (Error Code 8).

This error occurs when the Exchange server is configured with a self-signed SSL certificate.

Outlook makes connections to the Exchange server over HTTPS and therefore must trust the SSL certificate that is configured on the server, otherwise it will display those error messages to the end user.

To resolve the issue install a valid SSL certificate on the Exchange server from a trusted certificate authority. See Exchange Server 2013 SSL certificates for more details on this as well as step by step instructions.

 

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. Connect with Paul on Twitter and Google+.

Comments

  1. Mike Manning says:

    Ran into this last week. I don’t have a CA server in my Exchange 2013 lab so I put a copy of Exchange servers self signed cert into the clients trusted root store of the computer account to get past this.

  2. well ,

    is there any way to resolve issue without buying an external certificate from trusted certificate authorities?

    for more than 3 years I am I have not faced this issue..

    • A certificate has to be trusted for it to be valid. If you don’t want to use a commercial CA then you can look into using a private CA instead.

      However if you don’t already have a private CA in place then commercial CA’s are the best way to go.

      • well terms private and commercial should not be more confusing.

        I have CA installed on Exchange server itself and has issued selfsigned certificate.
        this set-up and certificate is working for other machines/clients. but not working for 2/3 clients.

        what is Private CA ?

        • A private CA is one you install and maintain yourself in your environment, eg installing Certificate Services on a Windows Server in your Active Directory.

          I don’t recommend installing Certificate Services on your Exchange server.

  3. well that set-up there before I started managing it.

    well any clue guess how I should take care of this issue

  4. It absolutely baffles me that the whole SSL cert thing has to be so friggin confusing. You could make a career out of that topic alone.
    I have a new Exchange 2013 server, using an SSL cert from a trusted supplier. Outlook 2013 clients are set up with the proxy name being the public FQDN: mail.publicdomainname.com
    I have set up a static A record in the DNS, so client systems inside the LAN still use that address to find the server. Made sure the bindings are what they should be.
    The Outlook proxy keeps changing, all by itself, to server.domain.local, and then giving the error regarding the name on the security cert being invalid or not matching the name of the target site server.domain.local.
    Where do I change it so the LAN name isn’t being pushed out to the clients?

    • Exchange 2013 has two URLs for Outlook Anywhere – an internal one and an external one. My guess is you’ve still got an internal one configured for server.domain.local.

      An example here:
      http://exchangeserverpro.com/avoiding-exchange-2013-server-names-ssl-certificates/

      • Rob Pelletier says:

        Haven’t read it all the way through yet, but your article is exactly what I needed for setting this up. I used only the public FQDN on the SSL cert, and used a series of Exchange Powershell commands to define the internal and external URLs.

        For some reason the internal one didn’t accept the definition. I found a place in the Exchange mgmt console to change it. Had already made the appropriate changes to the DNS, so it’s now working normally.

        Looking forward to giving your doc a thorough read – looks like just the info I need for finally understanding all this.

        Thanks.

      • Dan Ramirez says:

        Hi Paul, thank you for time and sharing your knowledge. Hoping you can help me out. I just stood up an Exchange 2013 environment co-existing with Exchange 2010. I have 2 test users on Ex-2013 now and they are getting this pop in Outlook. The CAS servers FQDN is somehow being used to connect and I cannot for the life of me figure out where its coming from. I ran through your article and have all endpoints configured to use 1 name space which is out external name space(we have a split DNS config as your article points out). Any pointers of what I should look for to fix issue why Outlook 2013 clients are connecting to CAS FQDN and not the configured internal name space. Thanks again Paul.

Leave a Comment

*

We are an Authorized DigiCert™ SSL Partner.