365-command-logoThis week’s “Tech Tip of the week” focuses once again on Exchange Hybrid/Coexistence setups and/or migrations to Office 365.  In particular, this tech tip discusses how to alleviate the “annoying” SSL certificate pop-up that your Outlook users will start to receive when the Exchange 2010 or 2013 Hybrid server comes online.

An example of this pop-up is below:

The tip discusses how to alleviate the “annoying” SSL certificate pop-up that your Outlook users will start to receive when the Exchange 2010 or 2013 Hybrid server comes online.

 

 

 

 

 

This occurs because the SSL and/or UCC certificate that you have purchased and installed onto the Exchange 2010/2013 Hybrid server does NOT contain the local/internal URL of the CAS instance of this server, which is often “cas.mycompany.local”, or some kind of local domain that is not publicly searchable/obtainable on the internet.  As a result, the local Autodiscover service is configured to initially use “cas.mycompany.local” as its FQDN, which is why Outlook keeps popping-up this message to your end-users.

In the past, some CAs (Certificate Authorities) would allow you to purchase UCC certificates that could secure the local CAS domain instance as well, but because of the new referendum that no longer allow for internal domains to be trusted in a certificate purchased from a CA after November 1, 2015, CAs have already been implementing policies to eliminate this, which means even today in most cases you cannot purchase a certificate to trust an internal domain, which is leading to more and more problems with this internal pop-up message from Outlook as depicted above. 

Here are some links which talk about this new CA referendum:

http://www.digicert.com/internal-names.htm

http://support.godaddy.com/groups/domains-management-and-services/forum/topic/multi-domain-certificate-with-internal-dns-names-after-november-1-2015/

Thankfully there is a way to adjust/fix this internally on your Exchange 2010/2013 Hybrid server so that this is no longer an issue.  Essentially, you are going to adjust the internal FQDN to reflect the external, publicly facing FQDN for which you do indeed have an SSL/UCC certificate.

To fix this problem, you need to use the Exchange Management Shell (EMS) on the Exchange 2010/2013 server.  For this example, we will assume that internal FQDN is: cas.mycompany.local, and that the public FQDN is pubcas.mydomain.com.

The commands are:

Set-ClientAccessServer –Identity cas –AutodiscoverServiceInternalUri https://pubcas.mydomain.com/autodiscover/autodiscover.xml

Set-WebServicesVirtualDirectory –Identity “EWS (Default Web Site)” –InternalUrl https://pubcas.mydomain.com/ews/exchange.asmx

Set-OABVirtualDirectory –Identity “oab (Default Web Site)” –InternalUrl https://pubcas.mydomain.com/oab

If you are utilizing the Unified Messaging Service (UMS), you will also need to input the following:

Set-UMVirtualDirectory –Identity “unifiedmessaging (Default Web Site)” –InternalUrl https://pubcas.mydomain.com/unifiedmessaging/service.asmx

By using the Tech Tips I have provided above you will alleviate local SSL cert pop-ups.

I hope you found this helpful.  !  To view any of my previous tips, see here:

Shared Mailboxes Part I -What to do if you want or need to convert a full (user) Office 365 mailbox into a Shared Mailbox.

Shared Mailboxes Part II – How do you create a shared mailbox from scratch and then add permissions to them?  

Office 365 Calendar Invites and Meeting Requests

Archive Mailboxes

Mail Retrievals within Office 365

How to use Microsoft Active Directory Synchronization (“MS DirSync”) for Office 365 more effectively

Exchange Hybrid/Coexistence migrations to Office 365