Security alert in Outlook for office 365 Certificate

ajdratch
ajdratch used Ask the Experts™
on
I have a client that moved to Office 365 from on-premise Exchange 2010. They are using AD Sync so the old Exchange server is still online. When they open Outlook, they get a security alert for Outlook.office365.com - the security certificate for this site had been revoked. When I click to view details it shows it is issued by digicert and is valid until 8/1/2020.

This only happens when opening Outlook inside the network. laptops get this message inside the network but not outside.

Autodiscover is working properly. On the on-premise server I run Get-ClientAccessServer |select AutoDiscoverServiceInternalUri and it shows https://autodiscover.outlook.com/Autodiscover/Autodiscover.xml. I can ping autodiscover.domain.com and it returns Office 365 autodiscover name

How do I stop that security alert from coming up
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Shreedhar EtteTechnical Manager
Top Expert 2010

Commented:
Make sure you have autodiscover.yourdaomin.com is pointing to autodiscover.outlook.com.

In your local DNS server if you have yourdomain.com zone then make sure you have the autodiscover.yourdomain.com CNAME record is poiting to autodiscover.outlook.com

Author

Commented:
As I mentioned I can ping autodiscover.domain.com and it returns Office 365 autodiscover name autod.ms-acdc.office.com
Brian MurphySenior Information Technology Consultant

Commented:
This is a root domain issue.  Auto Discover can still work fine.  

Since this is a domain joined machine, the user is located in the same domain, and the machine is on the corporate network why was it looking at the root domain.

Outlook client will initially do the SCP lookup, on-premises Exchange cannot answer for Office 365 mailboxes.  Outlook then goes off and does the DNS chase down to find the Office 365 Autodiscover URL.

In a hybrid configuration the external Autodiscover namespace must point back to the on-premises Exchange infrastructure and not to Office 365.

You probably just need to disable "AutoDiscover Root Domain Lookup" by setting these registry keys on downlevel clients
HKEY_CURRENT_USER\Software\Microsoft\Office\VERSION\Outlook\AutoDiscover
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\VERSION\Outlook\AutoDiscover

I recommend changing this on one down level client and simply testing my theory.  Then, you can use GPO.

This can be done with GPO as well just need to have a central repository for with each version of ADMX/ADML files per version you have distributed to all internal clients.

Or, you can track down the IIS binding on possibly one or more DC's where you have SSL/TLS binding but that particular certificate is expired.

For example, remove autodiscover from FQDN and what does domain.com resolve to "internal".

The IP(s) of your DC's?
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Alex AppletonBusiness Technology Analyst

Commented:
You may be having an issue getting to the CRL from inside your network.  If you View Certificate, you should be able to see the CRL path from the details on the certificate.  See here:  https://www.digicert.com/util/utility-test-ocsp-and-crl-access-from-a-server.htm

There is a policy setting to have Outlook not attempt to download the CRL for the certificate, this will reduce security but may be a good workaround for you temporarily.  See Outlook - Security - Cryptography - Signature Status dialog box - Retreiving CRLs.  If you enable this policy settings you can set the option to "Never retrieve the CRL".  Alternatively you can set the registry key HLCU\software\policies\microsoft\office\16.0\outlook\security\usecrlchasing to 2 (Reg_DWORD)

Author

Commented:
I got a new certificate for the on-premise server however I still have the security alert come up when Outlook is opened.
The certificate is for remote.domain.com and autodiscover.domain.com
I had made these changes during the cutover to Office 365:

set-WebServicesVirtualDirectory -Identity servername\EWS* -InternalUrl https://outlook.office365.com/EWS/Exchange.asmx
Set-WebServicesVirtualDirectory -Identity servername\EWS* -ExternalUrl https://outlook.office365.com/EWS/Exchange.asmx
Set-ClientAccessServer –Identity servername –AutoDiscoverServiceInternalUri https://autodiscover.outlook.com/Autodiscover/Autodiscover.xml
autodiscover.domain.com points to autodiscover.outlook.com

After installing the certificate and still getting the alerts I set them back to point to https://remote.domain.com,,,,  inside the network remote.domain.com points to the internal server

It sill did not work. I changed autodiscover to point to the internal server and it still is not working.

In hybrid mode what should these settings be?
Brian MurphySenior Information Technology Consultant

Commented:
This is a root domain issue.  Auto Discover can still work fine.  

Since this is a domain joined machine, the user is located in the same domain, and the machine is on the corporate network why was it looking at the root domain.

Outlook client will initially do the SCP lookup, on-premises Exchange cannot answer for Office 365 mailboxes.  Outlook then goes off and does the DNS chase down to find the Office 365 Autodiscover URL.

Making those changes above is not going to keep Outlook from searching for the root domain.

Like I stated earlier, from one client simply run the connectivity test and you should see it trying to connect to domain.com and finding something.  
You can see this if you run the "Client Connectivity Wizard" using either Outlook or Remote Tool
https://testconnectivity.microsoft.com/

From Exchange
To Run the Exchange Analyzer tests in Support and Recovery Assistant, go to Advanced Diagnostic > Exchange Online > Check Exchange Online network connectivity > Yes.

Check Outlook Connection Status. Press CTRL key and right-click the Outlook icon in the notification area > select Test Connectivity....

Internally, your machines are domain joined.  To the AD Domain, not referring to FQDN.

You could have something internal, still, that is responding on domain.com (just the root).

You can easily rule out this theory by my previous comment.

You probably just need to disable "AutoDiscover Root Domain Lookup" by setting these registry keys on downlevel clients
HKEY_CURRENT_USER\Software\Microsoft\Office\VERSION\Outlook\AutoDiscover
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\VERSION\Outlook\AutoDiscover

Reboot
Retest

If the certificate error goes away you know now that you have either IIS running on a DC with a root certificate bound - for whatever reason - or something else.  Easy to test and rule out.

Author

Commented:
Autodiscover test comes back with no errors.

When you say "disable" registry keys do you mean delete them?

Still not sure why it says the certificate for this site has been revoked when it is issued to Outlook.com and is valid until 2020
Senior Information Technology Consultant
Commented:
We can discuss the why later but for now it is very easy to test on one client machine, if your willing.  If your open to testing then here are the registry keys that must be set on one client - for testing.

HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover
(AND)
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\x.0\Outlook\AutoDiscover
 
(x.0 corresponds to the Outlook version: 16.0 = Outlook 2016, 15.0 = Outlook 2013, 14.0 = Outlook 2010, 12.0 = Outlook 2007) and create these DWORD values as follows:

PreferLocalXML=0
ExcludeHttpRedirect=0
ExcludeHttpsAutodiscoverDomain=1
ExcludeHttpsRootDomain=1
ExcludeScpLookup=1
ExcludeSrvRecord=1

For Outlook 2010 version 14.0.7140.5001 and later versions, please also add the following DWORD:
ExcludeLastKnownGoodURL      1

For Outlook 2016 version 16.0.6741.2017 and later versions, please also add the following DWORD:

ExcludeExplicitO365Endpoint      1

Reboot.
Launch Outlook.
Test 1.

Author

Commented:
Registry settings did not work. I am working on a terminal server so I can not reboot now but I logged off and back on. I assume that is enough since these registry keys are under HKEY_CURRENT_USER

Author

Commented:
There is one more registry setting needed. I found this on another site and it appears to have worked
Hkey current user\software\policies\microsoft\office\16.0\outlook\HTTP DWORD 32 bit FailAllCertificateErrors  value = 1

Not sure if this is all that is needed or if I needed Brain's registry settings also. I may test that later but for now I am happy to have this resolved
Brian MurphySenior Information Technology Consultant

Commented:
Glad it is working. Simplest solution often works.  I came at this from the registry perspective to help eliminate "all the above" being I'm not in the "driver's seat". If you want to find the "root cause" we can troubleshoot further but need to start a separate thread. There is a reason why this is happening although if your ultimate goal is "cutover" then might be unnecessary.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial