Link to home
Start Free TrialLog in
Avatar of Kevin Castleman
Kevin CastlemanFlag for United States of America

asked on

Microsoft Exchange 2013, Outlook 2012 invalid security certificate

So a couple weeks ago, what seemed like randomly, a majority of my Outlook clients stopped working.  When Outlook is launched there is an error related to the security certificate.  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 XXXXXXX. (Error Code 8).

I don't know where I need to go to fix this.  The mail server uses a self signed/generated certificate.  We use auto discovery to configure the Outlook clients.  I'm sure it is something easy but I can't figure it out.  In the mean time we have been manually installing the certificate on all the client machines and putting it in the Trusted Root Authority store.  The certificate has been in place at least a year and we used it, installed new outlook clients, added new users without any issue or errors.  Now we get this error every time for every profile, even on machines that already had the certificate manually installed for a different user.

What do I need to change to fix this? I thought about forcefully installing the certificate via command in a login script but I figure there has to be an easier way on the server or related to auto discovery to fix this.
Avatar of arnold
Flag of United States of America image

Check you DCs that serve up autodiscovery/auto discover XML to make sure they have valid certs
Recently answered a question of a similar issue, the asker located the issue was on the HTTPS://ADmdomain/autodiscovepr/autodiscover.xml as the cause.

Will post the link to that post when I can find it.
Avatar of Kevin Castleman


I added the mail servers self generated cert to the trusted root cert authority on both my domain controllers.  I get the same error.  Do I need to store them somewhere else?
Are you pushing those self signed certs as trusted within a GPO to all clients?
Actually yes we are.  The cert is there in the GPO under Trusted Root Certificate Authorities and shows as expires on 9/5/2018.
There are several points where this issue can come up from.
There is the direct access to the exchange server, the other deals with autodiscovery

See if HTTPS:// do you get a certificate error in the browser.
I'm sorry I may be missing something.  I click that link and nothing happens.  I tried changing it to https://myinternaldomain.local/autodiscover/ and and neither replied with results.
That was a try.
identifying the connections your email clients makes and then looking at the cert.

I.e. The certificate is for the exchange server name, but the access from the client is to a different name. This will create a name mismatch that pushing the self signed certificate as trusted will not resolve.
OK so how do I fix that?  It was working for over a year without any issue.  Then something updated and now all I get is errors.
Without knowing where the issue is, I.e. You renewed/regenerated a new self-signed  certificate this year and used the system's name versus the one you used before.
I didn't do either.  It just stopped working one day.  I didn't renew the cert nor did I regenerate a new one.  If we can't troubleshoot the setup as it is, what is the process to create/use a new one so that I don't get these errors.
Where is the issue? Double check the account setup within outlook dealing with what host is being used. Then look to see whether the certificate of that host:port matches the name and not expired.
That is my questions, where is the issue?  it is all accounts, new or old.

the cert matches the name of the mail server.  it is not expired.  I guess I don't understand or know what's missing.
Look on your outlook account configuration. Is it configured through a GPO? Double check what host it pints to versus what certificate is there.

Let's say you have mail.youraddomain.local and the certificate matches that, but in the GPO to auto configure users, you are pushing exchange that also resolves to the same IP.

This will trigger a name mismatch.  Does the error/warning indicate what the issue with the certificate is?
The first problem is using the self signed certificate.
Those are not designed or supported for production use. You should really have a trusted SSL certificate on the server. When you can get a suitable certificate for less than $70/year, it doesn't make any sense to do anything else.

Once you have the certificate sorted out, you then need to correct the configuration of Exchange to support the new SSL certificate. Again easily done, but you need to be consistent with the configuration.

Exchange 2013 uses SSL exclusively, it is not an optional feature.

Avatar of Kevin Castleman
Kevin Castleman
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial