URL: When using Outlook or ActiveSync you may see Security Alerts dialog box. Outlook for Windows The information you exchange with this site cannot be viewed to change by others. However, there is a problem with the site’s security certificate. There are 7 variations of this error:. Red X next to The name on the security certificate is invalid or does not match the name of the site. Red X next to The security certificate has expired or is not yet valid.

Red X next to The security certificate was issued by a company you have not chosen to trust. Two red X next to The security certificate has expired or is not yet valid and The name on the security certificate is invalid or does not match the name of the site. Two red X next to The security certificate was issued by a company you have not chosen to trust and The security certificate has expired or is not yet valid. Two red X next to The security certificate was issued by a company you have not chosen to trust and The name on the security certificate is invalid or does not match the name of the site. Tree red X next to all certificate checks. Outlook for Mac On Mac computers you may see the with the following wording: A secure connection cannot be established with the server because its intermediate or root certificate cannot be found.

ActiveSync On mobile devices you can see the following errors:. iOS devices. Android devices Resolution:. All users are affected:. Check you have correct autodiscover record configured for your domain. Find correct autodiscover record in HostPilot速 Control Panel Home Exchange Servers & Settings. Verify autodiscover.yourdomain.com resolves to the same value globally (e.g.

Via website). If you have the website running on youdomain.com, check your website has appropriate certificates installed.

If it returns SSL certificate error, contact your web-developer and request SSL certificate to be installed or updated. As the workaround you may add correct autodiscover entry to HOSTs file: read the Knowledge Base article on. If you have the website running on yourdomain.com, check how your website deals with.XML files. When Outlook is looking for autodiscover record it checks, some websites are configured to process requests to yourdomain.com/something/etc with the particular response. If Outlook receives the response with any.XML file, it considers autodiscover is found when actually it does not. Contact your web developer and request to make appropriate changes (e.g.

Set website responses with Page Not Found). Check whether you have local autodiscover setup in your Domain Name System. Read the Knowledge Base article on One user / particular machine is affected:. Check you have the correct date, time and time zone setup on the affected machine. Check autodiscover resolves correctly on the affected machine. Open Command Prompt and type in ping autodiscover.yourdomain.com.

It should return correct autodiscover IP address. You may find correct autodiscover value under HostPilot Home Exchange Servers & Settings. Ping autodiscover server and compare IP addresses. If they do not match:.

Check HOSTS file for any mentions of autodiscover and remove them. Read the Knowledge Base article on. Check whether correct autodiscover record is created for your domain globally. Check whether you have local autodiscover record in place.

Read the Knowledge base article on. Perform flush DNS: open Command prompt and type in ipconfig / flushdns. Click on View Certificate on error window, add the mentioned certificate to the trusted ones in Certificate manager: Start in search field type in certmgr. Msc press Enter find mentioned certificate and move it to Trusted Root Certification Authorities Certificates directory.

If you cannot resolve the issue, provide support with the following info:. Screenshot of the error. Ping results of autodiscover.yourdomain.com.

After into your organization you may receive reports from your end users of a security alert containing certificate warning messages appearing in Outlook. Example of an Outlook certificate warning The two most common problems reported by the Outlook certificate warning message are:. The name on the security certificate is invalid or does not match the name of the site. The security certificate was issued by a company you have not chosen to trust Why Does Outlook Display a Security Warning for a Certificate Problem? When you install into your Active Directory environment the setup process registers a Service Connection Point (SCP) for the Autodiscover service. Autodiscover is used by client applications to discover information about Exchange mailboxes and services. For example, Outlook uses Autodiscover during the setup of a new Outlook profile to discover the server settings for the user, so that the profile can be automatically configured (instead of the old days of manually entering server names and other details into Outlook).

By default the Autodiscover SCP is registered using a URL that includes the Exchange server's fully-qualified domain name. You can see the Autodiscover URL for an Exchange 2016 server by running the cmdlet in the Exchange Management Shell. Https: //exserver.exchange2016demo.com/Autodiscover/Autodiscover.xml Note: Previous versions of Exchange used the Get-ClientAccessServer cmdlet.

With the changes in Exchange 2016 server roles architecture the new cmdlets for these management tasks are.-ClientAccessService. The old cmdlets are still available in Exchange 2016, but if you use them you will see a warning message that they are deprecated. Autodiscover is accessible via an HTTPS (SSL) connection from clients. The Exchange server also has a number of other web services that are accessible using HTTPS connections from clients, such as Exchange Web Services (EWS), Outlook on the web (also known as OWA), ActiveSync (for mobile devices), and Outlook Anywhere (used by Outlook clients). However, as this is also a new server installation all of the other HTTPS services also need their URLs reconfigured. You can read more about that, and also download my PowerShell script to make the process easier.

In some cases an IIS restart on the server is also necessary after configuring the namespaces. You also need to add a DNS record for the namespace if one does not already exist. In this example I add an A record of “mail” to my internal DNS zone, and point it to the IP address of the Exchange 2016 server (because it is the only server in the organization). If you have multiple Exchange servers then either DNS round robin or a load balancer could be used instead. Install a Valid SSL Certificate With the namespaces correctly configured, and DNS records in place, you will then need to provision an SSL certificate for the Exchange 2016 server.

If this is a new concept for you then I recommend some additional reading:. To provision an SSL certificate for your Exchange 2016 server the process is:. (CSR). Submit the CSR to a certificate authority such as. Summary The common causes of Outlook security alerts containing certificate warnings are misconfigured Exchange server namespaces, and invalid SSL certificates. Using the steps demonstrated above you can reconfigure your namespaces and/or install a valid SSL certificate. When your Exchange server's configuration has been corrected the Outlook security alerts should stop appearing for your end users.

Paul, I created with the FQDN to IP, added that IP in Exchange 2016 (only have one yet) in coexistence with Exchange 2010 and ran the command to change the InternalUri the Autodiscovery. What I realized on the client outlook? He communicated with the IP of the new FQDN, but looking at the status of the client connection outlook, it is still showing that you are connected to the FQDN of the server, which should be the new FQDN that changed in InternalUri. I logged with another user and created from scratch profile and he did the same thing, it shows that the FQDN is connected with the server name instead of showing logging in FQDN that created again. What could be wrong?

Thanks for your amazing articles! I have followed all of your information about this certificate warning, but I have one pesky machine that is still throwing this warning.

All of the other machines do not show the warning. They are all using Outlook 2007 (yes, I know it is not supported with Exchange 2016, but it is working). The one with the issue is the only Outlook 2013 install in the whole company. I did a ctrl click on outlook icon in the system tray and chose to test auto configuration and in the results, all of the entries have the correct FQDN. On the exchange server, I have set ALL of the virtual directories with the same FQDN for internal and external. I have an internal DNS entry for the server pointing to the internal address, and in our outside DNS, the entry points to the outside ip. Everything seems correct, yet this one machine still throws the error.

Paul, I can always count on you when I’ve been banging my head on a wall. I am about to help a small business client switch to an external trusted cert and I was testing on my own two node dag. I created new (self-signed) cert with only the webmail.domainname.com and autodiscover.domainname.com. I modified ALL the Virtual Directories (multiple times because it still gave cert error). I would open Outlook and after 20-30 seconds I’d get the security cert error pop-up with the name of one of my exchange servers. Then I saw your comment about Outlook profiles hanging on to outdated information. I created a new profile about 30 minutes ago.

Mailbox has finished sync’ing up and I still haven’t gotten the offending pop-up. I looked in the registry in my old profile and did not see the server name anywhere.

Anyway to clean that up without creating a new profile. I can see this will be an issue with the small business that I’m about to switch certs. Oh well.they pay me by the hour. Not the Server’s FQDN, sorry if I was misunderstood. The server’s FQDN is xyzserver.xyz.local.

The external URI is mail.xzy.com. The internal URI is also mail.xyz.com. The internal DNS server points mail.xyz.com to 192.168.1.3, while external DNS points it to some outside public ip. If they ping from their worksation mail.xyz.com they get 192.168.1.3.

That is what I meant. On the exchange server, I set all of the Virtual servers to use mail.xyz.com as the internal and external URI. So when configuring Outlook 2007 (again, I know it is not supported), I put mail.xyz.com as the server name and mail.xyz.com in the outlook anywhere proxy section. On Outlook 2013, it does it all automatically, so I put in her email address (Janedoe@xyz.com) and her password and it auto configures nicely. I even tried doing it manually and typing in the servername, mail.xyz.com, but it ends up the same as if I had let it autoconfigure. End result is that on Outlook 2013, she still gets the certificate warning. Is it possible to prevent exchange from “announcing” those virtual directories immediately?

Even if the SCP is changed to the “correct” DNS name as fast as possible, it seems that the virtual directories are distributed to outlook clients and somehow cached on the existing exchange servers. We have a lot of outlook online clients, and I could not prevent the certificate warning for almost an hour. Had to reset IIS on the existing exchange 2013 servers, which made a lot of noise also.

I have the same problem with my Exchange 2016, the first of all I’d like to thank you for your greate arcticles about Exchange. So I’ve got a problem with autodiscover in internal network. I installed 2 mailbox servers and 2 Edge in DMZ. I created DAG and included 2 servers, it is assigned IP and FQDN for DAG. I use 2013 outlook and then i try to connect to exchange the connection is fail.

Appears the window “The action can not be completed. The connection to Microsoft Exchange is Unavailable ” I’m sad. I read your article and took decision to create in my internal DNS CNAME record “Mail” for target host of DAG. I created new certificate in my local certification authority and impoted him to both servers. The certificate has SAN. There are two records in SAN field such as autodiscover.domain.ru and mail.domain.ru.

All virtual directory in both servers I change to, ecp, and etc. I executed the command: Get-ClientAccessServer AutoDiscoverServiceInternalUri the result of command is displayed for both servers: AutoDiscoverServiceInternalUri For Outlookanywhere I assigned mail.domain.ru for both servers as well. As I know in previous version of Exchange we have to change Cas server to FQDN CassArray Name or Alias in mailbox setings.

I mean we should run command Set-MailboxDatabase -RpcClientAccessServer, but the commant as I know occur with error. Paul, sorry for my long story. Do you have any ideas what I have to do? May be I should create Cname records for FQDN the both servers and include them in certificate? The Client Access namespaces should not resolve to the DAG IP.

They should resolve to the Mailbox server IP address, or to the load balanced VIP. If you’re not using a load-balancer then you can use DNS round robin instead. It is demonstrated here: (the same applies to Exchange 2013 as 2016) 2. Hopefully your DAG’s FQDN is not mail.domain.ru.

Setting the RPCClientAccessServer on databases is not required in Exchange 2013 or 2016. You might have missed a virtual directory in your configuration. Use my GetExchangeURLs.ps1 script here. Sorry for long break. My DAG’s FQDN is not mail.domain.ru and I’ve used your script to change my Exchange’s virtual directory from FQDN to mail.domain.ru for both Servers. But when I try to connect to Exchnge occurs fail and appears a notice ” The connection to Microsoft Exchange is unavailable”.

Certificate is a valid and not self-signed. I took desicion to use DNS Roun Robin. So, outlook try to connect not namespace mail.cpxdemo.ru and to one of FQDN.

OWA, ECP and etc. Are working perfect. Do I need to configurate anything more? By the way, I changed only internal URLs, external URLs have not used and no internet access. Another important consideration when you run into this issue after installing a 2016 server in your environment is MAPI over HTTP. When you install the first 2016 server MAPI over HTTP is enabled and if the new 2016 server which is a CAS by default resides in the same site as your old CAS server it will proxy and server clients. When we encountered this issue after installing our first 2016 server we corrected the issue by fixing the MAPI VD internal and external URLS to use our DNS alias which resolved the issue for us.

I am in the process of migrating from 2010 to 2016. I moved over a few mailboxes, and then I started receiving an error. “There is a problem with the proxy server’s security certificate.

The name on the security certificate is invalid or does not match the target site FQDN of my server. Outlook is unable to connect to the proxy server. (Error Code 10) The strange thing is that half of the users I have migrated work without any issues.

In addition, any NEW users connect with no issues either. I can just click ok to the error, and everything still works, but its annoying and I would like to resolve this prior to completing the migration.

Hi, I have a very weird problem. I am running 2 x Win2012 servers with Exchange 2016 CU1, in DAG configuration with kemp loadbalancer in front. I have a valid SSL certificate from COMODO, which is installed on both servers and all services are assigned to it. Now, when I open from browser ECP – the connection is secured and I get green bar. However when I open the same URL but OWA, the bar is green only up to the login screen.

Once done, when all mails are displayed, the connection becomes unsecured displaying a self signed certificate is used, which is not even installed or visible through the management center. The configuration: PS C:Windowssystem32Get-ExchangeCertificate -Server Exchange Thumbprint Services Subject ———- ——– ——- XXXXXXXXXXXXXXXXXXXXXXXXXXXX IP.WS. CN=mail.domain.be, OU=PositiveSSL Multi-Domain, OU=Domain XXXXXXXXXXXXXXXXXXXXXXXXXX. Hi, first of all thanks so much for great articles. I’ve recently installed an Exchange 2016, with multi tenancy.

Assume I have 2 domain: DoaminA.com and DomainB.com. Now how am I supposed to configure autodiscover URI? I have 2 accepted domain, so I created 2 SRV record instead of “autodiscover.DomainA.com” and “autodiscover.DomainB.com”.But I don’t have any valid SSL yet.

The problem is people can’t connect to exchange through outlook 🙁 it’s ok with IOS Mail application though! Any help would be really great thanks in advanced. Hello Paul First of all, thanks for a great article! As always you make things brilliantly easy to understand. I have question which I hope you will find time to reply to. I’m planning to install Exchange 2016 into an existing Exchange 2010 organization which consists of one server only.

Add Certificate To Outlook 2016

However, I don’t plan to configure anything else (routing, connectors, etc.) on Exchange 2016 for some months. Question is – will just installing Exchange 2016 to leave it alone without configuration – affect the existing autodiscover/Outlook Anywhere functionality? Thanks in advance. Have a nice day. Having trouble getting my certificate warning to go away and outlook anywhere working properly. My local domain is internal we will say exchange.contoso.internal. I have a FQDN mail.contoso.com that is signed to that domain and also autodiscover.contoso.com.

Local clients still get a certificate warning pointing to exchange.contoso.internal after running your powershell script on exchange 2016. In DNS I have authority setup for contoso.com and have an a record for mail.contoso.com pointing to my internal IP of exchange (also one for autodiscover.contoso.com). OWA works from outside and in, mail is flowing. Local outlook clients work fine except for the cert warning. After running the script some outlook clients have troubles connecting, they continually ask for a password even after providing the correct credentials. Hi Paul, I’m having issues with Outlook 2016 after upgrading from 2013.

I had to add AutoDiscover (autodicover.domain.com) to our External DNS in order for 2016 to get the mail profile. The mail server used to be remote.domain.com. The DNS entry is still there but outlook is looking for remote.domain.com and the cert displays autodiscover.domain.com. I understand that they don’t match and I’m getting the “The name on the security certificate is invalid or does not match the name of the site” warning when launching outlook.

Do you know of a way I can remedy this? Installing the self-signed certificate is not working correctly. Thanks in advance! Excellent article! I have read it several times to match the settings on my Server 2016. Though, Outlook is still generating the error: serv2016.xyz2.local The name on the Server is the domain controller + DNS +Exchange My local domain name is xyz2.local but actual email domain name is xyz.com. Autodiscover and OWA work from outside.

On the SSL, I have: autodiscover.xyz.com xyz.com email.xyz.com DNS on the server has: email (Host A) (FQDN: email.xyz2.local) pointing to server’s private IP Any suggestion will be much appreciated. Update – Resolved the issue by following the article: I had to apply both methods to resolve the issue.

Just changing the registry did not do the trick. In Method 2, I didn’t have to use the new profile after creating it. Just adding it was enough. The article’s title suggests the solution is for Office365 and it does not mention the Security Alert message. Though, in my case, we have Exchange 2016 and machines were getting invalid name security alert.

So the solution works for in-house Exchange as well. A little more on the Cert warning that people often get. We are receiving in Mac Outlook a cert warning for the DNS Domain Name. “exchange.DNSdomain.com” but this is listed only as an internal name. Exchange users “exchange.mailDomains.com” for auto discover in DNS and as configured on the exchange server. Why would outlook keep hunting for a secure connection to the “exchange.DNSdomain.com” when it is not external used? How is it even picking this up when the DNS Auto discover setings are correctly set and tested with the connectivity test website?

Outlook checks for Autodiscover in a number of different ways. One of them is by looking for the well known CNAME of “autodiscover”. If that resolves in DNS, it will try to connect.

You can suppress that lookup using Group Policy. Or you can remove the DNS record (but that might break other clients relying on it). The other possibility is that your CAS Autodiscover Internal URI is set to that URL. That will not be tested by the connectivity analyzer, because it’s only testing externally and can’t see the Autodiscover SCP that is used inside your domain. So you should check that as well.

Thanks for replying. I am following guidance given under this link so this is what i will be doing. After installing exchange 2013 with 2007. I will be creating following namespaces: Exchange 2007 has Ip address: 172.16.90.3 for exchange 2007:A record for mail.domain.sk.ca 172.16.90.3 for exchange 2007:A record for Autodiscovery.domian.sk.ca 172.16.90.3 for exchange 2013:A record for legacy.domain.sk.ca 172.16.90.3 new exchange 2013: 172.16.90.93 for exchange 2013:A record for mail.domain.sk.ca 172.16.90.93 for exchange 2013:A record for Autodiscovery.domian.sk.ca 172.16.90.93 i read some of your guidance documents, not sure but do i have to remove first two A records for Exchange 2007 and leave all others on Domain Controller. Thanks, Amjad. One more thing to mention.

Autodiscover.domain.sk.ca name space was not configured on exchange 2007 previously. It was left by default and no name space was there so i created name space and changed it on exchange server 2007 to using PS: Get-ClientAccessServer -Identity SPC-EXCH1 fl AutoDiscoverServiceInternalURI output was: todiscover.xml so i believe it has not been configured properly.

I plan to change it Set-ClientAccessServer -Identity spc-exch1 -AutoDiscoverServiceInternalURI will it create any problem for the client which are already connected and do i have to assign new certificates on exchange 2007. One more thing to mention. Autodiscover.domain.sk.ca name space was not configured for exchange 2007 on Domian controller previously. It was left by default and no name space was there so i created name space and changed it on exchange server 2007 to using PS: Get-ClientAccessServer -Identity SPC-EXCH1 fl AutoDiscoverServiceInternalURI output was: todiscover.xml so i believe it has not been configured properly. I plan to change it Set-ClientAccessServer -Identity spc-exch1 -AutoDiscoverServiceInternalURI will it create any problem for the client which are already connected and do i have to assign new certificates on exchange 2007.

Hi Paul, I tried to put some comments but i believe bcz of ip address and other configuration they get removed. I am following guidance given under techgenix and a guy tried to explain everything but i am stuck at this point. So this is what i will be doing. After installing exchange 2013 with 2007.

I will be creating following namespaces: Exchange 2007 has Ip address: x.x.x.3 for exchange 2007:A record for mail.domain.com x.x.x.3 for exchange 2007:A record for Autodiscovery.domian.com x.x.x.3 for exchange 2013:A record for legacy.domain.com x.x.x.3 new exchange 2013: x.x.x.93 for exchange 2013:A record for mail.domain.com x.x.x.93 for exchange 2013:A record for Autodiscovery. Domian.com x.x.x.93 i read some of your guidance documents, not sure but do i have to remove first two A records for Exchange 2007 and leave all others on Domain Controller. One more thing to mention. Autodiscover.mydomain.com name space was not configured on exchange 2007 previously. It was left by default and no name space was there so i created name space and changed it on exchange server 2007 to using PS: Get-ClientAccessServer -Identity SPC-EXCH1 fl AutoDiscoverServiceInternalURI output was: so i believe it has not been configured properly. I plan to change it Set-ClientAccessServer -Identity spc-exch1 -AutoDiscoverServiceInternalURI will it create any problem for the client which are already connected and do i have to assign new certificates on exchange 2007.

Hopefully this time my comments will go through. As i removed all ip address. Thanks, Amjad. Hi Paul Thanks for all the good content and info across your whole site.

Im in the middle of an upgrade from 2010 to 2016 and having teething issues. 2010 was not installed perfectly.

The virtual directories and autodiscover are set to the server names along with a few other config’s I dont know are right or not. Anyway I am getting the certificate issue for a user on the 2016 server. The cert is SSL form GoDaddy and has the mail domain name.

I had to export this from the old 2010 server and import to the new. Per Microsoft instructions, the cert on the Exchange server when viewed has the certificate authorises in the chain as expected.

However when you go view the cert from outlook error it does not contain the chain just the email domain. So it states it does not trust the provider. It was installed correctly and added to all the services including mapi so a bit stuck. Passed that outlook cant find the server. I put in a host file to point email.domain to the new exchange and autodiscover.domain.com to new exchange but no luck Cheers for any advice Sean. Hi Paul Thanks for replying.

Install Email Certificate Outlook 2016

So yes clients connecting to the 2010 exchange get a cert error. Now i put this down to the fact that the virt directories were never configured to the name on the cert.

They were left as the server name. My thinking was to leave that as is, I set the correct name on the virt directories on the new exchange and then could right away point the dns record at the new exchange.

Here is were I am. Outlook 2010 clients connect to the new exchange with a proxy error code 10 but still work. Outlook 2013 clients cant find the server.

So it must be security related, but in essence autodiscover is failing? I have changed the virt directories back to the server name as if I use a machine with a host file pointing mail domain to the new exchange not even the 2010 clients can connect to it. Great articles. But I did not find a solution to my issue. After installing two servers, Server 2016/AD/DNS and Server 2016/Echange 2016 CU7, and configured and tested that I could send and receive email. I then made what I think now is the blunder.

I renamed the Exchange server to follow a name standard, from SD-EX-01 to SD-EX-001. After this I can’t log in with or /owa anymore (also not the host or fqdn).

When I look at the certificate when I get the warning, I see it has SD-EX-01 and not the new name in it. I seem stuck. Any suggestions how to proceed or do I reinstall? I had an exchange server failure this past weekend. I have rebuilt the server. I was able to get the DAG reconfigured and the DB’s in the DAG.

All is good there. Now I am getting a certificate error so I noticed the certificate is assigned to the server that existed already but it is missing from the newly formatted and installed server. I have tried to export and import the certificate from the original server but I keep getting this error. A special Rpc error occurs on server XCH02: Cannot import certificate.

A certificate with the thumbprint FCBF254E775FC90925ED5AD997DC4A already exists. I am not sure where to go with this and was wondering if you could pleas offer me some assistance.

Anything is greatly appreciated. We will be installing 3 new 2016 Exchange servers that will only be used for the migration of mailboxes to Office 365 so we can achieve greater throughput. They will never be used in the production Exchange environment going forward. Is there a recommended best practice during install or config to avoid these servers ever being used for Autodiscover services and the certificate prompts? If all Exchange traffic hits a load balancer first which directs traffic to the production servers can we just change the internalURI and be done with it? Paul, thx for your article. Can you help me in configuring namespaces for our Exchange?

We have domainname kalina.ru, Windows Server AD with name b26.kalina.ru. Exchange Server with name forth.b26.kalina.ru. InternalURLs configured to mail.kalina.ru and extrenalURLs to kalina.ru mail.kalina.ru is CNAME forth.b26.kalina.ru and when users in office launch Outlook they got warning about certificate (name mismatch forth.b26.kalina.ru), which issued by Geotrust to.kalina.ru and kalina.ru. When users connect via browser to – certificate shows as valid, with green lock. DNS server has 2 zones: kalina.ru and b26.kalina.ru For kalina.ru we use next data: SOA: kalina.ru A: external IP MX: kalina.ru autodiscover CNAME mail.kalina.ru mail CNAME forth.b26.kalina.ru mx: external IP Can you explain how to properly configure the DNS records so that we do not receive a certificate warning?