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:
mail.example.com
autodiscover.example.com
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 AutodiscoverServiceInterna
Get-WebServicesVirtualDire
Get-OabVirtualDirectory -Identity "CAS_hostname\oab (Default Web Site)" | fl InternalUrl
Get-ActiveSyncVirtualDirec
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 AutodiscoverServiceInterna
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!!!!
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:
mail.example.com
autodiscover.example.com
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 AutodiscoverServiceInterna
Get-WebServicesVirtualDire
Get-OabVirtualDirectory -Identity "CAS_hostname\oab (Default Web Site)" | fl InternalUrl
Get-ActiveSyncVirtualDirec
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 AutodiscoverServiceInterna
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!!!!
ASKER
HI Amit. Thanks for the reply. Yes, we made sure the newly installed certificate has both:
mail.example.com
autodiscover.example.com
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.
Thanks!
mail.example.com
autodiscover.example.com
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.
Thanks!
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.
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.
ASKER
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
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
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.
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.
ASKER
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.
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.
ASKER
@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...
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...
ASKER
*** 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.
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.
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.
ASKER
@Adam....
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!
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!
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?
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.
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 RpcClientAccessServerI 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.
ASKER
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?
excas01.example.local
the external (and now internal uri) is mail.example.com
3) If you run the following command below, what is the output?
excasarray.example.local
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?
excas01.example.local
the external (and now internal uri) is mail.example.com
3) If you run the following command below, what is the output?
excasarray.example.local
So.. excas01.example.local is throwing out the error? What was that assigned to originally?
ASKER
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Please see thread above and screenshot depicting how we got the daily alert to stop bothering users. Everything seems to be working OK.
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.