Outlook SSL Error after New Certificate Installation
Recently replaced the SSL cert on our Exchange 2010 box with a new wildcard cert. Assigned services, reconfigured all URL's for external and internal access to be identical (previous cert was a SAN cert with .local domain names and since they are no longer available we are having to change this), setup split DNS so internal and external clients all use the same DNS name for access.
Everything works as expected, with the exception of Outlook clients receiving a mismatch certificate error... it appears the server is presenting the server.domain.local FQDN to the client and with the SSL being *.domain.com it doesn't match...
I have followed all guides/articles I found ensuring that all URL's are setup properly and all point to the same external DNS name. Autodiscover internally also works and passes (we do not have it setup to autodiscover externally but Outlook anywhere does function as it should when manually configured, this has been tested)
What has me perplexed with this issue is that newly created profiles/accounts do not have this issue so it seems to be more of an Outlook profile issue rather than a server issue. I can open Outlook and use my previously configured profile and I get the SSL mismatch error.. If I create a new Outlook profile and setup my account within it, there are no SSL errors at all.
Not certain if anyone has come across this before or not but any advice/help would be greatly appreciated... while rebuilding the Outlook profile does fix the issue, with 25 - 30 users that isn't exactly something I want to have to do.... It isn't something that should have to be done.... Thanks in advance for any response/assistance.
Clay
Edit -
My issue isn't quite like the referenced Outlook Security Alert question... but more so Like this one - Outlook/Exchange certificate errors after setting clientaccessserver, etc… properties... this one seems to be almost identical to my problem... sadly it has no answer though
I have come across same issue while doing migration to Exchange 2013 requiring to replace SSL cert on Exchange 2010 and configure OA to enable proxying through Exchange 2013. Solution to avoid cert pop ups on desktops was to import Outlook 2013 GPO template and enable GPO for Autodiscover to ExcludeLastKnownGoodUrl.
Outlook 2013's new feature to store last known good urls and order of processing connectivity when launched is the culprit :)
Based on a comment you made above, I would like to provide you a clear picture as to what you need to validate in order to make the environment work properly. I'm going to cover all the aspects, so some things you probably already have working. 1. Make sure you have "RPC over HTTP" installed on the Exchange server and properly operating (corresponding event logs can be seen when server boots, for example.
Since you have replaced your SSL cert with wildcard one, you would need to decide how are you going to reference the Exchange server inside your internal network, for a sake of the example, let's make it mail.domain.com for the fqdn and mail for the netbios name.
Run the following CMD-lets to find and SET the correct information as for the virtual directories perspective:
Exchange Control Panel: Get-ecpVirtualDirectory -Server mail | Set-ecpVirtualDirectory -InternalURL https://mail.domain.com/ecp -ExternalURL https://mail.domain.com/ecp
Get-ECPVirtualDirectory -Server mail | Fl InternalURL,ExternalURL
Outlook Web App: Get-OwaVirtualDirectory -Server mail | Set-OwaVirtualDirectory -InternalURL https://mail.domain.com/owa -ExternalURL https://mail.domain.com/owa
Get-OWAVirtualDirectory -Server mail | Fl internalUrl,ExternalURL
EWS (Exchange Web Services): Get-WebservicesVirtualDirectory -Server mail | Set-WebservicesVirtualDirectory -InternalURL https://mail.domain.com/EWS/Exchange.asmx -ExternalURL https://mail.domain.com/EWS/Exchange.asmx
Get-WebservicesVirtualDirectory -Server mail |Fl internalURL,ExternalURL
Autodiscover: Set-ClientAccessServer mail -AutodiscoverServiceInternalUri https://mail.domain.com/Autodiscover/Autodiscover.xml
Get-ClientAccessServer mail | Fl AutodiscoverServiceInternalUri
ActiveSync: Get-ActiveSyncVirtualDirectory -Server mail | Set-ActiveSyncVirtualDirectory -InternalURL https://mail.domain.com/Microsoft-Server-ActiveSync -ExternalURL https://mail.domain.com/Microsoft-Server-ActiveSync
Get-ActiveSyncVirtualDirectory -Server mail | Fl InternalURL,ExternalURL
Offline Address Book: Get-OABVirtualDirectory -Server mail | Set-OABVirtualDirectory -InternalUrl https://mail.domain.com/OAB -ExternalURL https://mail.domain.com/OAB
Get-OABVirtualDirectory -Server mail | Fl InternalURL,ExternalURL
OutlookAnywhere: Set-OutlookAnywhere -Identity mail\Rpc (Default Web Site)" -InternalHostname mail.domain.com -ExternalHostName mail.domain.com -InternalClientAuthenticationMethod ntlm -InternalClientsRequireSsl:$True -ExternalClientAuthenticationMethod Basic -ExternalClientsRequireSsl:$True
Get-OutlookAnywhere -Identity mail\rpc (Default Web Site)" |fl InternalHostName,InternalClientAuthenticationMethod,InternalClientsRequiressl, ExternalHostName,ExternalClientAuthenticationMethod,ExternalClientsRequiressl
Perform iisreset /restart after the script above, remember to replace mail with the actual netbios name of the server and mail.domain.com with the actual fqdn of your Exchange server.
In regards to the Outlook provider see here: http://blogs.technet.com/b/exchange/archive/2008/09/29/3406352.aspx
Let me know if you have any questions.
We had the same issue after removing our local domain from our Exchange certs and went down the same troubleshooting path, Clay.
We found that the 'last known good' cache in Outlook 2013 was the culprit by turning this feature off via the registry for a couple affected PCs.
Then we realized the root cause was because we had left the old "local" record in dns. Outlook 2013 was looking to cache for the old autodiscover, and because it still existed despite not matching the cert, it was never going out to get the new address.
I know this is old but thought it may help someone else.