We help IT Professionals succeed at work.

Security alert in Outlook for office 365 Certificate

4,618 Views
Last Modified: 2019-01-26
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

Shreedhar EtteTechnical Manager
CERTIFIED EXPERT
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
CERTIFIED EXPERT
Distinguished Expert 2019

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?
Alex AppletonBusiness Technology Analyst
CERTIFIED EXPERT

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
CERTIFIED EXPERT
Distinguished Expert 2019

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
CERTIFIED EXPERT
Distinguished Expert 2019
Commented:
This problem has been solved!
(Unlock this solution with a 7-day Free Trial)
UNLOCK SOLUTION

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
CERTIFIED EXPERT
Distinguished Expert 2019

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.

Gain unlimited access to on-demand training courses with an Experts Exchange subscription.

Get Access
Why Experts Exchange?

Experts Exchange always has the answer, or at the least points me in the correct direction! It is like having another employee that is extremely experienced.

Jim Murphy
Programmer at Smart IT Solutions

When asked, what has been your best career decision?

Deciding to stick with EE.

Mohamed Asif
Technical Department Head

Being involved with EE helped me to grow personally and professionally.

Carl Webster
CTP, Sr Infrastructure Consultant
Empower Your Career
Did You Know?

We've partnered with two important charities to provide clean water and computer science education to those who need it most. READ MORE

Ask ANY Question

Connect with Certified Experts to gain insight and support on specific technology challenges including:

  • Troubleshooting
  • Research
  • Professional Opinions