When connecting to an Exchange server using Outlook 2013 you may encounter an SSL trust error.
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.
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.
Dear All,
Do ensure all the active directory servers are up and running nd all are replicating properly in your domain and specially the one which is referred by the exchange server
Regards,
one can really make a career out of Exchange certificates.
i have a valid one from a trusted CA, installed it, works fine for Internet connected users. those without Internet access encounters that same errors.
how to fix this?
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?
The Real Person!
The Real Person!
“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.
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!!
The Real Person!
The Real Person!
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.
I have the same issue and I cant even open ECP.
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..
The Real Person!
The Real Person!
Are they getting the error when they connect to your Exchange server? Or when they connect to the Exchange server from their company?
Its weird I get this error for a client using Office 365. I’m assuming their browser is also trying to sue a proxy first?
Pingback: Outlook 2003 Ssl Error
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
The Real Person!
The Real Person!
Sounds the proxy is the issue. I would try adding a bypass to the proxy for the Exchange URLs to make sure clients aren’t still trying to connect via the proxy, if you don’t want them to. Your proxy logs may also show signs of the issues.
You promissed us to find a solution to bypass proxy
I stuck in this problem
Pingback: Outlook Error Code 18 Proxy - ORG.org
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?
The Real Person!
The Real Person!
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:
https://www.practical365.com/avoiding-exchange-2013-server-names-ssl-certificates/
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.
Hello
I have the same problem may you send me the steps that solve your problem
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.
well that set-up there before I started managing it.
well any clue guess how I should take care of this issue
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..
The Real Person!
The Real Person!
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 ?
The Real Person!
The Real Person!
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.
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.
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.