Home » Exchange Server » Outlook 2013 SSL Trust Errors When Connecting to Exchange Server

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.

 

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

24 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. Atul says:

    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.

      • Atul says:

        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.

          • Julio Baptista says:

            Hi Paul,
            If we don’t have a valid certificate on my Exchange 2013 lab it’s possible to access my email using internet?
            Best Regards!
            Julio Baptista.

  3. Rob says:

    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?

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

  4. wagdi says:

    Hi Paul
    I faced the above SSL trust error Although I’m using a trusted SSL cert from godaddy. this cert is installed correctly because i can use it with OWA and ECP. I did not experience this problem on all devices , but only some of them. my other problem is when I try to connect to the exchange server with outlook 2007 or 2010 from LAN some computers connect perfectly using autodiscover and some of them connect using also autodiscover but with no address book and some can not connect to the server and showing a message said server is not online. I have a TMG server but I’m not publish my exchange through it. (the exchange server has a real IP and connect directly to the router). In some devices when I remove the proxy from internet explorer they connect perfectly to the server but this does not work with all devices.
    Please, advise me as you always do

  5. Nazir says:

    I’m getting the same error for some users. But my situation is little different..we have people coming from another company and using our machines..they have two email, one from our company and one from their company…Do we need to do anything from our end..

  6. Eddie says:

    Hello. We went from a wild card go daddy certificate to a go daddy SAN certificate. Our domains are all listed in the certificate. We can go to web access with no errors. Correct certificate. All apple clients can connect with no challenge. But when we try to connect externally with Outlook we get the error listed in this article. Go Daddy has confirmed the certificate is installed correctly. We use TMG on our edge server as the externally facing server. Any ideas? Two days on this, can’t figure it out. Thanks!!

    • You’ve installed the new cert on the TMG as well?

      Try running the Outlook Connectivity test on ExRCA.com. It will show you diagnostic info that might help you narrow down the issue.

  7. Julio Baptista says:

    Hi Paul,
    I have my exhange 2013 installed on my lab but i need to know if i don’t have a valide certificate it’s possible to access my exchange from outside?

    So right now i have some problema that outlook not connected to exchange server because the error was Proxy server.
    Can you help me to explain?

    • “Valid” means that the certificate:
      – matches the name the client is trying to connect to
      – is issued by a CA that the client trusts
      – has not expired

      For a test lab, it’s common to install Certificate Services on the domain controller and issue certs for Exchange from there. Then you can import the root certificate for your CA into the trusted root certs on your client, and the client will trust the certificates that CA issues.

Leave a Reply

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