Office 365 certificate errors outlook.office365.com revoked

[RJordan-CCS]

Since this week we've had three occurrences at our office of a dialog popping up saying that secure communication for the office apps was not trusted because the vertificate for outlook.office365.com was revoked.  Its that one specific domain.

When researching the problem, most of the fixes found we for issues on the upstream firewall, in our case an MX84, but the solutions were for Sonicwall and Cisco ASAs.  On the Sonicwalls you had to whitelist a pair of Digicert URLs, and other actions for the ASA (sorry don't have that link right now).  And a majority of the incidents I read about reported that apparently fixed the problem.  Today we had a customer behind a Sonicwall experience the dialog, so the fix for that is in place, and we'll have to see if it repeats.

I can't find similar on the Meraki MX.  I have an open ticket but they've stated there is nothing on the MX that would do the equivalent, and the problem has to be further downstream at the per PC level or any intermediate firewall (none at our location).

So far we can't find anything at the host level; the problem is very sporadic so we don't know if a test system with the windows firewall turned off not getting the dialog (so far) is relevant.

Has anyone seen this before?  Got a fix?

Thanks

[SoCalRacer]

My thought is also that the PC is an issue. Try downloading/running the support tool on the affected PC.

https://diagnostics.outlook.com/#/

[PhilipDAth]

+1 to @SoCalRacer .

A common cause is the date/time on the machine.  Are you sure the machines date and time was correct?  It wasn't 10 minutes into the future or anything like that?

This wont be an MX issue.

[RJordan-CCS]

@SoCalRacer @PhilipDAth
thanks for responding. All three of the events (on three different PCs) are on systems in a windows domain. While I can't swear to the times when the dialogs popped (two of the machines were unlocked when people came in in the morning and were already displaying the dialog, the third just popped up later that morning), I did check them after seeing these post and they and the DCs were in sync and correct. I checked the event logs for the 'time change' events, there were a some but the adjustments were milliseconds, not minutes, over the preceding evening and night.

Yesterday we saw one pop up on a customer machine; also a domain environment, and by the time we were called and checked (maybe 15-20 minutes after the dialog popped up) times were correct there as well. Again can't speak to the time at the instant the problem cropped up, but that would be a pretty large swing.

For now we're letting it go, see if it repeats. If it does supposedly we have microsoft support via some squirrely method, and will engage them to help troubleshoot. I expect they'll blame whatever upstream device is doing SSL inspection (nothing, so far as I'm aware if the MX isn't doing it) since some of the reports and solutions for Sonicwall and Cisco ASA were on MS pages. So it goes.

[PhilipDAth]

There is another possibility.  That is it malicious, and someome is deliberately trying to intercept the traffic.

[markssmith500]

You are facing an Outlook security certificate error because of one of these factors i.e. invalid certificate, using a wrong hostname, incorrect date & time. But you can resolve this Outlook error aka the server you are connected to is using a security certificate that cannot be verified by changing Outlook SMTP settings, using unsecure port, verifying the Outlook security certificate name, etc.