Outlook Security Alert after SSL Certificate Updated on CAS

Problem:  We recently renewed an expiring SSL certificate for Exchange 2010 (removed internal fqdns) and now Outlook clients get SSL security alert when launched.

Background Info
Due to an 11/1/15 expiration of using internal FQDNs (our domain ends in .local), we've changed the UCC SAN cert to only include:


We setup split dns to ensure the 2 external FQDNs above can be resolved internally, then ran a bunch of powershell SET commands so our Exchange environemnt will use same URi's for both internal and external.

Everything is working well, EXCEPT...

Our Outlook 2010 and 2013 clients get an ssl security alert ONCE when first opening Outlook.  
The alert has the INTERNAL fqdn of our CAS server on it
Since that is no longer on the new UCC SAN cert, the security alert pops up.
Some part of the Outlook profile (maybe cached) is still pointing the Outlook client to CAS server's internal FQDN vs. the new public FQDN  

Clicking yes makes it go away for duration of outlook being open.  Of course, it will become very annoying to end users after a while.

Every article I've researched says the same thing...make sure none of the intrenal URis point to old way (internal FQDN of CAS server).  I've triple checked that.  

Seems only reliable way to make this go away is rebuilding local outlook profile which I want to avoid (100 users).  Oddly, one Outlook 2013 client seems to have had alert stop showing up, but not others in my test pool.

Troubleshooting Done So Far

Again, triple checked all commands launched on CAS server - the internal URi definitely matches external URi in following commands below.  Each of these attributes previously showed the internal FQDN of the CAS but not anymore.  Now all show mail.example.com:

*Using CAS_hostname for examples below:

Get-ClientAccessServer -Identity CAS_hostname | fl AutodiscoverServiceInternalUri
Get-WebServicesVirtualDirectory -Identity "CAS_hostname\EWS (Default Web Site)" | fl InternalUrl
Get-OabVirtualDirectory -Identity "CAS_hostname\oab (Default Web Site)" | fl InternalUrl
Get-ActiveSyncVirtualDirectory -Identity "CAS_hostname\Microsoft-Server-ActiveSync (DefaultWeb Site)" | fl InternalUrl
Get-OwaVirtualDirectory -Identity "CAS_hostname\owa (Default Web Site)" | fl InternalUrl
Get-EcpVirtualDirectory -Identity "CAS_hostname\ecp (Default Web Site)" | fl InternalUrl

The only item that was not changed is the OutlookAnywhere attribute because internalHostname was blank before we converted:

Get-OutlookAnywhere -Identity "HostName\Rpc (Default Web Site)" | fl InternalHostname, InternalClientsRequireSsl

I've also checked the SCP using AD Sites & Services and it correctly shows the internal URi is our pubilc FQDN (mail.example.com)

Most articles claim this is due to AutodiscoverServiceInternalUri still being set to the internal CAS FQDN, but ours is definitely set correctly along with all other attributes.  

All internal Outlook clients are using Cached Exchange Mode and connect fine.  They just have the annoying single security alert.

I've tried a bunch of things including the Outlook "Test email auto configuration" which comes back with the correct public FQDNs and no mention of the CAS server's true internal FQDN.

I've also tried going to Outlook account settings and choosing repair to see if it will run refresh setup and detect changes completely without rebuilding the entire profile.  This seemed promising but did not work.

I've tried clearing SSL state on local PC and rebooting - does not help.

Does anyone know how I can get Outlook profiles to stop showing this prompt at launch?  It makes no sense that they still are looking at CAS internal FQDN for something...

Many thanks!!!!
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Amit KumarCommented:
Your question explaination is very good and long.

Simple thing I want to tell. if you using split DNS (Internal - mail.domain.local and external - mail.domain.com) then your certificate should contains both DNS names. either you use single DNS (mail.domain.com) for internal and external then you can use only external DNS.

In this case you can create DNS (mail.domain.com) record pointing to private IP of CAS server in internal DNS server and with public IP of CAS in external registrar/hosted DNS server.
dpmoneyAuthor Commented:
HI Amit.  Thanks for the reply.  Yes, we made sure the newly installed certificate  has both:


We also already setup split DNS and name resolution for both FQDNs above is working perfectly - both from inside (public DNS) and outside (internal Active Directory DNS).

Still need a way to get Outlook to stop prompting with security alert at launch of Outlook.

Amit KumarCommented:
Try configuring a new system with outlook and see do you get alert on new system.

if not then please clear certificate state by Internet explorer or check if system has any bad/old certificate which is conflicting.

Also please verify you have updated certificates on all CAS servers.
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

dpmoneyAuthor Commented:
On new Outlook profiles since this cert renewal, the alert does not pop-up when Outlook is launched.
Only happens with previously existing profiles (Outlook 2013 and 2010)
I've tried clearing ssl certificate state in IE then rebooted - doesn't work
Also have the new cert on both CAS servers
Adam FarageSr. Enterprise ArchitectCommented:
On a machine where you can repro the issue run the following command, report back with a screen shot if possible:

Outlook.exe /rpcdiag

I am curious if the clients OST file is causing the issue.. which would be odd for all 100 machines. The other thing could be something like OCT (Office Customization Toolkit) which could also cause this if you deployed custom PRF (Profile) files to the client machines.
dpmoneyAuthor Commented:
I'll be back on-site tomorrow and will try the /rpcdiag

We are not using OCT or custom PRF

This is happening as a result of the change from Outlook/Exchange using the public FQDN vs. the internal FQDN.  All relevant pointers changed but the local profile must cache a pointer to the old interanl URi.
dpmoneyAuthor Commented:
@Adam Farage:

The outlook.exe /rpcdiag is the same on the Outlook client that is showing the alert at launch and one that is not.

2 RPC connections to the internal FQDN of our Casarray name
1 RPC connection to the internal FQDN of our mailbox DB server name - for public folders (Which we don't even use but it was a carryover from the 2003 to 2010 migration)

No difference...
dpmoneyAuthor Commented:
*** SOLUTION ***

To anyone else who goes through the similar transition that we did, I have found a simple solution.

Each time Outlook was launched following this transition, the certificate name mismatch security alert appeared.

I instructed users to click Yes in order to ignore the mismatch and continue.  Next time Outlook launched, it prompted them again.

Today, we confirmed that simply clicking No at the name mismatch security alert makes the alert not show up again and all functionality appears to be totally normal.

I'm going to mark this as the solution unless someone can provide a good technical explanation into why it does not bother users after clicking No.  My guess is Outlook has the internal FQDN cached, and clicking No forces it to connect another way (specifically using the updated Internal URi which is now the public FQDN).  I'm not clear which component of Outlook that uses https (Autodiscover, OOF, OAB) was at play here, but I've tested all of them after clicking No and they all work fine.
Adam FarageSr. Enterprise ArchitectCommented:
The certificate prompt could be a number of things, and clicking no is surprising that it worked in my opinion. This might be autodiscover acting funky within Outlook (which is typically the issue) but I am glad you have it resolved.
dpmoneyAuthor Commented:

Agreed, very strange, but it does indeed work.  I've tested Out of Office, Free Busy Time, and Offline Address Book updates by modifying a user's last name in AD (shows up in Outlook address book next day).  

As noted above, I really believe some element of the cached exchange mode was hanging on to the internal FQDN reference vs. picking up the modified URi that was made for using the 6 Powershell commands at the beginning of this thread.

A key thing to point out is even though these are all domain PCs on the internal network, the Outlook auto configures itself to run in "cached exchange mode".   The URL for the proxy server is auto-configured as mail.domain.com, yet the server name is the FQDN of our CASArray which is examplecas.domain.local.  This is the same config both before and after the internal URi values were changed from internal FQDN name to public FQDN names this weekend.

Bottom-line, its working.  I wish someone who is a very deep expert on Outlook/Exchange interaction (perhaps from MSFT) would shed some light on this case and why we got that prompt each time Outlook launched after these changes.   Until then, I'm going to roll with my suspicion that it was simply a cached reference that was forcefully re-queried and updated when we clicked No.

Thanks for the input!
Adam FarageSr. Enterprise ArchitectCommented:
I probably should have asked this before, but I think I know the answer. Let me ask some questions first prior to getting there:

1) What is the FQDN of your CAS Array, feel free to omit it out
2) What is the FQDN of the domain causing the SSL mismatch error
3) If you run the following command below, what is the output?

Get-MailboxDatabase | Select RpcClientAccessServer

Open in new window

I tend to review questions quickly sometimes, and not quickly enough. For some reason I thought you were on Exchange 2013 when I responded above.. but your not.. your on 2010. 2010 uses RPC / MAPI as the default connectivity, so I am curious to see what the response is above.
dpmoneyAuthor Commented:
OK, I ran the command and answered questions below:

1) What is the FQDN of your CAS Array, feel free to omit it out?

excasarray.example.local    (real domain named changed for privacy)

2) What is the FQDN of the domain causing the SSL mismatch error?


the external (and now internal uri) is mail.example.com

3) If you run the following command below, what is the output?

Adam FarageSr. Enterprise ArchitectCommented:
So.. excas01.example.local is throwing out the error? What was that assigned to originally?
dpmoneyAuthor Commented:
excas01.example.local is the internal FQDN of our CAS server.

It's name used to be on the SSL cert from GoDaddy before this weekend's renewal when we had to remove it (and other internal names) as a subject alternative name.  

I think Outlook clients previously connected to the CAS by that name and some aspect of the Outlook profile was remembering it that way.  Maybe it was OOF or OAB.  

By clicking No, I think Outlook was forced to re-discover the connection and noted its internal uri was now setup as mail.example.com to match public facing stuff.

Overall, its been over a week now and clicking No to the daily morning prompt when Outlook first opened has made this go away for good.  

I think Outlook essentially figured it out itself but needed the encouragement by clicking No at the security alert and not letting it proceed using the cached internal FQDN for some aspect of Outlook's profile.  

Users were initially clicking Yes each morning, essentially letting it connect via the name excas01.example.local.  The FQDNs excas01.example.local and mail.example.com both resolve to the same internal IP from our internal DNS.
dpmoneyAuthor Commented:
Here is a mock-up of the security alert.  Of course, the domain name is not really example - just used for illustration purposes

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
dpmoneyAuthor Commented:
Please see thread above and screenshot depicting how we got the daily alert to stop bothering users.  Everything seems to be working OK.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.